- The Architecture Playbook
- The Frontend Playbook
- The Backend Playbook - In Progress
The Architecture Playbook
A unified development effort should use a single infrastructure to control all similar projects.
The Frontend Playbook
Our frontend infrastructure is based around webpack builds, but most of the guidelines / goals apply to any build tool.
A short list of plugin recommendations for best frontend performance include:
||Yes for v1||Collapse identical code chunks to a single reference|
||Maybe for v1||Reorder module and chunk ids by occurrence count|
||Maybe||Define constants for better optimization|
Code splitting is a Webpack feature that enables a JS bundle within a single build to be split up and loaded on-demand in smaller parts. Code splitting is appropriate within a single page and build.
Webpack shared libraries are slightly different from code splitting scenarios in that the common dependencies are shareable across builds and require a two-part build. In a first step, a common shared bundle and manifest is created. Then, in a second step, entry points ingest the manifest and omit any libraries included in the shared bundle. Shared libraries are appropriate for better long term caching within a single app across deploys and across different projects / real HTML pages.
Scope hoisted bundles try to place bundle modules into a global bundle scope so as to reduce the overhead of function calls for each bundled module. The problem and scope hoisting solutions are discussed in detail in Nolan Lawson's 2016 article "The cost of small modules"
Tree shaking is a
transformation process for ES6 modules
exports that are not used in a Webpack bundle can be isolated
during code bundling and removed entirely by Uglify dead code elimination.
The Webpack SourceMapDevToolPlugin creates source maps which allows a developer to view / debug developer-friendly source code instead of the optimized, mangled, and minified JS bundle of a frontend web app. Source maps should be enabled for both development and production.