How to Plan a MEAN Stack Application the Right Way

The MEAN (MongoDB, Express, Angular, and NodeJS) Stack is an innovative open source technology that empowers developers to get apps to market rapidly. This is one of the primary reasons driving its popularity within the developer community. If you have chosen MEAN instead of MERN (you can read here what suits you better) this article is for you!

Another factor is the fact that it’s based on a single programming language, JavaScript, which also happens to be the most popular coding language out there. This means that whether it’s on the client-side or the server-side, the language is the same.

Other factors include the following:

• Cost effective (open source)
• Performance (MEAN stack projects score significantly higher than most client-side server-side web applications primarily due to the performance of NodeJS)
• Single data format (where data is transferred in JSON format throughout the entire app, so it’s in the same format in the user interface (UI), data layer, and server)

However, building a successful application with a MEAN stack starts with a lot of planning. So what’s the best way to approach it?

Before we get ahead of ourselves, for the purpose of this article, we’re building a hypothetical working app on a MEAN stack called WiFi117. It will help locate and list WiFi hotspots where users can seamless gain access. So, it will display the facilities, location map, opening times, and user ratings.

1. How many screens will you need?

The best way to get started is to begin thinking about screens. You can approach it at a high level without focusing on the details that will go into each page.

Sketching it out can go a long way to help visualize the whole app while organizing screens into collections and flows. This can also be a good reference point while going through the build cycle.

Because you’re not adding data or application logic to the pages, it will be easy to just add or remove screens, change what’s in the UI, or even the number of pages.

More often than not, you won’t get it right the first time (so just keep improving it until you’re happy).

2. Plan the individual screens

As stated above, our aim with WiFi117 will be to list facilities, location map, opening times, and user ratings related to WiFi access to get stuff done. This will help you get an idea about what screens you’re going to need.

Your screen list should look something like this:

• A screen with a list of WiFi hotspots nearby
• A screen with details for an individual facility
• A screen to enable users to add a review

It will also be a good idea to have an About screen to tell users what the app is all about. So we will need more screens like the one for the “About us” page. We will also need to divide the screens into collections to make them easier to manage.

This means that you should take the screen list and collate it in a logical manner. For example, the “About us” page will stand on its own while the other screens that deal with locations can be bunched up together.

3. Plan the collections

Before you even start thinking about the architecture, you need to go through this stage of planning. It’s important as it enables you to look at the basic pages and figure out how they will flow.

4. Application Architecture

WiFi117 might seem like a simple app with just a handful of screens, but it still needs robust architecture to ensure that the transfer of data from the database to browser is seamless.

User interactions with the data and the transfer back to the database should also be a simple process (and this makes planning the architecture a vital part of the process).

5. The API

As WiFi117 is basically based on a MongoDB database that’s passing data around, it’s best to start building a REST API with Express and NodeJS. This will enable interactions with the MongoDB database.

The foundation of the architecture is building an API to interface with our data. But how do you architect it?

6. Application Architecture

What’s the aim of the app? Does it need to be easily discoverable and crawlable by search engines? Do you want to generate organic traffic? If so, then it has to be crawlable to achieve this.

If you hope to drive users by promoting as the application, then you don’t have to be too concerned about search engines. So your app architecture might look something like this:

• A Node.js and Express application
• A Node.js and Express application with Angular additions for interactivity
• Angular SPA

This means that the architecture options will range from a server-side Express and NodeJS application to a full client-side Angular SPA.

Building these separately will allow developers to figure out how each will work, take an in-depth look at the technologies, and develop it layer by layer.

So you would start with NodeJS and Express application, add some Angular, and then refactor to Angular SPA.

7. Finishing up in an Express project

At this juncture, you will need to incorporate separate Express applications for the application logic and API. If you expect a lot of traffic, then you might want to place the API and the main application on separate servers.

This approach comes with the added benefit of creating more specific settings for each application and servers to meet individual needs. Another way to keep it contained and simple is to have everything inside a single Express project.

By doing this, you only have one application to host and deploy along with one set of source code to manage.

8. MEAN stack app with Express

The application architecture with the API will have the app logic wrapped inside the single Express project. However, it will be important to organize the code really well to enable distinct parts of the app to be kept separate.

This approach will also make it easier to maintain the code or split it out down the line for separate projects.

9. Make the end product responsive

Once all the layers of the MEAN stack are in place to create the WiFi117 app, you should also include the Twitter Bootstrap to help create a responsive layout.

So the final product will be an application that can display differently on different devices and will display the list of locations, information about the places, and visitor login for reviews.

That about sums it up!

What would you do differently? Share your thoughts in the Comments section below.