Now: realtime Node.js deployments(zeit.co) |
Now: realtime Node.js deployments(zeit.co) |
Edit: Sorry, TRIGGER WARNING: Real things are being said.
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.
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?
We all get how encountering wrongness and badness on the internet can put one on tilt, and we've all been there, but it's necessary to stop.
I'm not repeating those behaviors at all. I'm just calling a spade a spade.
You seem to think that someone who picks a fight with a bully is somehow guilty of also being a bully.
All you end up doing is passive-aggressively condoning their bullshit behavior in the first place.
I'm guilty of being nothing more than a fed up son of a bitch with a rude attitude. I can live with that.
You're morally bankrupt. Can you live with that?
The rule is "Be civil" and it applies regardless of what you think other people are doing.
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...
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.
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.
https://docs.oracle.com/javase/tutorial/java/package/namingp...
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)
> 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.
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?
Mmmmmmmmmmmmmm not a CDN.
Does this mean you forward port 80/443 to whatever port the app is listening on, or I can have my app listen on random external ports?
Multi-cloud.
We don't depend on a single specific cloud provider, but abstract them instead.
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.
But I may have it wrong. It’s a unique-seeming service, which can make the nuances hard to understand
You manage "upgrades" by changing pointers (aliases and DNS). We'll be exploring this in upcoming posts.
But I wish they would clarify this, either way.
With the advent of microservices, code will become more succinct. Your backends will be aggregations of small functions with clear inputs and outputs.
The syntactic differences between languages will matter less. Our bet is that JS has the largest and most prolific community!
I'm sorry, but that's just meaningless buzzword bingo.
[0] https://github.com/icflorescu/openshift-cartridge-nodejs
Docs here: https://blog.openshift.com/any-version-of-nodejs-you-want-in...
> 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.
Every time you run `now` it's as if you had installed from scratch (including semver invalidations like ^ or ~). The focus is on reproducibility.
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.
(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?
HTTP/2 significantly improves performance by introducing multiplexing and header compression. There's no need to introduce new concepts or APIs. REST away!
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
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.
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 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.
https://www.digitalocean.com/community/tutorials/how-to-set-...
This is basically the problem `now` is solving... "what if Node was as easy as PHP?"
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
Why not just buy a VPS and set it up yourself, it's just more convenient for some people.
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 (mongoLab) or run our own DB server right?
4) What about production logs?
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?
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`.
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 haven’t kept my personal site up with no linkrot for the past 10 years by making technology choices on a whim, you know?