Architect 8.4: say hello to Lambda tree shaking
One of the things that sets OpenJS Architect apart from other serverless tools is its opinion that serverless apps work best when composed of many small, discrete Lambda cloud functions.
This approach offers the greatest coldstart performance, security isolation, deployment speed, and mean time to bug resolution. However, this approach also comes with a minor drawback: the need to manage many Lambdas’ dependencies. Or at least it used to! Architect 8.4 introduces a new concept we call Lambda Node.js modules tree shaking.
How Lambda tree shaking works
If you’d like to take advantage of the nearly 1.5 million publicly published Node.js modules, your Architect app may have numerous individual package.json files spread across its various Lambdae. Here’s an example file tree of how such a project might look:
/ ├─ src/ │ └─ http │ ├─ get-index │ │ ├─ index.js │ │ └─ package.json │ ├─ post-api │ │ ├─ index.js │ │ └─ package.json │ └─ put-api │ ├─ index.js │ └─ package.json ├─ app.arc └─ package.json
Architect 8.4’s Lambda Node.js modules tree shaking now automatically statically analyzes all of your Lambdas’ business logic and manages each of their dependencies from the root. This means:
You only ever have to install dependencies one time in one place: your root
Similarly, upgrading, removing, or otherwise maintaining dependencies happens in your root as well
Perhaps our favorite: no more having to keep dozens (or hundreds) of individual package[-lock].json files in your repo
Now the project above looks like this:
/ ├─ src/ │ └─ http │ ├─ get-index │ │ └─ index.js │ ├─ post-api │ │ └─ index.js │ └─ put-api │ └─ index.js ├─ app.arc └─ package.json
Get started with Lambda tree shaking
For starters, make sure you’re running Architect 8.4 (
npm i @architect/architect@latest)!
For new projects, taking advantage of Lambda tree shaking is as simple as adding dependencies to your project’s root package.json file (and require()¹ them in your business logic).
For existing projects, any Lambdas that already have their own
package.json will continue to have their dependencies wholly managed by you, meaning you can choose to mix and match dependency management on a per-Lambda basis.
We think this is a massive step forward in the ergonomics of building cloud function-native applications — we’d love to hear what you think in Architect’s Discord!
¹ Architect will ship ESM support when Lambda ships Node.js 14 support; dynamic requires are not supported
Art by Michael Ramstead