Live data from Hacker News

Now: realtime Node.js deployments

zeit.co

91–100 of 121 posts

Re: Now: realtime Node.js deployments

#91
post #65

I used to use a project called now on npm that was abandoned a few years ago ( https://github.com/Flotype/now ). I was curious how this new project was using the same name on npm as the previous now that I had used. Looking at the npm release history, versions <= 0.8.1 are the old project, and the new project picked up at 0.9.0 (should have been 1.0.0 I guess). This is consistent with npm's statements about package n…

> but there's just something weird about reusing package names for totally different projects... Not only is it weird but it is inherently insecure. Even NPM's solution: > "If a package with known dependents is completely unpublished, we’ll replace that package with a placeholder package that prevents immediate adoption of that name. It will still be possible to get the name of an abandoned package by contacting npm…

I really see no good reason not to employ namespacing with immutable packages. If a package is dropped, all is well still. If readoption is needed, people can use the new package, similarly named. It obviously also allows for similar but different named packages to exist, which I don't see as a problem. I can usually find the top repo on github for instance, even with multiple forks. I worry about Rust since they have decided against namespacing, even though some suggested otherwise, early on..

Re: Now: realtime Node.js deployments

#92

Had to read three pages and still haven't quite confirmed that this is node.js hosting. But based on the pricing page, I guess it is. Can you please just say that? Just say "It's node hosting and the deployment system is fast." You literally just stole some of my life.

Just to piggyback for people confused:

It's zero-configuration Node hosting, for permanent lightweight microservices or temporary Node projects that need to be accessible online.

In other words, it's as close to uploading PHP files to a server that you'll get with Node.

For people wondering, the creator is Guillermo Rauch, who is behind Socket.io and LearnBoost (the company that brought us Express, Mongoose, Stylus, Jade, etc... basically the entire Node stack)

Re: Now: realtime Node.js deployments

#93

Had to read three pages and still haven't quite confirmed that this is node.js hosting. But based on the pricing page, I guess it is. Can you please just say that? Just say "It's node hosting and the deployment system is fast." You literally just stole some of my life.

it literally says "now: realtime node.js deployments" on the top on the page. > You literally just stole some of my life. he absolutely did not! You decided to spend time investigating what now is, he did not steal anything from anyone.

deployment != hosting.

Re: Now: realtime Node.js deployments

#94

Had to read three pages and still haven't quite confirmed that this is node.js hosting. But based on the pricing page, I guess it is. Can you please just say that? Just say "It's node hosting and the deployment system is fast." You literally just stole some of my life.

Just to piggyback for people confused: It's zero-configuration Node hosting, for permanent lightweight microservices or temporary Node projects that need to be accessible online. In other words, it's as close to uploading PHP files to a server that you'll get with Node. For people wondering, the creator is Guillermo Rauch, who is behind Socket.io and LearnBoost (the company that brought us Express, Mongoose, Stylus,…

Why not just upload node files to a server?

Re: Now: realtime Node.js deployments

#95

Earlier quoted context omitted.

Just to piggyback for people confused: It's zero-configuration Node hosting, for permanent lightweight microservices or temporary Node projects that need to be accessible online. In other words, it's as close to uploading PHP files to a server that you'll get with Node. For people wondering, the creator is Guillermo Rauch, who is behind Socket.io and LearnBoost (the company that brought us Express, Mongoose, Stylus,…

Why not just upload node files to a server?

I suppose you could do that, but I reckon their main selling point is convenience. Same argument can be made for any cloud hosting service.

Why not just buy a VPS and set it up yourself, it's just more convenient for some people.

Re: Now: realtime Node.js deployments

#96
post #76

Earlier quoted context omitted.

Something that’s bothering me is: Is there any way to deploy via `now` with secrets? You know: API keys or the like? `_src` is always public in the free plan and I don’t see any documentation around providing environment variables.

my guess is that for free tier, it's targeted at demo/tutorial so environment variables wouldn't be necessary. If you are serious about privacy then you have to upgrade to paid tier. But heroku does offer environment variables to free tier and it is handy for database keys and 3rd part API keys, so I guess they will add that at some point through some user-facing web interface or just cli options.

> so env variables would not be necessary

My initial thought as well — but it’s simply not true. Let's say you want to demo something that is using Firebase on the back end. You can't just give away your credentials or your demo may get very broken very quickly… and you’ll foot the bill

Re: Now: realtime Node.js deployments

#97
post #86
post #72

Earlier quoted context omitted.

I see. They shouldn’t use the word “reproducible” then, because something is either reproducible or it’s not. If they just mean, “We ignore everything but your package.json to generate a deploy,” say that, don’t mis-use the word “reproducible.” (Heroku, for example, has put a lot of effort into making deploying to their platform actually, truly, really-the-same-years-into-the-future reproducible. `npm install`, espec…

> `now` doesn't seem to be using shrinkwrap They aren't? I haven't tried a deployment, but was hoping/assuming they'd upload a shrinkwrap along with everything else and that it would drive the install as per usual. > I’m still not 100% if I get what they are doing or not. I think their angle is to lower barriers to entry close to zero for cloud deployments, and thus drain a shallow ocean. "Shallow" in the sense that…

I’m potentially one of those people, at least for personal projects and such. But I also need to understand what the hell I’m getting into before I make the leap.

I haven’t kept my personal site up with no linkrot for the past 10 years by making technology choices on a whim, you know?

Re: Now: realtime Node.js deployments

#99
post #65

I used to use a project called now on npm that was abandoned a few years ago ( https://github.com/Flotype/now ). I was curious how this new project was using the same name on npm as the previous now that I had used. Looking at the npm release history, versions <= 0.8.1 are the old project, and the new project picked up at 0.9.0 (should have been 1.0.0 I guess). This is consistent with npm's statements about package n…

> but there's just something weird about reusing package names for totally different projects... Not only is it weird but it is inherently insecure. Even NPM's solution: > "If a package with known dependents is completely unpublished, we’ll replace that package with a placeholder package that prevents immediate adoption of that name. It will still be possible to get the name of an abandoned package by contacting npm…

Needs more hashes

Re: Now: realtime Node.js deployments

#100
post #65

I used to use a project called now on npm that was abandoned a few years ago ( https://github.com/Flotype/now ). I was curious how this new project was using the same name on npm as the previous now that I had used. Looking at the npm release history, versions <= 0.8.1 are the old project, and the new project picked up at 0.9.0 (should have been 1.0.0 I guess). This is consistent with npm's statements about package n…

> but there's just something weird about reusing package names for totally different projects... Not only is it weird but it is inherently insecure. Even NPM's solution: > "If a package with known dependents is completely unpublished, we’ll replace that package with a placeholder package that prevents immediate adoption of that name. It will still be possible to get the name of an abandoned package by contacting npm…

I've had one of my package names transferred away from me with no warning, presumably after some period of inactivity. Npm as a repository seems to have gone totally insane, and I don't think I'll be publishing there anymore. I'll recommend people install my modules from a tag in the repo.
Post reply on HN