DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
View Events Video Library
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Integrating PostgreSQL Databases with ANF: Join this workshop to learn how to create a PostgreSQL server using Instaclustr’s managed service

Mobile Database Essentials: Assess data needs, storage requirements, and more when leveraging databases for cloud and edge applications.

Monitoring and Observability for LLMs: Datadog and Google Cloud discuss how to achieve optimal AI model performance.

Automated Testing: The latest on architecture, TDD, and the benefits of AI and low-code tools.

Related

  • 2-Tier Architecture vs 3-Tier Architecture in DBMS
  • Creating a Secure REST API in Node.js
  • The Serious Stack Behind Salesforce Developers — Part 2
  • Key Things to Know: Enterprise Chat Architecture That Connects Millions of Users

Trending

  • AI for Web Devs: Project Introduction and Setup
  • Performance Optimization Strategies in Highly Scalable Systems
  • Implementing Stronger RBAC and Multitenancy in Kubernetes Using Istio
  • Build Quicker With Zipper: Building a Ping Pong Ranking App Using TypeScript Functions
  1. DZone
  2. Coding
  3. JavaScript
  4. Designing a Flexible Mean Stack Architecture

Designing a Flexible Mean Stack Architecture

This article gives you a simple example and shows you how you can fit together the pieces of the MEAN stack to design the best solution.

Simon Holmes user avatar by
Simon Holmes
·
Mar. 08, 15 · Tutorial
Like (2)
Save
Tweet
Share
20.86K Views

Join the DZone community and get the full member experience.

Join For Free

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.

Architecture mobile app Express Blog Data (computing) AngularJS Engine Database Interface (computing) Node.js

Opinions expressed by DZone contributors are their own.

Related

  • 2-Tier Architecture vs 3-Tier Architecture in DBMS
  • Creating a Secure REST API in Node.js
  • The Serious Stack Behind Salesforce Developers — Part 2
  • Key Things to Know: Enterprise Chat Architecture That Connects Millions of Users

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: