So the hip software stack of 2014 supports no concurrency or very limited concurrency on each and every level. Have people given up on actually using their hardware? Are we content running our software on Pentiums, taking comfort in the fact that we can cram a few of those into a single box?
> So the hip software stack of 2014 supports no concurrency or very limited concurrency on each and every level.
NodeJS's asynchronous approach is a concurrency (but not parallelism) approach. Your reference to "Pentiums" (which I assume is intended to be a reference to single-core nodes) suggests that your concern is actually with parallelism rather than concurrency.
But, sure, a not uncommon usage pattern for an IaaS like GCE might be to have lots of single-core nodes cooperating, rather than running individual processes on larger nodes with lots of parallel threads.
Excellent question. The MEAN stack certainly doesn't seem to be badly oversold. It is, in fact, usually mentioned as being best-suited for specific types of applications, not as a general panacea.
Then there are the speed/performance tests, which seems to place MEAN at or near the top as compared to the other mainstream web app stacks, which begs the question: is it possible that snide comments about "concurrency" are utterly beside the point? Who cares if my hoopty car looks inelegant if it wins the race?
Well, winning races is nice, but so are things like scalability and reliability. These pages are no stranger to criticism of MongoDB's fault tolerance semantics, or the notorious difficulty it has scaling to sizes as small as, say, 100 gigabytes. Even aside from fault-tolerance concerns, mmap()'d linked lists of BSON documents and a few B-trees certainly have the potential to be a snazzy enough little foundation for some projects, but will only get you so far.
Good stuff. That's what I like. I've got a lot to learn, and it's better if I get real info and not empty rhetoric.
As simply a learning tool for someone who is immersed in a .NET + jQuery stack every day, how does MEAN compare? I disliked Rails, fwiw. And since I'm becoming reasonably fluent in JavaScript, it seemed intuitive that building my own site from the Node-ground up wouldn't be a bad idea, purely for a learning exercise. Struggling through it right now, actually.
Can't be much slower than PHP or Ruby, so theres that. What is repelling to me is callback-hell and Javascript as a language in general. People will build simple stuff with this, then it will evolve, and then someone will have to deal with it. I don't want to be that guy.
The concept is good, even though javascript is awful. I'm more in the direction of a Riak/Webmachine/Ember-Angular-Backbone-Batman-Knockout-Whocares/Erlang stack, though. There are many ways to execute pretty much the same thing as MEAN and avoid Node/Mongo, and new tooling on legacy projects to support the MEAN stack will inevitably also support other methods because that client-services model is so decoupled.
It's really not fair to call single cores Pentiums, I had the dual-core Pentium D once upon a time and the Core 2 was a huge improvement. We're now 4 generations on from the Pentium.
This is on Google Compute Engine, not Google App Engine. It's not straight forward to me what GCE is a good fit for^1. Can someone explain in layman terms?
Based on the name, I'd think it be for long running concurrent algorithms that require many resources, but the M of MEAN is throwing me off. Why do you need a persistence layer? Is it to load the data for input? To store the data as output? Is it for anything you want? If the latter, why can't I use this exactly as I'd use GAE?
> It's not straight forward to me what GCE is a good fit for^1. Can someone explain in layman terms?
GCE is a pretty standard IaaS offering, like Amazon EC2.
> Based on the name, I'd think it be for long running concurrent algorithms that require many resources
There's lots of things an IaaS like GCE can be good for; what you are doing with it will determine what size instances you use, and what options you use with them. Certainly, that's one thing GCE could be used for.
But an open IaaS like GCE or EC2 is designed to be a general purpose on-demand dynamically-allocatable server solution, so anything you can use a general purpose server for is an in-scope use of the IaaS.
> If the latter, why can't I use this exactly as I'd use GAE?
You can. An IaaS like GCE is lower level tool on which, with an appropriate software stack loaded (which MEAN might be), you can use the system basically like a PaaS like GAE. The difference is that a PaaS already comes with a particular software stack included, rather than requiring you to bring your own (that's the "platform" in the "platform as a service".)
I checked it out myself and you can decide for yourself which type of instance you want to deploy. The default was micro (the cheapest) and 3 nodes.
Cited from the setup page:
This interface allows you to deploy one or more MongoDB server nodes and one or more arbiter nodes as part of a single MongoDB replica set. By default the replica set will contain 2 data-bearing server nodes and 1 arbiter node.
A short-lived "Deployment Coordinator" Compute Engine instance will be created to manage instance setup.
Are they intending this is used for development only? I see numerous places where they remind you to delete your app when done, but nothing about what to do when you want to deploy for production?
Yea, it's kind of odd they don't explain some of these things in more detail on their site. If they do then maybe I'll invest some time playing around with it
Looks like you can’t try it out without setting up billing first -.- (I’m not in the mood for setting up financial stuff now \yawn\ \drinks a sip of coffee\)