This is part 2 of a 3 part series on the MEAN stack. Part 1. Part 3.
This ain’t omakase.
Every component in MEAN is swappable, and somewhat paradoxically, not sticking to Mongo, Express, Angular or Node is what makes MEAN great. While doing so will mess with a tidy acronym, I trust that your linguistic skills match your engineering skills and you will be able to find a suitable replacement (the MANK stack? MAKN?). Even Node is somewhat swappable, though if you swap that out this really just becomes service-oriented architecture.
MEAN is important because it gives the engineers flexibility on both matching technology to a project as well as giving the project the capacity to support changes in architecture. Without the back-end conflated with the front-end, both projects are lighter and making big changes like swapping out databases is less of an ordeal than it would seem. On a monolith, a change like that is akin to a rewrite. Rewrites are almost never a good option, but unfortunately sometimes they’re the only sensible one.
Stick with SOA. Avoid the Monolith. Never rewrite again.
Neckbeard Note: You might think I’m using the term SOA wrong here. Generally when people describe SOA they’re talking about breaking the back-end up into different components. While this is certainly SOA, when you have a thick front-end and your back-end is a simple API, the back-end now looks much more like a service and a lot less like an app. If that isn’t “service-oriented” I don’t know what is.
No More Mongo
Sometimes a NoSQL document-oriented storage isn’t the right pick for an application. Some other options you might pick:
PostgreSQL
The best thing about PostgreSQL is that it uses SQL which is probably the best BI tool to quickly analyze your data. Want to know how many users signed up and added a credit card month by month? Any BI engineer worth his salt can quickly write up a SQL query to find that out.
The worst thing about PostgreSQL is that it uses SQL. This means that ultimately your web application has to generate strings of SQL statements to send out to the database, as well as parse the SQL responses. Now you won’t (shouldn’t) be doing this manually, you’ll use an ORM such as Sequelize or Bookshelf to do this for you, but these (and any other ORM) is necessarily complicated and complicated generally means struggles when you’re talking about code.
Admittedly I have only used PostgreSQL for simple projects with Node. I have used Sequelize to put a project into production and it worked well, but the project was very simple. With Rails, PostgreSQL is a treat of a database to use, but the ORM (ActiveRecord) has been in heavy development and use by many people for over a decade. It’s refined by now. I’m not saying the Node ORMs have bugs — in fact I’ve never really seen one. In my experience, however, ORMs take years before they become something you want to use on a complex system.
Also it’s certainly worth noting that with PostgreSQL you will be limited to a single database server. If you need to scale beyond that, there are some clustering options for PostgreSQL, but I wouldn’t expect them to work flawlessly. Unlike MongoDB, it wasn’t designed to be horizontally scalable from the beginning. Having said that, a single PostgreSQL instance is often plenty for any system. If it starts falling over, it’s almost always due to inefficient queries, not due to PostgreSQL itself.
RethinkDB
I know very little about this database. Not many people do. I bring it up because the feedback I have heard about it over the years has been very positive. It comes out of the box with a very cool admin UI:
It uses a JSON-like data storage and JavaScript query language just like MongoDB but has some relational database features as well like JOIN.
It looks amazing. I’ve never used it. Why haven’t I used it? Why isn’t it more popular? ¯\_(ツ)_/¯
Redis
Redis is difficult to define, it can be used like a database, can be used like a cache, a message bus, or a queue. I like to refer to it as “data structures in the cloud”. You get all the CS classics: sets, lists (arrays), hashes (dictionaries), and even some new characters: geo, pub/sub. It’s not one I would pick for things that aren’t ephemeral (it doesn’t have the best persistence strategies), but it’s great to augment an existing database or API. It’s incredibly efficient and often will make your code simpler by sticking to traditional data structure types. You’ll find Node developers are quite big fans of Redis and as such a Redis client exists in many, many package.jsons.
Elasticsearch
Elasticsearch is a treat to work with. It might be the first, if only, horizontally scalable search database. It has powerful Geo tools you can use to ask really complicated questions such as “find me restuarants matching ‘foo’ in the name/description, ranked using a combination of distance to my location, rating, and how good the text match is.” It’s incredibly efficient both for retrieval and storage. I once wrote a test to see how quickly it could ingest a large amount of fake tweets that went so fast I figured it wasn’t working. I tried to debug it for a bit before I looked in the database and was shocked to see the data was there.
It’s not limited to search though, it’s a great, easy to use and learn NoSQL document-store database on its own. Queries and documents are all JSON, so you’ll feel right at home in Node and even Angular. You could augment a different data store like with Redis or even use it on it’s own. It has a much more reliable persistence strategy.
While it’s probably better to find an Elasticsearch host, managing an Elasticsearch cluster is not only easy, but actually really fun. Once it finds other buddies in the cluster, it automatically shards out the data, finds out the best way to replicate for backup and split shards for performance. All of this is configurable of course, but it’s fun to use the defaults and just watch it split the data out and come online without any configuration.
Neo4j
Neo4j is a graph database and really the only graph database you’d likely use. In some ways it works like any other NoSQL database that stores key-value documents and has high performance, but it has unique features when it comes to querying.
Graph databases are used to query complex ontologies. An ontology in CS is really just a fancy word for “[noun] [verb] [noun]”, which happens to be the way a lot of data exists in our world. For example, Craig follows Jim in a social network application. While you could represent this as a row/document inside PostgreSQL or MongoDB, the trouble would come when you want to find complex follow relationships. For example, if you wanted to ask “who is Craig mutual friends with?” where friends means they follow each other, this would be a relatively complicated query in MongoDB or in SQL. Neo4j has a query language that while taking a bit of time to learn, makes these kinds of queries very natural to ask of the database.
It’s also not a database I would select as the only database of an entire system since the query language is a bit unfriendly and doesn’t have the same general purpose tools that MongoDB does (for example). It would make a fine addition to a system that already had a good database to help speed up and make sense of heavily ontological queries.
I’d like my back-end with a bit less express, please.
Not a fan of express? Maybe you’re not a fan of how “node-like” it is with regards to error handling and routing. Walmart felt the same way so they built Hapi.
Hapi
Hapi is all about configuration over code. Expect more boilerplate here, but it’s probably great for building a large codebase. Big companies use it, so I would expect it to be mature. If I’m honest though, configuration over code is not my cup of tea.
Koa
Express has been around as long as Node has been around. It’s not surprising the creator has been trying to find a replacement. To that end, he’s been working hard on Koa. From the documentation,
Philosophically, Koa aims to “fix and replace node”, whereas Express “augments node”. Koa uses co to rid apps of callback hell and simplify error handling. It exposes its own this.request and this.response objects instead of node’s req and res objects.
It’s a very different way to write your code that moves towards ES7-like async/await syntax leveraging the co library. What does that mean? It means that instead of writing a request like this in express:
You write it like this:
No more callback hell. You can make as many db calls as you want but write the code as if it was synchronous (but it isn’t synchronous, this is still evented).
Also, no more messing with error handling all the time, it’s dealt with via exception handlers. This is great because you only need to write code to deal with exceptions if you want to catch them, if you just want them to bubble up, do nothing at all.
Koa is great. I’ve used it and co on a few projects and have had great luck with both. Definitely worth your time.
Angular-less MEAN (round MEAN?)
Angular is an obvious candidate to swap out since the goal with MEAN is to decouple the front-end from the back-end. You might have an iOS app be the front-end for your application instead and nothing else would have to change, really.
I won’t try to list out all the various front-end frameworks here, that’s been done to death and it’s a place that changes so much that anything I write will be immediately obsolete and wrong. This should get you started:
No Node?
A MEAN app without Node is starting to not look very much like a MEAN app, but many of these principles can still be used. You could have Ruby/Sinatra app with an Angular front-end, you could use Python or Go, or maybe even Rust. Just keep the front-end separated with a front-end framework that allows for it. The world is your oyster, pick the language that speaks to you and go from there.
