The LAMP thing
LAMP – Linux, Apache (web server), MySQL and PHP – was the go-to stack of the early web. The MEAN name evokes the spirit of LAMP but that's also a warning from the past. You see, the odd thing with LAMP was that over time, people went from treating it as a handy shorthand for a common combination of components to a baseline for development. Worse still, some got locked in on particular components to the point where the technical debt of either staying with or switching away from any component would be a long time in being paid off.
In LAMP, probably the stickiest component was MySQL. Getting unknowingly locked into a database is one of the worst things that can happen and it can happen easily. Relying on specific optimisations, scaling or behavior or hard coding optimised database queries are all ways to lock an application in. Add to that the fact that once your data is inside it in any quantity and your use cases develop, application knowledge invariably follows the data into the database. That kind of thing is often undocumented too and when the day comes to move to another database, its that knowledge which isn't copied across by the tools.
Flexibility is key to making your applications agile. One of the lessons of LAMP is that you need to be aware of alternatives for your various components so you can at least avoid blocking off paths to making use of those alternatives.
By the letters - M
That means that there is now a wider range of databases available that speak JSON and at least conceptually, this could be any database – NoSQL or SQL, general purpose or specialised and it could even be multiple databases.
Within the NoSQL catagory that choice tends to be amplified – the complexity of the application tends to be in the other levels of the stack. A typical NoSQL database like MongoDB isn't a good home for most application logic – application knowledge tends there to be buried in schemaless collections and how they are structured.
SQL databases, with their ability to join, create complex views and trigger events, are more likely to hold application logic, but with the schema-based tables, application knowledge is better exposed.
Which ever path you take, when developing your application, look to pass JSON compatible objects around and use that as your portable data protocol within your application. Ideally, do try and write your database operations with a thin layer of abstraction that accepts and returns JSON. Look out for trapping application logic in that thin layer too.
By the letters - N E and A
Express is the E in MEAN and is a routing framework for web requests. It's not the only routing framework for Node.js though it is the most popular – there's also koa.js, hapi.js, flatiron, Locomotive and more. They all tend to offer easy and rich configuration but don't drag you into a particular application style or opinion.
So whats left
MEAN, as a group of components, is not revolutionary. That's not a bad thing; it is made up of four independently popular components, MongoDB, Express, Angular and Node, which can be brought together to provide a pretty well explored stack in which you can write applications.
There's also ready packaged variants of the stack with their own tooling - MEAN.js pulls the components together to make lightly tooled un-opinionated framework while Mean.io uses the components as the foundation for it's own opinionated framework. They are far from alone though in terms of web frameworks for Node.js as NodeFramework.com shows.
Whichever path you choose though, make sure you keep your database options open. At Compose, we have the tools to move your data to whichever database you want, all you have to do is make sure you haven't overly tied your application to a particular database, even if it did come with your chosen stack.