Is there really no way to delete a deployment?
Now: realtime Node.js deployments
31–40 of 121 posts
Re: Now: realtime Node.js deployments
#32Earlier quoted context omitted.
Compared to other providers, there's absolutely no setup involved. No Procfiles, ports, containers, dynos, processes, instances… Just type `now` where you have a `package.json`.
This is very cool. I'm excited to use this in my next project. I like the zero setup, no fuss, secure by default features. I guess 4 more questions: 1) Does "Dynamic Realtime Scaling" mean you spin up more clusters and do load balancing automatically? 2) Can your $15/month cost cover this? Or is that what the 50GB bandwidth cap is for? 3) The nature of this service means we need to use a DB service like mLab (mongoLa…
Protip: put an extra new line between items or HN eats your line breaks :(
Re: Now: realtime Node.js deployments
#33This has a great landing page.
Re: Now: realtime Node.js deployments
#34Red Hat Openshift has a solid free tier, free SSL, git push deployments, node / ruby / python / java / php / etc., mysql / postgres, redis. Why would I use this over that? https://www.openshift.com/
Also, Openshift is only supporting Node O.10 right now...
Re: Now: realtime Node.js deployments
#35Are these zero downtime deployments?
They seem to be one-time deployments that never go away. Since there is no updating and no "down" at all, I think the answer to your question is "N/A."
But I may have it wrong. It’s a unique-seeming service, which can make the nuances hard to understand
Re: Now: realtime Node.js deployments
#36Fantastic intro write up to read in a mobile browser. Wish many products get to what matters like these in their descriptions. Interesting enough to try immediately!
Re: Now: realtime Node.js deployments
#37CEO of https://zeit.co here! Happy to answer any questions throughout the day :)
I'm curious about the differences between hosting a node app on zeit vs heroku.
Re: Now: realtime Node.js deployments
#38Earlier quoted context omitted.
Our biggest focus is `npm install` performance. We have multiple caches to make it the best possible experience for you. Every time you run `now` it's as if you had installed from scratch (including semver invalidations like ^ or ~). The focus is on reproducibility.
> Every time you run `now` it's as if you had installed from scratch (including semver invalidations like ^ or ~). The focus is on reproducibility. This is very confusing to me as these seem to be contradictory statements. Installing "from scratch" (I take this to mean, as if node_modules is an empty folder) is not a reproducible action, as all it takes is one sub-dependency releasing a new version to change your ins…
In order for you and your team to never rely on transient local state (either in the cloud or your own computer), we "start from scratch".
However, our process of starting from scratch is actually faster than running `npm install` on your own computer in many cases.
As an example, I've found myself getting into the habit of using `now` instead of `localhost`.
Re: Now: realtime Node.js deployments
#39Red Hat Openshift has a solid free tier, free SSL, git push deployments, node / ruby / python / java / php / etc., mysql / postgres, redis. Why would I use this over that? https://www.openshift.com/
I think this is a fantastic way to do code interviews who ask us to make an app n host it in a real URL for consumption. It's just one use case that can immediately think of.
Re: Now: realtime Node.js deployments
#40Red Hat Openshift has a solid free tier, free SSL, git push deployments, node / ruby / python / java / php / etc., mysql / postgres, redis. Why would I use this over that? https://www.openshift.com/
Also, Openshift is only supporting Node O.10 right now...
Valid point, but there is a fairly robust open source community that provides many more packages (called cartridges in openshift lingo) than are officially supported [0]
[0] https://github.com/icflorescu/openshift-cartridge-nodejs