Now dev – Serverless on localhost

by styfle • 7 years ago

273 104 7 years ago

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.

rudolph9• 7 years ago

I’ve had a very similar experience building with nextjs. Drastically simplifies the boiler plate needed for a React app and gives you a concise api for SSR.

siquick2• 7 years ago

I use Next by default for all React projects now. Just haven't found any reason not to, it's a joy to use. Same can be said for the Vue equivalent, Nuxt.

kevinqi• 7 years ago

How does Next.js compare to Gatsby?

freedomben• 7 years ago

Would be interested in this as well. I currently use Gatsby for a personal site, and the development server is great and for prod I just sync production assets to an s3 bucket and serve from there. It's hard to see how it could get any easier.

armandososa• 7 years ago

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.

siquick2• 7 years ago

The positives are both are pretty similar but the usecase is different.

Gatsby probably isn't the right choice if you have a lot of pages (e.g. ecommerce site) as it has to render each page down to HTML during the build - so everytime you make a change, you have to rebuild all those files which could take a substantial amount of time. But if you were just building a few landing pages or a blog that required good SEO then Gatsby would be fine.

Next.js renders serverside on the fly and has good SEO.

This might be useful for you to read: https://coffeencoding.com/cra-vs-next-js-vs-gatsby/

nailer• 7 years ago

If you're interested in other JS based serverless frameworks, 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• 7 years ago

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

hjdarnel• 7 years ago

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.

mindrun7• 7 years ago

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

peterwwillis2• 7 years ago

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

westoque• 7 years ago

Yes. I believe "serverless" still has it's use cases. It's really good for small services and abstracting away some logic. It's really good for basic query and render (html/json) type apps. If you're doing more, then I suggest you just build more services that are specific to it's task and then let them talk to each other through RPC or similar.

sidmitra• 7 years ago

Depends on your use case. Certain parts of the app fit the bill really well.

Just yesterday i put the 'dnspython' module behind a google cloud function and all it took was 5 minutes and i had a REST interface to query MX records. It's great for small little use cases like that.

Another use case might be a simple webhook, where you're receiving pings from an external service and all the serverless function does is save it to a DB and maybe trigger another task for it.

In cases like this you can skip a lot of the devops boilerplate and reduce it a single file containing your function and perhaps a requirements.txt(or whatever manages your dependencies)

peterwwillis2• 7 years ago

It would also be really simple to sftp a single application to a /cgi-bin/ directory on a shared web host. You don't need to know anything except STDIN and STDOUT, and none of that CI/CD or VCS boilerplate to worry about. Instant web applications. It'd probably be much simpler than using Lambda.

I don't have anything against FaaS as a concept, but it almost always leads to crappy operation. The simplest examples of it working are crowded out by the attempts that ended up redesigned as normal applications.

skrebbel• 7 years ago

Care to share? I haven't seen a single such blog post and would like to learn. (never did much serverless myself but could see us use it in the future)

mark242• 7 years ago

Yes.

I will gladly pay (Amazon|Google|Microsoft|Cloudflare|Zeit) to manage software deployment infrastructure for me, allowing my teams to concentrate on writing business logic. As with any other concept, it has a learning curve, but once you're comfortable with the concepts, your development will speed up, no question about it.

vbezhenar4• 7 years ago

Is there any solutions for Intranet websites without Internet access?

quickthrower22• 7 years ago

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• 7 years ago

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.

simplify• 7 years ago

Lots of replies saying it "depends on your use case", but zeit's departure from v1 to v2 clearly shows they think serverless fits most use cases.

dewiz• 7 years ago

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

paxys• 7 years ago

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

nickjj• 7 years ago

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.

vbezhenar4• 7 years ago

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

rubyn00bie2• 7 years ago

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.

barrkel• 7 years ago

If you want to do it with the JVM, I recommend Play.

paulddraper• 7 years ago

There are in fact several ways to do this in Java.

The Play framework uses classloaders to keep library classes (which are stateless) loaded, while reloading app code.

The JVM has build in hot swapping for cases where signatures don't change.

And then JRebel uses proprietary rocket science to do really good hot reloading.

SomeHacker44• 7 years ago

