

The MEAN Stack: MongoDB, ExpressJS, AngularJS and Node.js - c-oreills
http://blog.mongodb.org/post/49262866911/the-mean-stack-mongodb-expressjs-angularjs-and

======
bsaul
I really don't understand this no-sql everywhere trend. Types and structure
definitions ARE useful. There are times when you may find them cumbersome, but
most of time they're not (especially when working in teams). The more i think
about it, the more i think my ideal stack would be this :

Postrgesql with no-sql extensions ( for when you may need flexibility), typed
python or typescript or dart( or any language with optionnal typing) on the
server, and typescripted js lib on the frontend I'd call it the Optional
Typing Stack ( but ots isn't nearly as good as "mean" i must say).

~~~
threeseed
Of course types and structures are useful but why do I need it in my database
as well as in my app ? That's one reason databases like MongoDB have become
popular because you can deal exclusively with your domain model and treat the
database like an object store.

So you still have everything structured but not have to worry about annoying
migrations.

~~~
joshmaker
>Of course types and structures are useful but why do I need it in my database
as well as in my app ?

Do you write bug free code 100% of the time? I'm pretty good, but I definitely
don't. And when there are bugs in my code, I'm grateful for a RDBMS with
enforced referential integrity.

I've also had to work on projects where the initial codebase was scrapped all
together. When that's happened I've found having the data in clearly defined
columns and relationships immensely useful.

~~~
threeseed
I have unit tests around my domain model so just as confident as I would be if
I was using an ORM library. With the advantage of course of not having to
worry about yet another library to manage especially working on mainly Java
apps.

And like many are doing these days I do all my joins in my app so that I have
the flexibility of moving objects into more appropriate storage mediums e.g.
Redis or Solr without major refactoring.

I am not dismissing the benefits of having business rules in the database only
that they aren't always necessary.

------
RyanZAG
The real problem with this MEAN stack for any real project is maintainability
in 5 years time. You can almost guarantee that within 2 years, this stack will
be semi-unsupported in favor of a newer JS library, with all the current devs
and support on this stack jumping ship to better versions.

That said, this is a very awesome stack to use for hackathons and short
projects or prototypes.

~~~
marknutter
jQuery has been a pretty safe bet for years. There's no reason why one of
these Javascript frameworks won't also become a safe bet as well.

~~~
hackerboos
Angular maybe but Express? Even the longevity of Node is a gamble in my
opinion.

~~~
tg3
From Express's package page on NPM:

20 765 downloads in the last day 127 921 downloads in the last week 489 285
downloads in the last month

Since it's essentially Sinatra for Node.js, I don't think it's too big of a
stretch to say that it will be a part of the stack for some time.

I would say longer than Angular, as browser-side packages seem to have more
churn on the basis of adoption of newer browser features.

------
corresation
_A few weeks ago, a friend of mine asked me for help with PostgreSQL. As
someone who’s been blissfully SQL-­free for a year, I was quite curious to
find out why he wasn’t just using MongoDB instead._

The lead in seriously harms the technical credibility of the rest of the
entry.

~~~
angstrom
Having done a large personalization project (25 million+ users) with Mongo as
a proof of concept I tend to agree. It's great for small POC, but it still has
problems under large applications. We took tailored our data collections to
take advantage of memory locality, but for that project it wasn't a good fit.
I'm more interested in Hyperdex at this point. Mongo is great for getting
something up and running quickly.

~~~
corresation
MongoDB is very suitable for some tasks (though it has the inevitable young
product edge issues that early adopters get to enjoy), but my core issue with
the lead-in is that the author sounds like the _problem_ with NoSQL, which is
the "everything is a nail, here is my hammer" mentality, assuming that
products like MongoDB are the successors of RDBMS', when that is absolutely
not true. They are different tools for different purposes.

~~~
tomsthumb
What are the different purposes, and how do I know that have have one versus
the other, versus another, etc?

~~~
vec
SQL databases are strongly typed and extremely good at enforcing consistency,
whether you want them to or not. They are quite good at preventing many
classes of bad data from being recorded in the first place, and allow you to
do some types of low level data manipulation (joining datasets, eliminating
duplicates, finding mins and maxes, etc) extremely efficiently.

NoSQL, on the other hand, is weakly typed and makes few if any attempts to
validate your data, pushing that responsibility back onto you. They are very
well suited to storing inherently inconsistent data (which, as a corollary,
makes them very good for prototyping, when your data model is rapidly changing
and growing). They also allow you to link much larger datasets into a
'document' which is retrieved as a unit with no extra computation.

So it mostly boils down to what kind of data you want to store. If you find
yourself almost exclusively saying things like "All users have a username that
is a string" or "I want to be able to find all products that cost less than
$20" then you're probably looking for a traditional SQL database. If, on the
other hand, you find yourself saying "some products have a width and height,
but some just have a height, and a few have a volume instead" or "I want to be
able to add custom fields to products on the fly" or "I never want to see
purchases on their own, I always want to see them joined to the user that
bought them" then you should probably consider a NoSQL solution.

~~~
tomsthumb
> SQL databases are strongly typed and extremely good at enforcing
> consistency, whether you want them to or not. They are quite good at
> preventing many classes of bad data from being recorded in the first place

>NoSQL, on the other hand, is weakly typed and makes few if any attempts to
validate your data, pushing that responsibility back onto you. They are very
well suited to storing inherently inconsistent data

Actually, I've had to deal with that first hand. It gets particularly nasty
when multiple languages with varying type-tightness interact with the same
data.

It's nice to hear someone else put this into words.

------
brasetvik
The NNN Stack: NoJS (Python, Twisted, Cyclone), NoNoSQL (PostgreSQL) and NoSQL
(Elasticsearch).

~~~
bentaber
And you're going to write your front end logic in what?

~~~
niggler
One of the many compile-to-JS languages. Or just using emscripten.

------
VeejayRampay
MEAN or how to be redundant in the elements of your stack (Express.js is
already a Node.js framework) just so that the acronym were somewhat sexy.

------
vkarpov207
Hi all,

Author of the post here. Thanks for the excellent discussion, this is a very
interesting read. Let me make a few comments re: some of the more interesting
points I've read.

1) I love Redis, but in my book, if you're already using MongoDB, its more of
a tool for reducing latencies once you're looking to scale. If I'm just
looking to prototype I'll probably use one or the other, but not both. I love
the MEANR / MEANER acronym though, but I can't support the EJS decision, I'm
all about Jade =)

