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 name transfers during the leftpad debacle, but there's just something weird about reusing package names for totally different projects...
> 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 support."
seems susceptible to social engineering. All it takes is for one heavily depended upon package to become compromised by a malicious actor, and the entire dependency graph is poisoned.
I'm not sure of a great solution, but it really makes you question the soundness of the NPM ecosystem.
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..
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.
There should be at least some warning on the page that an earlier project with similar name was replaced with this package.
People make fun of Java's namespace conventions [1], but it goes to show the advantages of not having to have a central authority to decide on these matters.
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'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)
For PHP, you upload index.php, go to yoursite.com/index.php, and it works. Node isn't like that at all. For example, here's the "Hello World" guide for getting Node started:
That's not inherent to PHP. It's just how most hosts are set up. The only major difference is the order in which things are done (and the necessity to have shell access to the host.)
The real comparison is this:
# PHP #
1. Install a server
2. (Possibly optional) Install a process manager
3. (Possibly optional) Configure the process manager
4. Configure the server
5. Start the server
6. Upload files
# Node #
1. Install Node
2. Upload files
3. Start the server
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.
Red 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?
This seems like a different use case than those solutions. This is if you're working on a project and you want to share the state of what you're working on across the net. Think of it like a point-in-time disposable link shortner but for a full node app.
Actually, I think the issue is that you just don't understand the meaning of those words.
The "rich module ecosystem" he is speaking of refers to npm. With node and npm it is trivial to install a few modules from the command line, write up a custom server, and very quickly have yourself a dynamic web page or API.
The "realtime JavaScript cloud" is basically any node application running on a service like Heroku or with any number of hosts and providers ranging from self-managed VPNs to esoteric AWS services. Applications that run on this realtime JavaScript cloud are incredibly portable as engines can be fired up and torn down very quickly across both server-side and client-side environments.
This service that he has been a part of creating does exactly this. It empowers the user by streamlining existing development processes.
I would say that his sentence is rather meaningful contemporary industry jargon.
I do understand them exactly the way you explained.
However, they're still a buzzwordful, dodging, non-answer to the relative parents' very simple question. They're a reiteration of the most basic, marketing-level bulletpoints on why node.js and microservices are so wonderful! that barely scratch the surface of real-world software complexity.
I'm gonna go further: that is actually a fantastic mission statement!
I believe that it is very important to have goals that are simple in definition. It can really help the cause if the ultimate meaning is somewhat allusive. The act of interpreting the mission statement bakes in a dynamic element that can help keep an organization from getting stuck in place.
That I can interpret this mission statement in a verbose, complicated and applied manner is an example of its utility.
How are you thinking about latency in an environment where there's a waterfall of Now function calls? Will Now functions calling over Now functions naturally get cached on the same server?
There's no explicit concept of "now functions". You simply deploy HTTP/2 services to the cloud.
HTTP/2 significantly improves performance by introducing multiplexing and header compression. There's no need to introduce new concepts or APIs. REST away!
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.
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]
Any chance of some clarification around the limits of the free tier?
> 20 FREE deploys per month
So I can only run the `now` command 20 times each month? What are you using to track how many times I've run it already? IP? NPM username? Package name?
>1MB size limit per file
Is this at deployment time or is this also enforced at runtime? If I deploy a 900kb sqlite file, then add 200kb of records to it at runtime, what's going to happen?
> Perfect for open-source demos, classrooms, tutorials & testing.
Are 20 deploys per month really enough to use in a teaching context? I'd love to use this tool in the web tech module I teach at my university, but I think most students would burn through 20 deploys in a week, let alone a month. Is there any chance this limit could be re-thought for teaching purposes?
I wouldn't mind if some of the other restrictions were changed, but free tiers that halt development til the start of next month don't sound great for learning to me.
Really cool website! I'm confused though exactly what is going on. Is this kind of like Heroku? What are the pros and cons of this service? For context, I'm currently running a production node/express/mongo service on Digital Ocean.
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`.
How is there no port? I have to run my server on some port, are you saying I can choose whatever my port I want and your service detects that somehow? I don't need to use process.env.PORT ?
Curious about performance of npm install, seems like it's one thing that could make it not so snappy. For compiled modules, does it have a decent amount of memory/CPU on the instances? How about connectivity? Does it use a mirror for NPM? Might it in the future?
> 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 installation.
Can you clarify what you mean and resolve this seeming paradox?
This doesn't address the poster's issue: If you reinstall every time, the results won't always be the same (not that I personally hold this as a big issue, I'd consider it on the programmer to freeze their package.json)
I think it's "reproducible" in the sense that it starts from scratch every time, rather than sometimes starting from scratch, and other times starting with a pre-populated node_modules. If you want actual versioning reproducibility, you'll need to put an npm-shrinkwrap.json in your root.
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`, especially without shrinkwrap -- and `now` doesn't seem to be using shrinkwrap -- will never get there.)
I’m still not 100% if I get what they are doing or not.
After all, I need some sort of index.js or dist/foo.js in my package, and if they aren’t using git or anything, then isn’t this by definition happening based on transient local state (my local files at `now`-time)?
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 there are devs who are interested, but maybe not interested enough to buy into terminology like "dynos" or "cartridges" or "lambdas". "Ocean" in the sense that there are (supposedly) quite a few of these people.
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?
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.
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
(1) I notice that your pricing chart mentions storage. I'm wondering what that typically would consist of? Only thing I can think of are static assets as I imagine a codebase — even with a million npm module dependencies — wouldn't come close to 1GB let alone 100.
(2) Is it possible to back your apps with a database/datastore? Say I want to use MongoDB with my app. Would I need to purchase a third party service and set the MONGO_URL in the env? Are there any plans to offer database services as add-ons?
The pricing structure is missing a couple of middle tiers and overall the service lacks useful features. For instance: I could buy a $5/mo droplet in Digital Ocean, one click install node, even use my own domain and manage deployments/restarts almost as easy. For that money I get 1TB transfer and 20GB ssd and many more features (b/c I basically get a VPS where I can do whatever). It takes me 10 min to setup the server and zero minutes to deploy each new version (I use deploybot so every git push is really a deployment).
Some things are not clear:
"Dynamic realtime scaling" Forever? Unlimited? Say 1MM concurrent API calls for $15/mo?
URLs change after each deployment? Do I need to update endpoints on all clients?
Off topic: Right when I saw the terminal, I instinctively typed "ls". Not sure now if that's what triggered the animation or not but regardless it was a neat occurrence (I also just want to leave it at that ;) ) Yayy muscle memory!
What makes the deployment "realtime"? Is it just that you get terminal output of the deploy happening? That's been around for a while now. Or am I missing something?
This looks very promising for the node community. I was wondering which cloud infrastructure service they went with to power this. According to the FAQ, they don't rely on just one. Very cool, and if implemented correctly, more resilient.
Multi-cloud.
We don't depend on a single specific cloud provider, but abstract them instead.
P.S. Is the markdown parsing broken on the FAQ? Or is that part of the look they're going for?
Does this support native modules and is it running on Linux 64?
If so it'd be an interesting "hack" to have it run arbitrary code. You could have the default "npm run" script download a python/ruby/golang/foobar runtime and kick start an app on the expected port.
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
No. For zero downtime deployments on AWS with blue/green deployments behind EIPs & ELBs, we at Boxfuse (https://boxfuse.com) offer a very easy solution for both Node.js and JVM apps based on immutable infrastructure.
Very cool! I was just saying how hard it is to get someone to deploy a quick node app. Trying it with a React + Express app right now. Taking a while to deploy but I assume you are getting hammered.
Once you've done it once it is very quick imo. Deploy 1 to Digital Ocean with Node/Express/Mongo took me a work-night and deploy 2 and 3 took me < 15 minutes.
You don't really mention this in the pricing section but I assume for the paid plan, it gives you the option to hide the /_src feature based on something (IP, etc.)?
Looks neat for demo apps. I did try it out on one of my simpler express based apps and it failed during the npm install. Looks like this is possibly using ied?
Seems cool.
After many years on node, and even writing a deployment service once (paastor) - just plain VPS, nar to make an executable, then scp onto an Ubuntu server, and scp a logrotate and upstart conf - that's all you need man.
No, it doesn’t. Elements of it are great. The design screams “We’re programmers too,” which is great. But as the comments on this page attest, this landing page does a simply horrible job of introducing what `now` actually does.
Fantastic 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!
That you can't see how much of a dick you're being when you accuse someone of playing "buzzword bingo" is proof to me that you can't be anything but a god damned troll. This isn't about having different viewpoints. This is about you objectively being an asshole.
Edit: Sorry, TRIGGER WARNING: Real things are being said.
If I were accused of buzzword bingo, i'd try to take it as good-natured criticism that what I said was perhaps a little too filled with lingo to have a solid meaning.
It's certainly possible to read this example as a trollish remark, there's also a perfectly valid reading which interprets it as an attempt to provide useful feedback. Since I assume neither of us knows q3k, we're not in a position to know which is true, except for q3k telling us.
It becomes pretty clear that it's not a troll when one puts his/her best-effort to interpret "realtime JavaScript cloud". It's a critic with a very obvious point.
Oh yeah Einstein, what's the point he's trying to make then?
God, this forum is just like 100% assholes these days. You can't even fucking see it either, can you? When was the last time you interacted with normal people in society? Did you just start out with bitter criticism and attacking their vocabulary?
This is way over the line of what we ban people for. I don't want it to seem personal (it isn't), so won't ban you, but if you keep doing this we'll have to.
The rule is "Be civil" and it applies regardless of what you think other people are doing.
I honestly think we should hash this out in person. I live in Bernal Heights in San Francisco. My email address is williamcotton@gmail.com - I'd love to buy you a coffee and a scone and talk about how differing cultures and classes in America have different definitions of "being civil".
I'm like a living Rosetta Stone for rednecks and yuppies. I guarantee you'll spend most of your time laughing and that you'll leave with a giant smile. Hell, I might even bring my guitar along and pick a few songs out for you!
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 name transfers during the leftpad debacle, but there's just something weird about reusing package names for totally different projects...