Clojure in JVM does hot reloading brilliantly.

holtalanm• 7 years ago

wut?

java has had hot reloading of recompiled classes for years.

and if you use dcevm, the number of things that can be hot-reloaded is even higher: http://dcevm.github.io/

RossDM• 7 years ago

hot reloading is standard with Java frameworks such as Spring Boot or Play.

tathougies• 7 years ago

I guess I just don't see how much easier it can get than to kill a process, start it, and test. These are all solutions to non-problems. My control-C + up arrow motion is hammered down after years of practice.

BigJono• 7 years ago

Yeah, same as Ctrl-Shift-R in the browser for me. Even when I'm running a hot reloading server on my project I'll start off pretty much every manual test with a hard refresh because it's so trivial that it's easier than dealing with the 1/500 chance of something going weirdly wrong with the hot reloading and being difficult to debug.

joevandyk• 7 years ago

Easier:

Save a file, see the result instantly.

In a browser, terminal, etc. Using live reload, auto test, Rails class reloading, and so on.

mayank3• 7 years ago

If you have multiple monitors, you don’t have to lose keyboard focus to see a change visually.

pdpi• 7 years ago

Developer ergonomics are made of an accumulation of small things like this.

wastedhours• 7 years ago

Same for me - I even do it for things that don't really need a server restart to take effect, just because it's an ultra-quick reflex. It's a non-issue really.

stephenr2• 7 years ago

It's hardly surprising the phrasing is a big WTF - the term "serverless" is the most ridiculous thing since rented virtual servers suddenly become "the cloud".

You may as well make a bacon pizza and say "vegetarian" and when someone questions it, just say "well you didnt personally kill the pig, so it's not really from an animal"

TheAceOfHearts• 7 years ago

I'm also not a big fan of the term "serverless" within this context either, however I don't think it's entirely fair to blame the Zeit team for following along with the rest of the industry. All the big tech companies use the term, which forces smaller players that wish to compete in the same space to use it as well.

unityByFreedom• 7 years ago

the term "serverless" is the most ridiculous thing since rented virtual servers suddenly become "the cloud".

hah! I'm so happy to see someone say this. I've been thinking the same for awhile and did not know how to articulate it.

guru4consulting• 7 years ago

do you feel the same when you hear "wireless internet", "WiFi", "cordless mic", "wireless phone"? in that context, 'serverless' sounds okay to me.

Nafesy12• 7 years ago

Both terms have a deeper meaning which is seemingly lost on pedants like yourself.

Is a rented vm in a warehouse on a remote industrial estate a hyper-scale data centre with dedicated fibre etc.? No.

Is a web host which lets you manually add more hosts into a load balancer and bill you for each additional host a self-scaling, micro billed (aka serverless) solution? No.

But you know that already.

Nafesy12• 7 years ago

Both terms have a deeper meaning which is seemingly lost on pedants like yourself.

Is a rented vm in a warehouse on a remote industrial estate a managed data centre with dedicated fibre etc.? No.

Is a web host which lets you manually add more hosts into a load balancer and bill you for each additional host a self-scaling, micro billed (aka serverless) solution? No.

But you know that already.

a_t48• 7 years ago

I implemented hot reloading once for a game scripting engine. The gain was totally worth the work I put in (and had the side effect of discouraging use of globals).

honopu• 7 years ago

Yeah in PHP, unless you have some opcode caching that ignores file modification time, you simply need to just change the file and it immediately starts running the new code. There isn't a compiled runtime generally that persists across requests. This is one of the great things about php, and is one of the things that made PHP so pervasive and get the marketshare that it did.

When I last did PHP, i ran it all in docker, but the same thing applies.

ianamartin• 7 years ago

The reality of developing serverless apps is seriously painful for anything that's not 'hello world'. Non-trivial functions very quickly go over the size limit for directly uploading your dependencies, then you have to start doing stuff like extracting your python packages into a zip file and pushing it to an s3 bucket, and then every small code change requires a new upload. Testing and debugging tools for serverless are distributed logs that are mixed in with all your other logs in your VPC.