2) AngularJS not good for hackathons? Sounds like a subject for another post.
Granted it may be that I'm just extremely biased towards Angular, I was an
intern with the Google team that developed it in '08 and I've been using it
since v0.9.9. However, I find Angular's slick two-way data-binding to be
completely indispensable for building a prototype. There are two primary
reasons for this, first I find the paradigm of writing Javascript which
explicitly references the DOM to be brittle, and second it makes life easier
for my designer because he never has to worry about breaking the frontend
Javascript.

3) I agree that Javascript is a rapidly developing language and many of the
tools that I use may well be obsolete within a few years. However, I think
that I benefit from using the tools that I believe are best in the meantime,
and when better tools are released, then we'll change along with them.

Thanks again for the commentary, I really appreciate it. I'll be coming out
with a few more posts in the near future, please be on the lookout =)

------
throwaway1979
This is funny. After using Angularjs at the recent techcrunch disrupt ny
hackathon, I was mulling over writing a post that said Angularjs is not good
for hackathons! To be clear, I am a newbie and am very impressed with
Angularjs. That said, debugging Angularjs for a newbie is a nightmare. It was
very brittle in our experience. Likely, this is because both my hackathon
colleague and myself had less than a week's experience with Angularjs. We
found that it was easy to find simple examples online, going to an actual app
was VERY non-trivial.

~~~
jbdeboer
What sort of debugging problems did you run into?

~~~
throwaway1979
Stuff just wouldn't work :p (sorry ... I know this is first year CS grad speak
but I can't describe it better than this) In the model view of batarang, I'd
just see a bunch of scopes with nothing in there. Clearly, exploratory
programming isn't a good idea.

------
sturadnidge
I recently built a HN clone (for a much smaller community) using exactly this.
As a solo / moonlit act, staying in a single language had huge benefits for
me.

But I don't see the point of using an ORM with MongoDB... not saying ORMs are
bad, I just don't think they have much to offer when there is no SQL to
abstract and when you're doing everything in JSON anyway (in this stack). If
I'm missing something, happy to be enlightened.

~~~
derefr
> As a solo / moonlit act, staying in a single language had huge benefits for
> me.

As someone who spends each day switching between Erlang, Ruby, Javascript and
sometimes C (with various infrastructure components also requiring bits of
Java or Go) I find a the idea of a one-language stack sort of mindblowing
(though I've always sort of fantasized about connecting my Erlang servers
directly to an Erlang VM running in the browser over the distribution
protocol.)

Would you mind expanding on those "huge benefits", as you've actually
experienced them? I've only ever really seen people describing theoretical
benefits they imagine they might see if they did this, but nothing from anyone
who has.

~~~
muyuu
If you require expertise in 3-4 languages for a project, hiring becomes A LOT
harder. And so does code review and assessment. Never mind the learning curve,
attack surfaces, etc.

------
xsace
Nice acronym, I use that stack + Redis. Need to find something else starting
with E then I can brag about the MEANER stack.

~~~
soulclap
RAMEN!

~~~
jonhmchan
Genius.

------
dkhenry
The MongoDB/AngularJS combination is really good enough on its own that you
can shove most Language+Toolkits in there and have something together real
fast I have use the following and its worked great each time

    
    
        MongoDB + Flask + Angular + Python 
        MongoDB + Play + Angular + Scala

~~~
quarterto
You should call it Scala + Play + Angular + Mongo. The SPAM stack.

~~~
cpursley
Congratulations, you won.

------
alexhancock
You can bring even more value to the table in terms of interoperability if you
have the mongo api implemented on the client. No more looking at a different
set of docs (backbone/angular/spine/ember/etc...) to figure out how to query
the cache on the client differently than you do on the server.

The meteor guys have implemented this logic in a package called minimongo:
<http://bit.ly/YmS3Y1>

------
bjhoops1
I've been working with a similar stack lately: MongoDB, ExpressJS, Node and
Backbone/Marionette (Sorry, no snappy acronym). I've found it to be remarkably
productive and would recommend giving it a try. Also, it's a lot of fun! If
you're using Backbone (and apparently everyone is), you would do well to layer
some structure on it with a framework like Marionette or Chaplin.

------
codewright
Would be great if not for the CPS. I end up doing something similar except
with Clojure instead of Node.js for my projects lately.

~~~
egeozcan
I'm currently a developer on the MEAN stack. Do you know of an example project
where Node.js, or maybe even the client side js is replaced with Clojure?

~~~
arianvanp
Clojurescript clientside. Noir serverside. <http://www.chris-
granger.com/projects/noir/> <https://github.com/clojure/clojurescript>

you could also use clojurescript serverside using node.js. this is what
LightTable does iirc <http://www.chris-granger.com/lighttable/>

~~~
ConstantineXVI
Be aware, Noir is deprecated: <http://blog.raynes.me/blog/2012/12/13/moving-
away-from-noir/>

