MVC

Let’s get a brief overview of how different components and technologies will communicate together. For example, how do we get React to work with Express and MongoDB, or get Express to work with MongoDB?

There are many independent courses about React, Express, and MongoDB. Still, there’s not much content that tells us how to use all of these different technologies together in a fully-working application. During this course, we’ll learn how to make different technologies work together to help our projects go live.

MVC architecture

Our application mostly follows either the popular three-tier architecture, the MVC pattern, or the MVC model. This is done to separate internal representations of information from the ways information is presented to and accepted by the user.

The view layer, written in HTML, CSS, and JavaScript using the React and Tailwind CSS frameworks, is the frontend. Users can interact with this layer to get a full experience when using the application.

The controller layer, written using Node.js and Express framework, is the backend. This layer represents the server-side of our application and performs the following tasks:

• Contains all the business logic.
• Serves the HTTP requests.
• Acts as a bridge between the frontend and the database.

Finally, the model layer is the database hosted by MongoDB. It stores all the data that the application needs to function.

View: the front-end

The view layer, also known as the frontend, is the first point of interaction between the user and the backend of the application. This layer determines how the application looks and feels to the end users, so it’s important to care for it both visually and functionally.

We’ll use React and its ecosystem to build the view layer. As we discussed in the previous lessons, React is just a JavaScript library, so we’ll need additional tools like HTML, CSS, and JavaScript—the core technologies used in web development.

The problem is that a React application has nothing to show to the user! For example, if we want to display a table of all the saved files, we need a data source.

The controller layer—the backend

We need to effectively communicate all the data stored in our MongoDB database to our React application. To do this, we’ll put an Express API between React and MongoDB.

This Express API will contain our application logic. So, the API will receive the HTTP requests from the React application, pull some data from the MongoDB database, process it, and then send that data to the React application for display.

The Express API and the React application are going to communicate through the HTTP or AJAX request protocol. Each request may contain some data, which will be in the form of JSON.

The Express API and MongoDB communicate through the Mongoose client. Mongoose is a MongoDB object modeling tool, which is designed to provide a straightforward solution to model data in the application. We can think of Mongoose as the frontend of MongoDB.

The model layer—the database

If we want to display a table of all saved files, then we need some source of data. Once again, the problem is that our React application has nothing to show to the user! In this course, we’ll use MongoDB to store all the required data. For example, it stores the user’s email and files. However, a React application will never communicate directly to the database. Why is this so?

There are four reasons that the frontend and backend are separate and don’t communicate directly:

• Abstraction
• Security
• Performance
• Separation of concerns

If we directly connect the database to the React application, it will be difficult and time-consuming to change the database. That’s why abstraction is a very imporatant reason to keep the frontend and backend separate. Security is an even more important reason. We shouldn’t connect the database to the frontend, unless the stored data in the database is worthless!

When it comes to performance, there are many ways to optimize and protect access to the databases in the backend, such as caching and authentication schemas. These strategies aren’t easily available in the frontend and can degrade the application performance. Lastly, a separation of concerns is why it’s best to make the frontend have one single responsibility—that is, the frontend!