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:

module.exports=(req, res)=>{
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.

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

However, we recognize that a lot of you have existing, working codebases that might take
some time to migrate. To that end, we created the @now/node-server builder, which can embed your entire
server in a cloud function, provided that it fits within our limits.

{"builds":[{"src":"api/server.js","use":"@now/node-server"}]}

The @now/node-server builder only requires that you listen on a port, just like Now 1.0.

The /docs and /api sections now have a toggle to switch between platform versions.
They default to v2 for all users.

The Universal Now client capabilities are being removed from the client side,
in favor of our new architecture that incorporates these benefits directly at the platform level.

The legacy server-oriented and long-running workloads (v1) will remain operational and
deployable but will be de-prioritized once Now 2.0 reaches feature parity
for all the detailed customer use-cases.