Cloudpack learnings

This page details some of the things we've learned in the process of implementing Cloudpack.

WARNING

This page is a work in progress.

Bundling the app as a single unit has limits

In the very early iterations of Cloudpack, we started out with the approach of moving the bundling step to a service, with the following goals:

• Reconfigure the app on the fly; toggle a feature, watch it appear/disappear in the bundle.
• Improve servicing by changing out dependency versions, causing a re-bundle.
• Improve testing; leverage re-bundling so that we can try private/new versions of dependencies easily.

From testing with a prototype in a very large app, we learned that the idea of "switching on a feature" causing a re-bundle would take at minimum 10 minutes to recompute. It also isn't really desired beyond development mode; you want production bits to go through as much validation as possible. This means you need to not just transform TypeScript; you need to validate it by running it through TSC. You need to lint. You need to run unit tests, integration tests, vr tests - anything you can to prevent issues.

This has led to a few realizations that took Cloudpack in a different direction:

• We need production and development modes; each has a separate strategy to achieve the ideal outcomes.
  • Development mode opts for speed in getting up and running, as well as incrementally updating. This comes at the cost of validation - we won't validate TypeScript, we won't run eslint, we won't spin up tests as you edit your code, we won't minify or tree-shake. Instead we will leverage browser cache and pre-bundled dependencies as much as possible to avoid doing as much work as we can.
  • Production mode opts for correctness and optimization, at the cost of performance. We will run TypeScript, eslint, tests. We will validate as much as possible, minimize and optimize bundles as much as possible.
• Validating things like bundle size, runtime performance, and memory footprint is only viable in production builds, so there is of course a need for production builds to be locally testable.