Tech stack on Supabase
Frontend:
Backend:
How & Why
I’ve always thought that you want to minimize the amount of effort spent to read data from the database. Building REST APIs that just read similar data from the database is a lot of effort to build. And the burden of sharing code amongst all these code pathways leads to bad practices around database accesses. Loops for data retrieval that shouldnt be loops etc, just to avoid duplicating business logic in the access layer.
To combat this, we allow the frontend javascript to connect to the database directly for query. This uses the great Supabase database access so that the exact data required for the page can be loaded in the same place it is used. No overhead of additional rest calls. This library also allows us to make great use of Supabase authorization (JWT) at the same time which is an important problem for all applications too. But chiefly this makes data access simpler.
From the frontend, updates to the database should use RPC. RPC procedures are implemented in plv8. This gets the nice benefit that application logic does not need to be deployed in a separate server, it happens at the database level. But also, no REST API bindings, the frontend JS code can invoke the backend stored proc with no middle layer. And again, JWT secured.
To round out the frontend, we build the frame of this application in SvelteKit. This is a lightweight app layer with lots of precompilation. And a great approach for styling and code reuse that really lends itself to clean code.
The backend with Kotlin & Jimmer is where I think it gets interesting again. The idea on the front end is to basically read and write simple data. Any intensive queries should be moved into a backend process to prepare data (don’t aggregate on the fly, precalc and store… frontend can then just retrieve and render). This backend process is not an application API, instead these are async processes that wakeup, process and go back to sleep. Jimmer & Kotlin together really appear to make database access painless and I think could be a great way to write well tested code. Again, the frontend can use the simple data access it needs, and do relatively little unit tests there. But the backend should be extremely well covered with unit tests. Kotlin makes this extremely possible.
What next?
Now I just need to decide what to build as a hobbyist :)