Chapter 2. Designing a MEAN stack architecture

 

This chapter covers

  • Introducing a common MEAN stack architecture
  • Considerations for single-page applications
  • Discovering alternative MEAN stack architectures
  • Designing an architecture for a real application
  • Planning a build based on the architecture design

In chapter 1 we took a look at the component parts of the MEAN stack and how they fit together. In this chapter we’re going to look at how they fit together in more detail.

We’ll start off by looking at what some people think of as the MEAN stack architecture, especially when they first encounter the stack. Using some examples we’ll explore why you might use a different architecture, and switch things up a bit and move things around. MEAN is a very powerful stack and can be used to solve a diverse range of problems ... if you get creative with how you design your solutions.

2.1. A common MEAN stack architecture

A common way to architect a MEAN stack application is to have a representational state transfer (REST) API feeding a single-page application. The API is typically built with MongoDB, Express, and Node.js, with the SPA being built in AngularJS. This approach is particularly popular with those who come to the MEAN stack from an AngularJS background and are looking for a stack that gives a fast, responsive API. Figure 2.1 illustrates the basic setup and data flow.

2.2. Looking beyond SPAs

2.2.1. Hard to crawl

2.2.2. Analytics and browser history

2.2.3. Speed of initial load

2.2.4. To SPA or not to SPA?

2.3. Designing a flexible MEAN architecture

2.3.1. Requirements for a blog engine

2.3.2. A blog engine architecture

2.3.3. Best practice: Build an internal API for a data layer

2.4. Planning a real application

2.4.1. Planning the application at a high level

2.4.2. Architecting the application

2.4.3. Wrapping everything in an Express project

2.4.4. The end product

2.5. Breaking the development into stages

2.5.1. Rapid prototype development stages