Louis :emacs: on Nostr: In the last few days I’m experimenting with substituting CRUD API code with Stored ...
In the last few days I’m experimenting with substituting CRUD API code with Stored Procedures which directly produce the endpoints JSON as a single-row scalar value. API is then just a wrapper that authenticates, validates input and streams the DB’s JSON directly to the client.
- No ORMs, no SQL generators etc.
- All SQL is where it should belong: in the database
- API does only single „CALL myfunc(…)“ db calls
- A simple centralised error handler can accurately report errors from the database
- No weird mixed row/json columns scanning into structs and re-marshalling everything to JSON
- Codebase is collapsing to 20% (by LOCs)
- Stored Procedures can use wonderfully declarative SQL code
- Response times in the microseconds, even for multiple queries, all happens inside the DB
More side effects:
- the data model can change and evolve without touching the API at all
- Zero deploys mean zero downtime
- the API application is so tiny, I could easily switch it to any programming language I want (yes, even Common Lisp) without worrying about available databases libraries, type mapping and rewriting tens of thousands of lines of intermixed language/SQL-code.
The general direction of the dev industry is heading in the opposite direction. More ORMs, more layers, more database abstraction. More weird proprietary cloud databases with each their own limited capabilities and query language.
So you tell me: Is it crazy? Is it wrong? Why do I have doubts despite everything working out beautifully?
#sql #webdev #golang #backend #mysql #postgresql
- No ORMs, no SQL generators etc.
- All SQL is where it should belong: in the database
- API does only single „CALL myfunc(…)“ db calls
- A simple centralised error handler can accurately report errors from the database
- No weird mixed row/json columns scanning into structs and re-marshalling everything to JSON
- Codebase is collapsing to 20% (by LOCs)
- Stored Procedures can use wonderfully declarative SQL code
- Response times in the microseconds, even for multiple queries, all happens inside the DB
More side effects:
- the data model can change and evolve without touching the API at all
- Zero deploys mean zero downtime
- the API application is so tiny, I could easily switch it to any programming language I want (yes, even Common Lisp) without worrying about available databases libraries, type mapping and rewriting tens of thousands of lines of intermixed language/SQL-code.
The general direction of the dev industry is heading in the opposite direction. More ORMs, more layers, more database abstraction. More weird proprietary cloud databases with each their own limited capabilities and query language.
So you tell me: Is it crazy? Is it wrong? Why do I have doubts despite everything working out beautifully?
#sql #webdev #golang #backend #mysql #postgresql