This page provides information about the architecture of the server.

- **Author**: Rachael Daly <[rld5989@rit.edu](mailto:rld5989@rit.edu)>
- **Author**: Alex Wilkes <[adw4236@rit.edu](mailto: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](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise)
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.
