
Now dev – Serverless on localhost - styfle
https://zeit.co/blog/now-dev
======
nickjj
From the article:

 _" When you work with servers, the developer workflow is quite tedious. You
have to run a process, find the port, then make your changes, then kill the
process (usually with Control+C)..."_

I don't know what web servers they are using but in development that's not the
case at all in Python, Ruby and Elixir.

With most modern web servers you can run them in some type of development /
debug mode where on code change, your code gets reloaded without having to do
that manually, and you'll get sub 100ms updates. This has been available for
many many many years now. Even with PHP development from 10+ years ago you had
a way to see code changes without having to restart Apache.

~~~
vbezhenar
You can't do that with Java. There are some workarounds, but generally people
restart application to check changes.

~~~
rubyn00bie
What? I beg to differ... I've used many a JVM web framework with hot
reloading. Like most every language, they are not perfect, and come with
gotchas but they're surely there.

~~~
vbezhenar
The only "easy" way to support hot reload in JVM is using java agent. But it
can only reload method body, so it's extremely limited tool. That's how IDE
usually work. You can sell your house and buy JRebel license, but if you don't
have house to sell, you're out of luck. You can try some experimental
alternative JVM implementations (DCEVM) which might or might not work.

May be your framework is just restarting automatically very fast. That's not a
hot reload, though.

~~~
chii
> framework is just restarting automatically very fast. That's not a hot
> reload, though.

If you can't tell the difference, then what's the difference?

There are plenty of ways to reload classes in the JVM as well - OSGi is the
most well known and popular. If an agent is the only way you've seen reloading
done, then you mustn't have much experience with the full range of libraries
and frameworks available on the JVM.

~~~
vbezhenar
The difference is that your runtime state is reset and you must architect your
application to keep fast startup time which is not always a good thing. OSGI
does not reload classes, it loads new classes, you can't reload class for an
existing object. It's the same restart, you just leak memory.

~~~
twblalock
> The difference is that your runtime state is reset and you must architect
> your application to keep fast startup time which is not always a good thing.

These are good things for serverless, which is what the article is about --
runtime state in a serverless application is bad, and fast startup is good.

Serverless instances are intended to be interchangeable and ephemeral. You
should be able to start new instances and they should be able to do the same
work as the existing instances -- that only works well if they are stateless.
Any necessary state should be stored in a database or blob store or some other
external state management system.

~~~
XMPPwocky
Plus, having runtime state around from a previous version (or versions!) of
the app sounds utterly terrifying

------
eoinmurray92
About 6months ago we had to leave now v1 because of bad TTFB times compared to
Heroku (me in Europe and server in USA east - now gave 800-900ms TTFB with
massive variance > 2s vs Heroku constant 250ms TTFB). We left because of those
bad TTFB times and an unresponsive support from my point of view, once they
left slack in favour of spectrum [1, 2] it was impossible to get a response. I
had left some detailed tests. (Spectrum is hosted on now I think which has
currently a 2s TTFB for me in Spain).

I really wanted to use now because the developer experience is so great but
the TTFB made itunusable for us to host customer facing services and lack of
support response made it hard to stay.

[1] [https://spectrum.chat/zeit/now/slow-response-times-for-
node-...](https://spectrum.chat/zeit/now/slow-response-times-for-node-js-
app~60bbbfa1-e38c-4314-b8c7-7df3cc3db08e) [2]
[https://spectrum.chat/zeit/now/latency-discrepancy-
between-n...](https://spectrum.chat/zeit/now/latency-discrepancy-between-now-
and-ec2~2b2562a9-2807-43f2-bbbe-eb40fcc6e7c6)

~~~
cgijoe
For those who needed to look it up like me, it stands for "Time to First
Byte". #SavedYouAGoogle :)

------
lucasmullens
This is the company behind Next.js, which I've had a wonderful experience
using for React development. They've managed to do what I thought wasn't
possible: abstracting away most of the build system. "Now" seems to do
similarly well at abstracting away a lot of the hosting complexity.

