This blog post is the first of the Inside Defer Series, opening a door into the inner workings of Defer on the technical and operating side.
The Defer Builder enables developers to get up and running with Defer with minimum code changes using background functions.
By building the projects, Defer adapts to all projects, not the other way around, saving tons of work for developers.
However, with hundreds of builds per day and continuous executions, introducing changes to the Defer Builder could be a slow and hazardous process.
We use the defer.demo repository as a matrix of supported project setup and frameworks:
The above projects also carry different tsconfig.json dependencies, and import scenarios to strengthen the testing coverage.
The defer.demo repository is configured on Defer, where every framework subfolder is assigned to an environment:
We also leverage Environments for new features by assigning new environments to development branches, example with the qa/concurrency branch:
This gives us a defer.demo project with 20+ environments:
Defer is connected to GitHub and Slack, which gives us visibility when a new build version is breaking some specific setup or framework support:
The integration with Vercel enables us to continuously test new @defer/client versions.
Example of a notification of a failing build linked to a canary version of the Builder.
Our dogfooding example is specific; however, the principles of leveraging environments for end-to-end QA or ongoing development work are universal.
Here are how you could leverage Defer environments to improve your development process:
Git flow environments
Most developer teams embrace the staging + production Git flow.
80% of Defer applications contain two environments that match an underlying Git flow: production and staging.
QA breaking changes and preview environments
Introducing breaking changes in background functions can lead to unanticipated execution issues (renaming issues, arguments breaking changes, workflow breaking changes).
For this reason, we recommend creating a new environment (assigned to a Git branch started from the default one, ex: main) to run a representative amount of executions on the updated background functions.
We suggest creating a new environment for each working branch or final Pull Request.
For this reason, we will soon introduce a “Preview Environments” opt-in feature.
Like the former breaking changes scenario, the Defer environments can be leveraged to run performance benchmarks on background function optimizations.
The Defer Console showcases the average duration, information that you can leverage to do quick performance assessments:
Explore how to offload time-consuming work outside your Node.js or Next.js API's critical path.
Processing images directly from your Express application has many downsides that should be avoided by moving these CPU-intensive and memory-leaking tasks in the background.