Expense Tracker Backend

Tech Stack

Core aspects

• jOOQ, Spring Boot, Java 17, OpenAPI, JUnit 4

Observability

Mostly the Grafana Stack:

• Grafana 11

• Grafana Tempo 2.6 - Traces

• Grafana Loki 3.2 - Logs

• Prometheus 3.0 - Metrics

• Grafana Alloy

• Grafana Pyroscope - Profiling

• OpenTelemetry Java Agent

Infra

• NGINX 1.28

• Ansible

• MySQL 8.0

• Apache JMeter

• Jenkins

• Flyway

Environments/Profiles

• devlocal - Developer’s machine

• testlocal - Automated tests on developer’s machine

• dev - General VM

• ci - Automated tests on the general VM

• staging - Mirrors production

• production

Setting Up Locally

• Have MySQL 8.0 installed with the executable on your PATH

• Flyway 10.22 on your PATH, or symlinked in /usr/bin

• Setting up a user:

CREATE USER 'expense_tracker' IDENTIFIED BY 'password';
CREATE DATABASE `expense_tracker_database_testlocal`;
CREATE DATABASE `expense_tracker_database_devlocal`;
GRANT ALL ON `expense_tracker_database_testlocal`.* TO 'expense_tracker'@'localhost';
GRANT ALL ON `expense_tracker_database_devlocal`.* TO 'expense_tracker'@'localhost';

cd database/flyway
flyway migrate -environment=devlocal
gradlew.bat :app:jooqCodeGenDevLocal

Setting up the Staging user

create user 'expense_tracker'@'localhost' IDENTIFIED BY 'xxxxxxxx';
create user 'flyway'@'localhost' IDENTIFIED BY 'xxxxxxxx';
GRANT INSERT,SELECT,UPDATE,DELETE ON expense_tracker_database.* TO 'expense_tracker'@'localhost';
GRANT CREATE,SELECT,ALTER,INDEX,INSERT,UPDATE,REFERENCES ON expense_tracker_database.* TO 'flyway'@'localhost';

Authentication/Authorization

• Login and Sign up return a short-lived access and long-lived refresh token

• Refresh also returns the same pair of tokens

Error Handling

• Uses RFC Problem Details with a custom error code

Logging guidelines

• Repository

  • The sizes of all List/Iterable results from Repository classes

  • The number returned for UPDATE and DELETE operations

• Controller

  • Custom error codes along with brief explanation before throwing it back to the client

Versioning

For now, it’s not fully fleshed out yet, because I have 3 separate things to consider:

• The Backend

• The Android app

• The OpenAPI spec

But the Backend - this repo, derives its version from app-version - uses this format:

YYYY-MM-DD:NN

The NN part is supposed to be incremented before every push to the test server, which in turn is supposed to happen on every merge to dev, which in turn is supposed to be the gateway to master.

It restarts at "01" each day. Let me see you try and reach 100 commits in 24 hours

Also, Java version is 17

Things to Note

• The project uses an API-first approach, so the endpoints are derived from the OpenAPI specification

• Generation is done using the codegen plugin with the openApiGenerate task

• Any changes to the openapi files should also increment the version number. How exactly to increment it is based on vibes discretion

• Subtle issues noted with the plugin:

  • Anytime a change is made to schemas.json, but not the root openapi.json, the Gradle task remains UP-TO-DATE

  • Validation doesn’t work, likely also because of the file splitting. TODO I’ll try adding a task that does merging and validation before the actual generation

• Concerning repositories:

  • Most of the methods should include a parameter that links back to the user: userId or profileId and the queries should include them, too. Basically IDOR mitigation

TODO

• I use "supposed" in Versioning the because the features haven’t been implemented just yet

• Fail any pushes if the version remains the same

• Alternatively, or combined - increment the version number automatically in the pipeline

• https://xkcd.com/838/ Log all attempts to access unauthorized entities along with the target entity IDs to the console. INFO level

• Generate SchemaSpy to static webpage

• Maybe use AspectJ for Repository logging