3 Layers for the Back End
Alexandria is built based on the principles of service-oriented architecture [2]. In order to achieve readability, testability, and maintainability, we ensured a separation of concerns when it came to implementing the back end.
More specifically, we designed the back-end server in three layers.
| Input layer | Logic Layer | Data Access Layer |
|---|---|---|
| Responsible for accepting HTTP requests, authentication, validating format, dispatch to correct logic function. | Algorithm queries data in response to user input and operates on it. | Reading and writing in-memory representation of records to and from database, performing complex queries over data. |
Based on this three-layer design including routes, services layer and data access layer, business logic is extracted away from the API.
When a request is made to a route, the corresponding service is called, which in turn calls the data access layer. The data access layer queries the database and returns the result to the service layer, which in turn parses the data and pass it back to the route. The route can be kept “dumb”, and simply relays the data it receives from the service back to the client.
The separation of duties is particularly relevant when it comes to the service layer and the routing layer. The service layer is framework agnostic, which encapsulates and abstracts business logic from the application. On the other hand, the routing layer is responsible for handling client requests and responding to them.
We capture the business logic and leverage the data access layer to interact with the database. Keeping concerns separate means that it does not handle request or response objects, does not respond to clients, provide anything related to the HTTP layer, nor does it interact directly with the database. Services are leveraged by passing the data needed instead of response or response objects.
In addition to keeping application logic out of the routes and data access layers, the three-layer approach also results in easier unit testing. Tests are designed to address each service function individually. Should we ever decide to change Alexandria’s database implementation, most of the changes will be confined to the data access layer.