One of the most common patterns utilized within the organized development of a server and its middleware is MVC.

 

Structuring the server with the architecture of:

Model<->View<->Control

MVC is NOT a framework, but rather an architectural pattern used by frameworks.

 

The goal of MVC is to assemble a server with abstraction and encapsulation in mind.

 

MVC allows a team to work on a server together while maintaining readability, mitigating the risk of conflicts, and making debugging easier than its ever been before.

3 Major Parts of MVC (server):

 

Model: the part that talks to the DB.

 

View: the part that talks to the templating engine.

 

Control: the part that handles user requests and liaisons between view and model.

 

*(router uses route & method to assign controller)

Allows us to modularize our codebase

- Server code is written in a flexible way, where we are not limited to what frameworks to use.

- Model (MongoDB, MySQL, Postgres, etc...)

- Views (React, EJS, Pug/Jade, Handlebars, etc...)

- Controller (Express, Laravel, Django, Ruby on Rails, etc...)

We can switch frameworks whenever we want

...and find what's best for the job.

People know where to go to fix errors/bugs

- Limiting the amount of code to debug increases the productivity we have on a team.

- We can also have a whole team work on different parts of the server at once

- Despite this, we won't fear overwriting each other's work

- Even if something goes wrong, we know where immediately, and we know what files to look for

For Web Applications:

 

The process starts as soon as the client makes a request:

- The router listens for routes and catches the client's request.

- The router connects the current request to the correct controller (/w HTTP method + route).

- The controller now handles the routes

* You can encapsulate each route by its requests as well

 

These routes can connect to the Model to grab information from the DB.

- DB info passes from the Model -> Controller -> View

- View produces a rendered HTML file with the DB info, relaying it to the controller.

- Finally, the controller responds to the client with the rendered file.

For MongoDB (an example):

One concern when choosing what DB to connect the model with is dependent on the ability to abstract the template design or make it so we can work on the model without having access to the DB itself.

A good way to handle this is by using Schema and Models.

Schemas allow structure and constraints definition (values, /w datatypes, and other rules) that are strictly enforced for information entering the DB.

Models allow us to use schemas in order to create collections that we can then perform CRUD operations on.

Mongoose, a library for MongoDB, provides us with an easy interface to do this:

const schema = new mongoose.Schema({ name: String, 
size: {type: String, required: true} });
// By default, Mongoose doesn't require properties on a document, but you can set that on the schema.
const Tank = mongoose.model('Tank', schema);

Then you can use CRUD interface methods for the model.

Mongoose (an example using its interface):

Using Mongoose, we can do CRUD operations (with an improved interface /w model and schema):

const schema = new mongoose.Schema({ 
name: String, size: {type: String, required: true} 
}); // required makes creation of a document fail if not provided
const Tank = mongoose.model('Tank', schema);
// will create tank collection if it doesn't exist already 
await Tank.create({ size: 'small' }); // (add doc to tank col)
await Tank.deleteOne({ size: 'large' }); // (delete doc from tank col)
await Tank.updateOne({ size: 'large' }, { name: 'T-90' });// (update doc)
await Tank.find(); // returns matching (by default all) documents
await Tank.findById(id); // returns matching document from the tank col
await Tank.countDocuments({size:'large'});// returns # of filtered docs

Then you can use CRUD interface methods for the model

Get what you need for the Controller to relay it to the View.

 

Templating language:

 

- Server has its model responsible for passing DB query information to the controller, which then relays it to the views, which provides the template language necessary information to dynamically make an HTML file.

 

- While language is template specific, we likely have the ability to use some JS or keywords with functionality that makes it easier to build dynamic HTML files depending on what the DB provided.

 

- The views part of the server will then pass this newly generated HTML file to the controller which will do the final handling as the middleware before the response is sent.

 

Response and Communication:

 

- Throughout all activities since the start of the received request, the controller finally gets its role to shine in the finale that sends a response back to the client.

 

- Just as its name describes the controller is the mediator, the glue that holds the server together, and without it, our code wouldn't have the needed binding agent to handle all the communications to other files and computers in a maintainable way.

 

- Despite being the core of the application and the hardest to change, it too is modularized so that despite how important it is for the program it can be replaced, which is a tough task given what it does.

 

- The views part of the server will then pass this newly generated HTML file to the controller which will do the final handling as the middleware before the response is sent.

 

MVC is a popular programming paradigm that defines the interface of a server and divides its job into 3 parts.

 

While used in more than just Web Applications, it's especially useful for a team to follow a pattern for an easy and organized building process.

 

It's commonly built as the backbone for many frameworks that want to take the role of the tool a team will use to build products.

 

The logical separation leads to a separation of concern, a mix of good fundamental practices (abstraction and encapsulation) which leads to better coding practices as a team and a more sustainable environment.