Pilgrim App Server Architecture
After doing some research into how similar systems work I've realized that this project will be far beyond the scope of anything I've attempted previously. because of this, I think thorough planning of exactly how these systems will function should help us stay on track and not get lost in a rabbit hole of headfirst coding.
A lot of the research I've found is based more on the overall philosophy of a system rather than specific code snippets and techniques. There are also technical constraints to consider and each option has its own benefits and drawbacks. To make these choices at this point in development means we need to understand the requirements of the app already, thinking and mapping the app’s functionality means we can make justified decisions on the technology to use moving forwards.
This is a map of how the server will work, but is subject to change.
Monolithic Architecture:
The two main architecture types for back end systems are monolithic and micro service. A monolithic server runs from a single app which contains all the backend functionality. Micro service systems are like an exploded monolith, where all the individual modules that would run inside a single app now function as multiple smaller apps that can communicate.
This has advantages in that each module can use a different language/technology, and use one which fits its individual purpose best. Monoliths can only use one language to complete a variety of tasks and this can cause issues that require time consuming or complex workarounds.
Distributed systems like micro services also are more resilient against crashes since if one part breaks then the other services can continue running.
However, creating a micro service style system takes considerably more time, and is a far more complex task. At this stage in the project, with the goal being to make a functional Pilgrim v1.0, a monolith architecture suits us better. If the requirements for this project change and more reliability on large scales is needed then the back end might have to be migrated to a different architecture may be necessary, but will be roughly similar.
Internal monolith hierarchy:
Inside the server app there are three layers of logic:
Controllers:
The first and last stage in the request/response loop. Validates incoming request, forwards it to relevant services and finally responds to the client.
Services:
Runs the main logic of the server. Receives incoming requests from controller, uses external API’s, other services, and DAO’s to evaluate and create response to return to controller.
Data Access Objects:
Abstracted functions for accessing databases and other external data sources. The concept being to “Separate a data resource’s client interface from its data access mechanism”. This is the only place database URLs, keys, and passwords should be loaded from config.js. Database DAO’s are also the only place any SQL or other database language is written.
