In this article, I will explain the architecture and element, how I split this project onto smaller pieces to avoid one big massive monolithic backend for easier maintenance in the future.
This article is part of a series. Other already public articles:
Home Ticketing #1 – What my back(end) at home!
Learn from my earlier project, where I did not want to split anything at all, I decided to split this big project onto more smaller pieces. It has 2 main reason from my view.
- Easier to make an overview: as it has more separated, so if I looking for a component, then I don’t need to check the whole project, only just a particular part
- Easier to maintain: if I handle these separated parts and I implement changes slowly (for example new change in one component should be compatible at least with the other components level), then rollout can be more massive and robust.
As I wrote in my earlier article I am using PostgreSQL as database software. Rest of the part (backend, API and frontend) will be created in .NET framework. When I have begun my project, it was .NET Core 3.1 the newest, but since .NET 5.0 has came out, so when I wrote this article, it is running in .NET 5.0 framework. You can see a representation about the solution high level overview on the following figure. I will discuss the layers from bottom to up.
- Database: this is the PostgreSQL database. As it can be seen on the figure, nothing can reach this database as “raw”. I implemented this method to allow access for data only via provided object, to avoid any inconsistent status in the database. Database has internal dependencies, requirements (it will be discussed in the next article) and if only available via a object, then it is easier to synchronize the “data usage” from the application and “data store method” in database.
- DatabaseController object: this is object where data can be reach in database. Actually, only REST API use it, but I am planning to implement some batch functions (e.g.: email notification for people when ticket is opened) and those batch programs will also use this object to gather/change data in database.
- REST API: these APIs are popular today and a good choice because no need to write any extra API, everything can send http request, so everything can send request to this server (even from a small microchip), so it is a handy solution because my goal is involve more of my item onto this system: home server itself, Raspberry Pi and some embedded system with STM32.
- Website: this is a common interface for simple users and admins too. This is the place where this ticketing system can be configured and tickets can be handled.
- Clients: interactivity with client can have more ways: via web browser or via http calls. OpenAPI (Swagger) is installed for the REST API, so it is easy to figure out which http calls is required. My local monitoring scripts on my home server, also using http request to generate tickets for me in case of an issue.