They've made React development feel as simple as PHP. Or at least close. Just
make a file and upload it.

~~~
kevinqi
How does Next.js compare to Gatsby?

~~~
armandososa
Next.js is server-rendered which means it includes a light weight node.js
server that pre-renders your pages, you can export everything as an static
website, but it's not really the main selling point.

I like to use next.js for small brochure-like websites. I think it's simpler
for simpler things. But for a more full-featured content site I would chose
gatsby.

~~~
DariusRucker
Wouldn't it be the other way around? Gatsby for static brochure sites and
next.js for something requiring dynamic content?

------
pcr910303
I can’t believe that `now dev` was released after about 6 months? from now v2
launch. For my experience in developing now v2, it was super insane to develop
for the platform. Any kind of code change involves minutes to just test, see
the `console.log` result, which makes developing super painful. Everytime I
think about Zeit’s now v2 is that it was rushed to launch for the new buzzword
‘serverless’. I actually was impressed by the new architecture; but
development was (and is... I didn’t check about a week or two, but last time I
checked: `now dev` doesn’t respect `now.json`’s routing properly) painful.
Ultimately I just went to Netlify Functions :-( (BTW... While I didn’t say
anything about Now v1, it’s a mistake if you consider v1 as outdated; those
two should be different products... and should not be deprecated but marketed
as a different service...)

~~~
RonanTheGrey
> it’s a mistake if you consider v1 as outdated; those two should be different
> products... and should not be deprecated but marketed as a different service

I'm not sure if your intent is to express your own opinion, or reflect Zeit's
official position; but their official position last I checked at the end of
the 1400 post monster Spectrum thread, was that Now v1 is dead and won't be
supported after some point.

And I think that is an utterly insane decision to be making, and is the reason
we are leaving. If I can't trust my host to not get "shiny tech syndrome",
then I need a different hosting service.

~~~
pcr910303
Oh, Mu intent was to express my own opinion. Looks like our opinions line up
:-)

------
esdott
Am I the only one who wishes they would continue their v1 system work? It Just
Works(tm) and was wonderful to use and easy to understand, especially from a
pricing perspective. I feel like the gas pump style pricing for their
serverless offering is shoehorning a pricing model that works well for vendors
but less so for users. With that said, I really enjoy these guys/gals’ work
and would love to work more with their platform.

