As we can see in the updated Now CLI visual feedback, adding @now/php resulting
in the processing of a build that outputted a lambda,
identified with λ.
The @now/php identifier refers to an npm package whose purpose is to
execute the build logic. We call it a Builder.
Builders operate on an abstract open-source API that
gives us future-proofing, prevents lock-in and maximizes interoperability
across all cloud infrastructure providers.
The best part? While we maintain official builders that make your life
easier for popular languages and frameworks, you are free to write your own.
In the spirit of a true monorepo, let's now add a Node.js endpoint as /date.js:
From `@now/php` to `@now/node`
The reason we started with PHP as our example is not coincidental.
While it's true that PHP is the technology behind tremendous successes like Facebook, Box, Yahoo, Wikipedia, Flipkart, WordPress, and many other giants, it's not
as popular of a choice as it once was.
In many respects, PHP has represented a unique and scalable marriage between programming language and execution model. The way it helped scale those companies is by imposing a fully serverless architecture:
No servers to manage (infrastructure)
No servers as an abstraction (code)
In line with the second point, the @now/node builder, therefore, presents
you the following API:
res.end('The time is: '+newDate())}
We retain the fully standard Node.js API, but reduce its surface.
By adding just one item to our builds config we can make our /date.js entrypoint
come to life:
Crucially, each entrypoint becomes a kind of sub-application. The compiler automatically code-splits to make sure that you don't ship extra code to users who are entering through only a
certain part of your application.
This has a dramatic effect on scalability, both at the code and team levels. A page can
accumulate complexity that doesn't impact other sections. This means teams being able to
fearlessly evolve their own codebases without being encumbered.
The entrypoint for @now/next can be next.config.js or package.json.
Let's take a look at what happens when we deploy this:
Compiling an existing Next.js app, previously deployed as a container, to serverless functions. Zero code changes.
Notice the output: unlike our other builds, @now/next is yielding
static files as well as multiple lambdas. This translates into:
Reduced cold bootup times
Per-route scaling and resource allocations
Increased security due to reduced surface
With zero changes whatsoever in how you were writing your application until today.
Now 2.0 brings symmetry to the cloud, by also code-splitting your backend
The Majestic Monorepo
Instead of having one large build process and one large process per project, you
instead get user-definable parallel builds.
A build is a piece of code that takes an entrypoint sourcefile (like contact.php) and
transforms it in some way. In the case of our example, @now/php is the build that
turns contact.php into a cloud function that executes on demand.
Builds can also transform static files into other static files, or yield new ones. They are
written in Node.js (LTS versions only), published to npm and open-sourced on GitHub.
As an example, we can optimize PNGs with a massive degree of parallelism by using
the @now/optipng builder.
A basic static site, whose sources get transformed to become ready for production.
Most interestingly, Now 2.0 enables what we will call The Majestic
Monorepo, inspired by a similarly named essay by DHH, creator of Ruby on
Rails (The Majestic Monolith).
We don't agree that you should be orchestrating a big server abstraction (a monolith), but
we believe you should be able to collocate your APIs and your business logic in a single
place, with a cohesive deployment story.
It looks, feels and deploys like a monolith, with none of its downsides
As an example, Now Lambdas now enable the following: