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).
Structures are useful - I'm actually a lot more comfortable putting things in MongoDB when I know they're coming from a strongly typed language than if they're coming from Javascript, because that way I know they've gone through a rigid "schema" at some point. But I don't think SQL's very limited datatypes are the best way to express the constraints on a typical business object. What I'd really like is a database that stored object instances, in a language that made a type-level distinction between serializable/value objects and non-serializable objects (one of those projects I keep meaning to do is the design of such a language). ZODB tried to do this in python, but it'd be far more useful in something strongly typed - I've heard Google have had some success with storing protobuf objects directly in a database? The protobuf schema is rigid enough to provide the kind of guarantees you get with SQL, but a lot easier to map domain objects onto.
Which really sums up the advantage of MongoDB to me - JSON is a more natural fit for domain objects than SQL tables.
They're very limited compared to what you'd get in a real programming language. The fact that the language needs to define types for so many things is actually a demonstration of this - the reason postgres has built-in types for things like IP addresses or line segments is because it's too hard for users to implement such things themselves and very little notion of library code.
Again, you haven't used Postgres very much if you think that. IP addresses are in there because they are generally useful, not because they're hard to implement.
Go have a look at the complex number implementation here: http://www.postgresql.org/docs/9.1/static/xtypes.html then come back and tell me that Postgres is "not a real programming language" (whatever that means these days).
With MongoDB/Mongoose there absolutely are types and structures. Schemas have structure and types for their fields, all of which can be enforced, validated and brought together for non-trivial querying. Just because its DO/NoSQL doesn't mean there's no structure.
Umm .., no .. if you have a large number of tables and need ACID compliance, I've found ORMs to be horrid. They hide a lot of details, which cause massive performance headaches later on.
I just noticed you said almost. Maybe this is the exceptional case you were thinking of :)
With MongoDB/Mongoose there absolutely are types and structures.
Most applications grow to the point that they have multiple database clients (it is a virtual inevitability).
Utilities that have to do something. Integration points. Etc.
In an ideal world these can all be completely tunneled through an API, but that is seldom the practice (different needs, different maintenance cycles, etc), whether in a RDBMS or a document model.
Above and beyond that, most applications see technical variations and evolutions of the things that contact it. Today you might be enamored with nodejs, tomorrow it's Go, and the next day it's noderust, etc. Having a technology-coupled surrogate for basic database functionality isn't a sustainable approach.
Mongoose mainly just provides a handy programmatic API in Node.JS to native MongoDB features. The querying power and types/structure (derived mainly from its inherent JSON-ness admittedly) are part of MongoDB, not the software around it.
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.
>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.
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.
What about using an ORM? In Symfony2 for instance, we only think about objects, and they are magically mapped into MySQL or PostgreSQL tables by Doctrine2.
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.
Agreed. The LAMP stack did not become ubiquitous because it had a cool name, but because it was cheap and easy to build on. The name 'LAMP' was just a 'backronym' for what was already very common.
Trying to repeat the trick by coming up with another cool acronym is not a good idea.
The problem with the LAMP stack is the idea that one stack is suitable for just about any purpose. So you get developers trying to build hugely complicated algorithms with 'if' and 'for' loops in PHP and turning MySQL into an object store with ORM.
Better to use the right tool for the job, rather than the one all the cool kids are using today, or the one with the best sounding name.
We both can't foresee the future, but what makes this statement unique to this stack over another? Can't one say the same thing on any stack? What makes rails, django, php a safer bet than node / angular? The mere fact they have a longer history? Bigger community? Or the fact that we see a renaissance in JavaScript libraries in recent times?
I think it's a great stack, and with TypeScript on top, even a potentially enterprise friendly one.
Javascript libraries come and go, especially as Javascript is a tepidly developing language. It's very likely that in a few years the current crop of JS libraries will be out of date and people will have moved on to something else. Compare this to the relatively stable world of LAMP. Linux hasn't changed, nginx is popular but Apache is still the standard, databases come and go but MySQL is still here, and PHP is still quite a popular choice for web applications.
Will the MEAN stack stand the test of time? How many forgotten JS libraries litter the timeline of web development?
As a user of MEBN stack for the past 2 years, I don't see this being the case for server side JavaScript. Node will still be around, and it's hard to believe Mongo is half way through its entire lifecycle.
For browser side packages, sure, there's churn. But that's true of any web stack, and at the pace browsers develop, it's worthwhile revisiting those library choices more than once a year anyway.
I think you're getting Javascript libraries confused with Javascript frameworks. Libraries have come and gone, yes, but there is a clear standard now in jQuery, and as such it's safe to assume it can be included in a stack for a long term project. Frameworks for building complex Javascript applications, however, are relatively new to the scene. One of the major offerings will eventually become the jQuery of Javascript frameworks and become the de facto standard, safe to include in a stack for a long term project as well.
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.
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.
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 =)
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.
> 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.
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.
Sure, it's probably more prominent for someone like me who doesn't code for a day job. So it's not just limited to the context switching associated with syntax, it's the peripheral things like language / framework conventions, packaging systems, etc.
I am definitely curious about other languages, but I don't have the inclination to spend the time to learn them well enough to build something I would put on the internet. At least not when I can put together a pretty performant / scalable app with a modicum of effort using this stack.
These things may not be of much significance to a seasoned polyglot dev, but for someone who only really knows JS and is an infrastructure guy by trade, it makes a big difference :)
I think it really depends on the architecture. From my experience (js client <-> HTTP API <-> Express.js <-> Mongo), it never went further than sharing some small bits of code like validation expressions and constants between the client and the server js files. It was just to keep things DRY. I suppose it gets really interessting when you dive into server-side dom manipulation or fully integrated stacks like Meteor.
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
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
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.
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?
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.
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.
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.
Ultimately most of the technical differences boil down to a single tradeoff between performance and reliability.
In some use cases, you have many transactions against a data store that won't be modified once it is set. In a case like that, mongodb is acceptable.
In other use cases, you have more complicated transactions involving lots of separate logical units. For example, lets say you are building an inventory and order management system. Someone wants to buy a widget. You need to reduce the widget inventory and push it into a customer's order, essentially an "Atomic" operation. AFAICT there's no "simple" data model under which MongoDB can give you atomicity.
In order to make a decision, the best bet is to figure out those requirements and just try one that fits the bill.
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.
> 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.
If this were just a good article about Mongo, sure, that's fair. But I don't think "fair" can be stretched all the way to "let's not be critical of biased comparisons simply because we expect the source to be biased."
People get burned when they assume honesty and find that counterparties are dishonest. It's harder to get burned if you go into business or other intellectual relationships without expecting honesty. And I think, push come to shove, many founders will do what is necessary (no matter how unscrupulous) to keep their startup alive or to ensure the big payday, even if it comes at the price of turning back on promises or contracts with customers
I recommend you read http://www.zerohedge.com/node/13972 (the Conflicts/"Full Disclosure" Policy for zerohedge.com) as I think it captures the point very well.
It's a very good way to bring trust to your brand. If you honestly say: "This is good with <product>, this is bad with <product>". If you do that enough, and isn't afraid to say that in <particular circumstance> a competitor's product is better, you might in time be seen as something more than a salesman.
tl;dr: never underestimate "reader's tacit or criminally negligent acquiescence."
'If you honestly say: "This is good with <product>, this is bad with <product>".'
In order to evaluate the veracity of the claim, you have to try the product. And if you have to pay money to try the product to verify the claim, then it's unclear as to how many people will actually bother to verify. If you price it high enough that the number of people is zero, then you could say whatever you want without others knowing if you are being honest.
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).