~~~
LetItSnow
An alternative, open-source solution to Now v1 is in the works:
[https://github.com/snowjs/cli/tree/secrets](https://github.com/snowjs/cli/tree/secrets)

~~~
everdev
Apex Up is a similar service:

[https://github.com/apex/up/](https://github.com/apex/up/)

------
factsaresacred
I really like the stuff by Zeit but if you've been a user for more than a year
it's insane how quickly the platform is shifting under your feet.

 _" The latest version of the CLI is now x.x.xx"_ \- and all that stuff you
think you knew how to do has changed. And we've added a useful feature that's
only documentation is Github issue #432.

Also this email is to inform you that you've been charged incorrectly because
you're on Now v1. Upgrade to Now v2 for cheaper rates. It's simple, just
follow these 8 steps, change your entire mental-model of how everything works,
and flip this obscure option in your settings.

It's as if their development process is a bunch of hackathons thrown out to
the public.

You're doing good work Zeit, but please, some order.

~~~
mindrun
Hey, Leo from ZEIT here!

I agree strongly. There's been a lot of chance over the last couple of months,
as Now 2.0 appeared and the entire platform started adapting to it.

However, I'd also like to let you know that the entire concept of "platform
versions" is just a temporary way of slowly allowing everyone to migrate to
Now 2.0 at their own pace. Once this process is complete, the whole concept of
platform versions will disappear and I hardly doubt there will be any major
changes from that point on.

------
2kballs
I really like the recent trend of dead-simple deployment tools. Now,
zeroserver[0], and 1mb[1] are all awesome attempts at simplifying the
confusing web world!

[0] [https://zeroserver.io](https://zeroserver.io) [1]
[https://1mb.site/](https://1mb.site/)

------
miki123211
I've heard a lot of devs have very negative comments about Now 2, but have
never delved into specifics. Apparently it's way worse than 1. Anyone here has
any idea what, exactly, is wrong with it, and whether it's really bad?

~~~
simonw
They're very different products.

Now v1 was essentially serverless Docker: you define a Dockerfile that runs a
web server on a port (along with anything else you can cram into that
container), push that Dockerfile up to Now v1 and they would build the
container and run it in a scale-to-zero configuration: with no traffic, the
container wouldn't run at all. When a request came in it would start up and
start serving - then it would shut down again a few minutes after the last
incoming request.

It was very similar to Google's new Cloud Run product - but better, because
you didn't even have to build the Dockerfile yourself - they would build and
run it for you.

The biggest catch with v1 was the cold-start time: depending on the size of
your image it could take quite a while to serve that first hit. Their efforts
to optimize this apparently didn't work out well enough for them.

Now v2 is an entirely different product. It doesn't use Docker at all -
instead it compiles your code to run on AWS Lambda. This means it's MUCH less
flexible: with Now v1 you could run anything that could be defined in a
Dockerfile - Now v2 instead requires you to stick to the list of languages
supported by their "builders" \-
[https://zeit.co/docs/v2/deployments/builders/overview](https://zeit.co/docs/v2/deployments/builders/overview)
\- initially available for Node.js, Python PHP and Go but more have emerged
over time.

Now v2 also has the ability to run a single app built in multiple languages -
it compiles each language to a separate Lambda. This is a neat technical trick
but it's not something most people are actually keen on using in my opinion.

My biggest problem with v2 is that you have to write software that
specifically targets it. With v1 I could take any web application that can run
in a Dockerfile and deploy it instantly with no changes. v2 requires me to
write code that directly targets the Now v2 system (hence why the initial lack
of "now dev" was so painful).

My second biggest problem with v2 is that the AWS Lambda build of Python 3
doesn't currently ship with the sqlite3 module, which is key to many of my
projects.

From my perspective, Now v1 was genuinely my dream hosting environment. Now v2
is an interesting project, and it's great if your project is one that fits the
AWS Lambda model well, but it's no-where near as appropriate for my projects
as v1 was.

~~~
omnimus
I am curious what use would sqlite3 module be in Lambda function? Lambda has
no persistency so you cant really use sqlite no?

~~~
simonw
Read-only databases: [https://simonwillison.net/2018/Oct/4/datasette-
ideas/#Publis...](https://simonwillison.net/2018/Oct/4/datasette-
ideas/#Publishing_readonly_data)

~~~
mayank
This is a great point. For small to medium, read-only, slowly changing
datasets, this is the ultimate serverless database model, especially for lots
of queries.

Although I think this approach would benefit more from Cloud Run’s request
multiplexing per function.

------
nailer
If you're interested in other JS based serverless frameworks,
[https://arc.codes](https://arc.codes) can also run on localhost - even though
serverless deploys are fast because they're per-lamda, localhost is still
super useful for ever faster iteration.

~~~
dboreham
Also :
[https://cloud.google.com/functions/docs/emulator](https://cloud.google.com/functions/docs/emulator)
(JavaScript only) and [https://www.openfaas.com/](https://www.openfaas.com/)
(if you can tolerate running Minikube on your "localhost".

------
revskill
Imagine AWS has the same Developer Experience as Zeit team, AWS could benefit
even more from their services. The AWS console and its definitions is too low
level to me, hard to grasp quickly to produce something useful.

Congratulation to Zeit team for the effort on DX. Thanks you very much for the
inspiration.

~~~
mindrun
Thanks for the compliments! That's exactly what our product is trying to
achieve: Abstracting away all of that low level stuff, so you can just run
`now` and that's it.

------
youeseh
For anyone interested, I finally figured out how to run Rust on a local AWS
lambda instance using SAM:

[https://github.com/vishaldpatel/rust_lambda_sam_local](https://github.com/vishaldpatel/rust_lambda_sam_local)

.. hopefully it'll save you some time =).

~~~
kkarakk
>Prerequisites:

>\- Newer installation of Rust, probably.

does not instill confidence

~~~
youeseh
Well, I don't know if it'd work with an older version. I just got into the
Rust game ;).

------
mvindahl
I'm currently experimenting with migrating a side project to now 2.0. It has
been a learning experience, for sure. But so far I think that it has been time
well spent.

My overarching goal is to be able to create and deploy a new web app, from
scratch, and just have the platform take care of all the boring stuff that
should just work.

So far I've been pretty pleased with nextjs and now 2.0, especially once I
grokked the lambda concept and found out how to slice my old express server
into vertical pieces. Also, I had to realize that the monorepo model was the
right fit.

I'm not quite up and running yet on now 2.0 but I'll be any day now. Curious
as to how it will affect my bill.

~~~
mindrun
I'm glad to hear! Over time, more and more guides and proper documentation
will be created for Now 2.0, so I'm sure you won't have any troubles with
migrating any kind of application to Now 2.0. Aside from that, your bill is
most likely going to decrease heavily, as Now 2.0 is much cheaper than Now
1.0.

------
sridca
Dumb question: is this specific to the JavaScript system? How does it relate
to using Nix for development?

~~~
mindrun
The command used for this can be invoked on any OS that Now CLI supports
(Linux, Alpine, macOS and Windows). In terms of the languages that are
supported, there's no end, really:

[https://github.com/zeit/now-
builders/tree/master/packages](https://github.com/zeit/now-
builders/tree/master/packages)

(These are just the default ones, you can add your own language using
[https://zeit.co/docs/v2/deployments/builders/developer-
guide...](https://zeit.co/docs/v2/deployments/builders/developer-guide/))

------
hjdarnel
Finally - I've been using Now v2 for side projects at work and it's been a
PITA to work without simple local dev. Having to shoehorn dev-only code in
there was annoying. Hopefully this works well.

~~~
mindrun
I'm glad to hear. Should you encounter any bugs, please let us know at
[https://zeit.co/feedback/dev](https://zeit.co/feedback/dev) and we'll get
right to it.

------
nathan_f77
Ouch, so many negative comments in this thread. I thought this sounded very
interesting and was thinking about trying it, but it sounds like they need to
improve a lot of things.

~~~
mindrun
This release of `now dev` is indeed a preview release. We're working very hard
to improve the quality of the CLI, so should you notice any bugs, please let
us know and we'll get right to it:
[https://zeit.co/feedback/dev](https://zeit.co/feedback/dev)

------
dewiz
Is Now much different from docker run nginx pointed to a volume mounting a
local folder?

~~~
paxys
Yes, for one it hosts your code on the internet.

------
peterwwillis
People still think serverless is a good idea? There must be a certain
threshold of horror story blog posts necessary to kick bad patterns.

~~~
quickthrower2
If "serverless" is referring to AWS Lambda, Azure Functions, etc. then cost
and scalability make it a great idea for some applications. If load varies by
time, and there are surges and troughs, then running servers can cost more and
potentially be less responsive to changing demand. Its a nice way to take load
off a web server.

~~~
jjeaff
I feel like the use case is much smaller than the number of people preaching
it warrants though.

You really have to have extremely unpredictable and spikey needs as well as
need the processing immediately. Because if the traffic is predictable, you
can schedule spot instances for much cheaper and same for if the data doesn't
have to be processed immediately.

To me, the best use cases are very infrequent, spikey, brief needs. I haven't
seen a lot of examples that meet that.

~~~
quickthrower2
I agree. Where I saw it used, I'd say 99% of the application logic was in the
web server, 1% in functions.

The 1% in functions was for processing large PDF files where users were
sitting their looking at a progress bar waiting for the file to be processed
in real time.

Another use case might be for something that is very low load, and say you
have a lot of these services you may not want a VM for each one. However
Docker provides a nicer solution for that: Get a VM (reserve if required) and
run some kind of Docker host/orchestration on it, and run all your little
services from there.

------
sbussard
Cool! Did you steal this from TJ too?

