Server Side Architecture

This page provides information about the architecture of the server.

• Author: Rachael Daly <rld5989@rit.edu>
• Author: Alex Wilkes <adw4236@rit.edu>

Server Side Architecture

The server itself is split up into two abstractions, one serves the client, and one serves the API. Both of these abstractions can exist in tandem easily through the use of express. See /server/src/app.js for the main entry point into the express server and how these two parts are joined together.

The rest of the server is broken into 3.5 layers, each is discussed below.

A note on synchronization: Adding async and await to all functions makes this architecture much easier to work with. As a general rule of thumb, all methods in any of these layers should be defined as asynchronous and all method calls should be awaited. This is a syntax shugar Node implemented to make working with promises easier.

Routes

This is the half layer that exists to define API routes. When a developer needs to find an entry point into the system, this is the layer that they should start in. This layer exists outside of controllers to act as an alternative grouping, and to help the readability of the controllers. This is also what the API documentation is based on, so it is where the most details about the API should be present in comments.

Controllers

The actual logic of the server starts in the controller layer. This layer is responsible for ensuring the input provided is valid and that anything being sent from the server is exactly in the format the client is looking for. It acts as an entry and exit for all API calls.

In most cases, it is acceptable for the controllers to interact with the models immediately, but when many model objects need to be used together for some more complex logic, the services tier exists to handle that.

Services

Services can take the form of either third party middleware like Passport, or it can be custom methods that interact with many model objects at once. This layer exists to ease the burden on model tier objects and solve the issue of circular dependencies there. This is also a good spot for custom validation code that multiple controllers use.

Models

The model tier is what relates code to data. Using mongoose, this tier is able to map objects saved in the database to JSON objects that can be used by services or controllers. These objects can also contain custom methods that can be used as a shortcut to manipulating their data.

Static methods on these objects exist primarily as a way of searching the database for a subset of objects, while non-static methods focus on updating objects in the database.