I'll take a look at this the next time I'm required to use serverless, but I really don't know what the people pushing this as the future of web apps are smoking. It's never been anything but pain for me. How anyone can try to use this for real and say, "This is sooooo much better than all that old shit!" has never actually used that old shit. That old shit works really, really well. It has for a very long time.

esdott• 7 years ago

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• 7 years ago

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

everdev• 7 years ago

Apex Up is a similar service:

https://github.com/apex/up/

mindrun7• 7 years ago

Thanks for your feedback. We've actually received quite a lot of other feedback regarding the new pricing model and will – as a result – soon be working on a way to set custom alerts and limits, so that it behaves just like 1.0 pricing, if you want it to.

With regards to 1.0 "just working": Aside from making 2.0 more intuitive, we're heavily investing into tools that allow you to automatically transition existing applications to 2.0, so that would definitely help a lot.

danscan• 7 years ago

https://futurism.com is using it too, but we're about to move to 2.0 :)

sridca• 7 years ago

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

mindrun7• 7 years ago

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

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

kreetx• 7 years ago

(I know Nix, not so much Now.)

Given what I read in this thread and their docs, it looks like they are still searching for a coherent solution to solve the "deploy my app" problem (from Docker with v1 to AWS lambda in v2), and they appear to be very vendor-specific with solving it.

The main goal seems to be to condense any action a developer might want to do into a single command.

It pretty much seems geared towards the JavaScript ecosystem.

miki123211• 7 years ago

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?

ingenieroariel• 7 years ago

now 1 was very opinionated but got out of the way quickly, with mini al changes to your code (in my case golang) you were up and running, did it with a Dockerfile using scratch as a base, integration with github, autoscaling, multiple data centers. I ran a production app used by hundreds of mobile users every day and it ran for a year practically unsupervised. you were up and running. now 2 requires rearchitecting your applications, in golang it means one file per server path and for our application it meant it was easier to migrate to GCP using nixops.

pcr9103033• 7 years ago

It’s not bad; it’s a different product. Now v1 was about dead simple deployments with no configuration, as now automatically configured that for you. Now v2 is about serverless (with minimal lockin, I’d say), and is a pretty good (actually pretty awesome) product if you see it alone.

The problem is that Zeit wants to deprecate Now v1 in favor of Now v2, which is super different and is incompatible (Now v1 code should be appropriately configured to use the `@now/node-server-builder` to run on the v2 platform).

I believe that Zeit should keep these two products as different names, something like ‘now classic’ and ‘now serverless’.

simonw2• 7 years ago

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 - 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.

omnimus2• 7 years ago

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

2kballs• 7 years ago

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 [1] https://1mb.site/

pcr9103033• 7 years ago

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• 7 years ago

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.

pcr9103033• 7 years ago

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

youeseh2• 7 years ago

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

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

kkarakk• 7 years ago

Prerequisites:
- Newer installation of Rust, probably.

does not instill confidence

youeseh2• 7 years ago

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

eoinmurray92• 7 years ago

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-... [2] https://spectrum.chat/zeit/now/latency-discrepancy-between-n...

cgijoe• 7 years ago

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

asien• 7 years ago

We left because of those bad TTFB times and an unresponsive support from

Had strictly the same issue with zeit.

Performance is horrible.

I also remember seing a somewhat similar issue about latency opened on GitHub[0].

They randomly closed it without giving any explanations or further details.

That's great support for sure !

[0] https://github.com/zeit/now-cli/issues/592

danr4• 7 years ago

From my experience, every single time a company/product moves to Spectrum, the quality of support drops significantly, both from staff and the community. I really don't understand why people like it, and why they were bought by GitHub.

paulogdm• 7 years ago

This has been improved massively with Now 2.0. Feel free to do any benchmarks on it!

sbussard• 7 years ago

Cool! Did you steal this from TJ too?

factsaresacred• 7 years ago

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.

mindrun7• 7 years ago

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.

revskill• 7 years ago

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.

mindrun7• 7 years ago

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.

nathan_f77• 7 years ago

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.

mindrun7• 7 years ago

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

mvindahl• 7 years ago

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.

mindrun7• 7 years ago

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.

Now dev – Serverless on localhost

Related Stories