Designing a Flexible Mean Stack Architecture

this article, excerpted from getting mean with mongo, express, angular, and node , gives you a simple example and shows you how you can fit together the pieces of the mean stack to design the best solution.

if angularjs is like having a porsche then the rest of the stack is like also having an audi rs6 in the garage. a lot of people may be focusing on your sports car out front and not giving a second glance to the estate car in your garage. but if they do go into the garage and have a poke around, they’ll find that there’s a lamborghini v10 engine under the hood. there’s a lot more to that estate car than they might first think!

only ever using mongodb, express, and node.js together to build a rest api is like only ever using the audi rs6 to do the school drop-off runs. they’re all extremely capable and will do the job very well, but they have a lot more to offer. for example, mongodb can store and stream binary information, node.js is particularly good for real-time connections using web sockets, and express is actually a web application framework with templating, routing, and session management built in.

there’s also a lot more, and i’m certainly not going to be able to address the full capabilities in an article! what i can do is give you a simple example and show you how you can fit together the pieces of the mean stack to design the best solution.

requirements for a blog engine

let’s take a look at the familiar idea of a blog engine, and see how you could best architect the mean stack to build one.

a blog engine typically has two sides to it. there’s a public-facing side serving up articles to readers, and hopefully being syndicated and shared across the internet. a blog engine will also have an administrator interface where blog owners log in to write new articles and manage their blogs. this images shows some of the key characteristics for these two sides.

looking at these lists, it’s quite easy to see a high level of conflict between the characteristics of the two sides. you’ve got content-rich, low interaction for the blog articles, but a feature-rich, highly interactive environment for the admin interface. the blog articles want to be quick to load to reduce bounce rates, whereas the admin area should be quick to respond to user input and actions. finally, users typically stay on a blog entry for a short time, but may share it with others, whereas the admin interface is very private and an individual user could be logged in for a long time.

taking what we’ve discussed about potential issues with spas, and looking at the characteristics of blog entries, you’ll see quite a lot of overlap. it’s quite likely that bearing this in mind you’d choose not to use an spa to deliver your blog articles to readers. on the other hand, the admin interface is a perfect fit for an spa.

so what do you do? arguably the most important thing is to keep the blog readers coming—if they get a bad experience they won’t come back and they won’t share. if a blog doesn’t get readers then the writer will stop writing or move to another platform. then again, a slow and unresponsive admin interface will also see your blog owners jumping ship. so what do you do? how do you keep everybody happy and keep the blog engine in business?

a blog engine architecture

the answer lies in not looking for a one-size-fits-all solution. you effectively have two applications. you have public-facing content that should be delivered direct from the server and an interactive private admin interface that you want to build as an spa. let’s start by looking at each of the two applications separately, starting with the admin interface.

admin interface: an angularjs spa

the architecture for this part of the engine is: a rest api built with mongodb, express, and node.js with an angularjs spa upfront. the next image shows how this looks.

there’s nothing particularly new shown here. the entire application is built in angularjs and runs in the browser, with json data being passed back and forth between the angularjs application and the rest api.

blog entries: what to do?

looking at the blog entries, things get a little more difficult.

if you only think of the mean stack as an angularjs spa calling a rest api, then you’re going to get a bit stuck. you could build the public-facing site as an spa anyway, because you want to use javascript and the mean stack. but it’s not the best solution. you could decide that the mean stack isn’t appropriate in this case and choose a different technology stack. but you don’t want to do that! you want end-to-end javascript.

so let’s take another look at the mean stack, and think about all of the components. you know that express is a web application framework. you know that express can use template engines to build html on the server. you know that express can use url routing and mvc patterns. you should start to think that perhaps express has the answer!

blog entries: making good use of express

in this blog scenario, delivering the html and content directly from the server is exactly what you want to do. express does this particularly well, even offering a choice of template engines right from the get-go. the html content will require data from the database, so you’ll use a rest api again for that. the next image lays out the basis for this architecture.

this gives you an approach where you can use the mean stack, or part of it at least, to deliver database-driven content directly from the server to the browser. but it doesn’t have to stop there. the mean stack is yet again more flexible.

blog entries: using more of the stack

you’re looking at an express application delivering the blog content to the visitors. if you want visitors to be able to log in, perhaps to add comments to articles, you need to track user sessions. you could use mongodb with your express application to do just this.

you might also have some dynamic data in the sidebar of your posts, such as related posts or a search box with type-ahead auto-completion. you could implement these in angularjs. remember, angularjs isn’t only for spas; it can also be used to add some rich data interactivity to an otherwise static page.

the next image shows these optional parts of mean added to the blog entry architecture.

now you have the possibility of a full mean application delivering content to visitors interacting with your rest api.

blog engine: a hybrid architecture

at this point there are two separate applications, each using a rest api. with a little bit of planning this can be a common rest api, used by both sides of the application.

the following image shows what this looks like as a single architecture, with the one rest api interacting with the two front-end applications.

this is just a simple example to show how you can piece together the various parts of the mean stack into different architectures to answer the questions that your projects ask of you. your options are only limited by your understanding of the components and your creativity in putting them together. there’s no one correct architecture for the mean stack.

best practice: build an internal api for a data layer

you’ve probably noticed that every version of the architecture includes an api to surface the data, and allows interaction between the main application and the database. there’s a good reason for this.

if you were to start off by building your application in node.js and express, serving html directly from the server, it would be really easy to talk to the database directly from the node.js application code. with a short-term view this is the easy way. but with a long-term view this becomes the difficult way, as it will tightly couple your data to your application code in a way that nothing else could use it.

the other option is to build your own api that can talk to the database directly and output the data you need. your node.js application can then talk with this api instead of directly with the database. this image shows a comparison of the two setups.

looking at this, you could well be wondering why you’d want to go to the effort of creating an api just to sit in between your application and your database. isn’t it creating more work? at this stage, yes, it’s creating more work—but you want to look further down the road here. what if you want to use your data in a native mobile application a little later? or, for example, in an angularjs front end?

you certainly don’t want to find yourself in the position where you have to write separate but similar interfaces for each. if you’ve built your own api upfront that outputs the data you need, you can avoid all of this. if you have an api in place, when you want to integrate the data layer into your application you can simply make it reference your api. it doesn’t matter if your application is node.js, angularjs, or ios. it doesn’t have to be a public api that anyone can use, so long as you can access it. the following image shows a comparison of the two approaches when you have node.js, angularjs, and ios applications all using the same data source.

as this shows, the previously simple integrated approach is now becoming fragmented and complex. you’ll have three data integrations to manage and maintain, so any changes will have to be made in multiple places to retain consistency. if you have a single api you don’t have any of these worries. so with a little bit of extra work at the beginning, you can make life much easier for yourself further down the road.