7 ms·
The MEAN Stack: MongoDB, ExpressJS, AngularJS and Node.js
- sturadnidge 13y agoI 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 13y ago> 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 13y agoIf 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.
- fla 13y agoI 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.
- sturadnidge 13y agoSure, 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 :)
- yen223 13y agoWhile I can definitely see the advantages of only having to work with one language, I really wish that one language wasn't JavaScript.
- codewright 13y agoWould 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 13y agoI'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 13y agoClojurescript clientside. Noir serverside. http://www.chris-granger.com/projects/noir/ http://www.chris-granger.com/projects/noir/ https://github.com/clojure/clojurescript 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/ http://www.chris-granger.com/lighttable/
- ConstantineXVI 13y agoBe aware, Noir is deprecated: http://blog.raynes.me/blog/2012/12/13/moving-away-from-noir/ http://blog.raynes.me/blog/2012/12/13/moving-away-from-noir/
- codewright 13y agoNoir is deprecated, use vanilla ring + libnoir or Luminus.
- codewright 13y agohttp://github.com/bitemyapp/neubite/ http://github.com/bitemyapp/neubite/ There's a CMS, for starters.
- bsaul 13y agoI 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).
- lmm 13y agoStructures 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.
- anthonyb 13y ago"very limited datatypes"? You haven't used Postgres very much, have you? http://www.postgresql.org/docs/9.2/static/datatype.html http://www.postgresql.org/docs/9.2/static/datatype.html And those are just the built-in ones, not counting PostGIS and other ones that you can define: http://www.postgresql.org/docs/9.1/static/extend-type-system.html http://www.postgresql.org/docs/9.1/static/extend-type-system...
- lmm 13y ago
- xsace 13y agoNice acronym, I use that stack + Redis. Need to find something else starting with E then I can brag about the MEANER stack.
- arunoda 13y agoMEANR would be fine
- jgj 13y agothis is the internet, you're free to omit the 2nd e and just call it MEANR. hell, http://mea.nr http://mea.nr is available.
- TheAceOfHearts 13y agoIt also costs $500 to register :(.
- soulclap 13y agoRAMEN!
- jonhmchan 13y agoGenius.
- octo_t 13y agoErlang?
- wprl 13y agoHaha I use MEBNR ... doesn't roll off the tongue!
- egeozcan 13y agoEJS templating engine, perhaps?
- dkhenry 13y agoThe 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
- RyanZAG 13y agoThe 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.
- SeanDav 13y agoPlease expand further. I would be very interested in what you base this comment on and examples of better versions for these.
- freehunter 13y agoJavascript 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?
- don_draper 13y agoRight on. That's why I'm sticking with EJB's and Oracle.
- wprl 13y agoAs 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.
- 13y ago
- brasetvik 13y agoThe NNN Stack: NoJS (Python, Twisted, Cyclone), NoNoSQL (PostgreSQL) and NoSQL (Elasticsearch).
- VeejayRampay 13y agoMEAN 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.
- corresation 13y agoA 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 13y agoHaving 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 13y agoMongoDB 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 13y agoWhat are the different purposes, and how do I know that have have one versus the other, versus another, etc?
- niggler 13y agoUltimately 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.
- throwaway1979 13y agoThis 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 13y agoWhat sort of debugging problems did you run into?
- throwaway1979 13y agoStuff 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.
- bjhoops1 13y agoI'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.
- vkarpov207 13y agoHi 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 =)
- alexhancock 13y agoYou 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 http://bit.ly/YmS3Y1