Finance Helper

project_preview_img

In this article I want to write about my project. I will try to explain project structure. This project is not yet fully completed, but I already want to share the interim results. You can see the project here.

Reasons to start a project:

  1. Improve my programming skills.
    Improving skills is the most important reason to start this project. Prior to starting the project, I had no experience with the mongo database. I wanted to learn how to work with this database because mongo has a lot of interesting features.
  2. Understand microservice architecture better.
    Microservice architecture is a popular topic these days. Understanding the microservice architecture in our time has ceased to be a luxury, but has become a necessity, and in this project I decided to try my hand and write everything on this architecture.
  3. Improve my server administration skills.
    To deploy and administer such a system, additional skills are required, such as the skills of deploying and selecting the parameters of a mongo base, deploying microservices in docker, and so on.

Financial Helper is an application that will become a personal financial assistant and it will help in efficient planning of budget, monitor spends and reach financial goals.

The main tasks of the application are as follows:

Financial accounting. You can to track money and have sense of how much money goes away and comes in. Also, it helps understand whether expenses are in excess and shows a better way to save money.

Financial planning. Planning for future costs and budgeting is an important part of financial literacy, so I consider it necessary to add such a function to the application.

Various financial tools. Many calculators will be available in the application, from currency translation to an investment income calculator.

Architecture

arc_1

Let's understand the architecture of the application. The diagram shows two blocks. These are blocks for collecting analytics and services.

In the block for collecting analytics, everything is quite simple, Prometheus is responsible for collecting service analytics (number of requests, query execution time, etc.), and Grafana is responsible for displaying graphs.

Now let's move on to the more interesting part of the project, to the block of services. Here are 8 services:

  1. Spring Gateway
    The main task of the service is provide a simple, yet effective way to route to APIs, also filter some requests using Auth Service to validate users.
  2. Auth Service
    Service give the ability to sign up, sign in, generate and verify the jwt token.
  3. Accounting service
    This service implements all the logic related to cost and income accounting.
  4. Telegram bot
    Telegram bot service implements all the logic of communication between the site's clients and the support service. All reviews and feedbacks will be sent directly to the support chat.
  5. Spring Cloud Config
    Spring Cloud Config centralized storage of configurations for other services.
  6. Discovery service
    Discovery service allows services to find and communicate with each other without hardcoding the hostname and port.
During development, there were cases of code duplication in some services. This kind of problem occurs frequently when writing microservices. The biggest problem with duplicating code in different microservices is the complexity of maintaining the system, since when you change the duplicated code in one microservice, you need to change it in all the others. To solve this problem, a library was written that contains duplicate code.
The Mongo database was chosen as the database. The main reasons for choosing this database are:
  1. Analytics
    MongoDB is designed for writing complex analytical queries.
  2. Data structure
    The data in this database is stored in JSON format, which makes it easy to change the data schema and to abandon heavy wrappers such as ORM.
  3. Horizontal scaling
    Easy horizontal scaling is also an advantage of this database, in the early days I will not scale out the database as there will not be a lot of data. I considered this point important since I will have the opportunity to scale not only the system, but also the database at any time.

Deploying

Now that we have more or less figured out the architecture of the application, another problem appears. How to deploy and manage so many services? I used a tool called docker, you can use other analogs like Podman. Docker is software for automating the deployment and management of applications in containerized environments, in other words, an application containerizer. Docker is also useful for horizontal scaling of the system. It is enough to tell the docker that we have several servers and it will automatically distribute the load.

Conclusion

In this article, I described the application in general terms, in the future I plan to talk in more detail about each service, show the results of load testing, and talk about how I trained machine learning models for an analytics service. I would be grateful if, if you find any errors or have ideas for improving the system, you let me know about it.