12 ms·

Now dev – Serverless on localhost

273 points by styfle 7y ago

lucasmullens 7y 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 7y 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.
- siquick 7y 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 7y ago
  How does Next.js compare to Gatsby?
  - freedomben 7y 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.
    - mayank 7y ago
      You could trigger that sync script from a git hook.
      - ohadpr 7y ago
        Or you could have Netlify handle build+deploy+host for you
  - armandososa 7y 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.
    - DariusRucker 7y ago
      Wouldn't it be the other way around? Gatsby for static brochure sites and next.js for something requiring dynamic content?
  - siquick 7y 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/ https://coffeencoding.com/cra-vs-next-js-vs-gatsby/
nailer 7y ago
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 7y ago
  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".
hjdarnel 7y 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.
- mindrun 7y ago
  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.
peterwwillis 7y 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 7y 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 7y 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)
  - peterwwillis 7y 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.
    - justasitsounds 7y ago
      Genuinely interested to hear/read these use cases. I'm using a serverless stack at the moment (AWS Api GW + Lambda), and after the initial headaches of wrestling with Cloudformation it's been relatively simple and performant
dewiz 7y ago
Is Now much different from docker run nginx pointed to a volume mounting a local folder?
- paxys 7y ago
  Yes, for one it hosts your code on the internet.
nickjj 7y 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.
- vbezhenar 7y ago
  You can't do that with Java. There are some workarounds, but generally people restart application to check changes.
  - rubyn00bie 7y 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.
    - vbezhenar 7y ago
      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 7y ago
        > 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.
esdott 7y 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 7y ago
  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 7y ago
    Apex Up is a similar service: https://github.com/apex/up/ https://github.com/apex/up/
- mindrun 7y 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 7y ago
  https://futurism.com https://futurism.com is using it too, but we're about to move to 2.0 :)
sridca 7y ago
Dumb question: is this specific to the JavaScript system? How does it relate to using Nix for development?
- mindrun 7y 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 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...)
- kreetx 7y 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 7y 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 7y 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.
- pcr910303 7y 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’.
- simonw 7y 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 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.
2kballs 7y 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 https://zeroserver.io [1] https://1mb.site/ https://1mb.site/
pcr910303 7y 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 7y 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.
  - pcr910303 7y ago
    Oh, Mu intent was to express my own opinion. Looks like our opinions line up :-)
youeseh 7y 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 https://github.com/vishaldpatel/rust_lambda_sam_local .. hopefully it'll save you some time =).
- kkarakk 7y ago
  >Prerequisites: >- Newer installation of Rust, probably. does not instill confidence
  - youeseh 7y ago
    Well, I don't know if it'd work with an older version. I just got into the Rust game ;).
eoinmurray92 7y 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-js-app~60bbbfa1-e38c-4314-b8c7-7df3cc3db08e https://spectrum.chat/zeit/now/slow-response-times-for-node-... [2] https://spectrum.chat/zeit/now/latency-discrepancy-between-now-and-ec2~2b2562a9-2807-43f2-bbbe-eb40fcc6e7c6 https://spectrum.chat/zeit/now/latency-discrepancy-between-n...
- cgijoe 7y ago
  For those who needed to look it up like me, it stands for "Time to First Byte". #SavedYouAGoogle :)
- asien 7y 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 https://github.com/zeit/now-cli/issues/592
- danr4 7y 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 7y ago
  This has been improved massively with Now 2.0. Feel free to do any benchmarks on it!
sbussard 7y ago
Cool! Did you steal this from TJ too?
factsaresacred 7y 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.
- mindrun 7y 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 7y 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.
- mindrun 7y 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 7y 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.
- mindrun 7y 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 https://zeit.co/feedback/dev
mvindahl 7y 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.
- mindrun 7y 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.

273 points by styfle 7y 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 7y 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.
siquick 7y 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 7y ago
How does Next.js compare to Gatsby?
- freedomben 7y 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.
  - mayank 7y ago
    You could trigger that sync script from a git hook.
    - ohadpr 7y ago
      Or you could have Netlify handle build+deploy+host for you
- armandososa 7y 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.
  - DariusRucker 7y ago
    Wouldn't it be the other way around? Gatsby for static brochure sites and next.js for something requiring dynamic content?
- siquick 7y 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/ https://coffeencoding.com/cra-vs-next-js-vs-gatsby/

nailer 7y ago

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 7y ago
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".

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

mindrun 7y ago
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.

peterwwillis 7y 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 7y 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 7y 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)
- peterwwillis 7y 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.
  - justasitsounds 7y ago
    Genuinely interested to hear/read these use cases. I'm using a serverless stack at the moment (AWS Api GW + Lambda), and after the initial headaches of wrestling with Cloudformation it's been relatively simple and performant

dewiz 7y ago

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

paxys 7y ago
Yes, for one it hosts your code on the internet.

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

vbezhenar 7y ago
You can't do that with Java. There are some workarounds, but generally people restart application to check changes.
- rubyn00bie 7y 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.
  - vbezhenar 7y ago
    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 7y ago
      > 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.

esdott 7y 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 7y ago
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 7y ago
  Apex Up is a similar service: https://github.com/apex/up/ https://github.com/apex/up/
mindrun 7y 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 7y ago
https://futurism.com https://futurism.com is using it too, but we're about to move to 2.0 :)

sridca 7y ago

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

mindrun 7y 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 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...)
kreetx 7y 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 7y 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 7y 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.
pcr910303 7y 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’.
simonw 7y 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 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.

2kballs 7y 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 https://zeroserver.io [1] https://1mb.site/ https://1mb.site/

pcr910303 7y 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 7y 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.
- pcr910303 7y ago
  Oh, Mu intent was to express my own opinion. Looks like our opinions line up :-)

youeseh 7y 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 https://github.com/vishaldpatel/rust_lambda_sam_local .. hopefully it'll save you some time =).

kkarakk 7y ago
>Prerequisites: >- Newer installation of Rust, probably. does not instill confidence
- youeseh 7y ago
  Well, I don't know if it'd work with an older version. I just got into the Rust game ;).

eoinmurray92 7y 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-js-app~60bbbfa1-e38c-4314-b8c7-7df3cc3db08e https://spectrum.chat/zeit/now/slow-response-times-for-node-... [2] https://spectrum.chat/zeit/now/latency-discrepancy-between-now-and-ec2~2b2562a9-2807-43f2-bbbe-eb40fcc6e7c6 https://spectrum.chat/zeit/now/latency-discrepancy-between-n...

cgijoe 7y ago
For those who needed to look it up like me, it stands for "Time to First Byte". #SavedYouAGoogle :)
asien 7y 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 https://github.com/zeit/now-cli/issues/592
danr4 7y 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 7y ago
This has been improved massively with Now 2.0. Feel free to do any benchmarks on it!

sbussard 7y ago

Cool! Did you steal this from TJ too?

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

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

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

mindrun 7y 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 https://zeit.co/feedback/dev

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

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