A place to publish my projects
As it is told: “If there are no issue, and engineer will create some”. I have created a web interface, but now I am not really satisfied with the result. I have decided to start it from scratch.
In this article, I will discuss about the REST API, what I have use for my home alerting service. This API is between my database engine and the incoming requests.
Before, I would explain the program, I would like to describe the environment and the way, how it is deployed. It is good to know, as it will self explain some launch settings in the API.
In my opinion, it is good way to make a separate layer between the database and the program logic. If I changed the database, it would be easier to make changes. Besides on this way, I can be assumed that each of my program treat the database on allowed ways. None of them will use or manipulate the data in database freely. It increase the robust of this application.
In this article, I will discuss what is in the database, what is the relationship among tables. Together with this, I will also discuss what information will be stored in the current version of this ticketing server.
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.
Home, I am using a Debian server where are store my files, media files and some of my application what I strictly use on my local network. Although, I am the only user who use it, not a good thing when something bad happen there and I have no information about that. I am that kind of guy who like to write solution for myself, so I have decided that I build a ticketing system where I can collect alerts from my server and from my other devices (e.g.: Raspberry Pi).