Benjie, one of the PostGraphile creators, has a good talk [1] advocating for database-driven development.
OTOH, having dug into PostGraphile a bit, I personally wouldn't advocate for pushing so much backend logic into the DB.
Like, if you decide to do auth and TOTP in the DB, you'll end up implementing it in PL/pgSQL. Writing core security logic in a less-familiar language feels like it adds risk.
Also, for smaller projects your backend is often just a single server, so moving auth in into the DB doesn't save you from managing distributed state.
Right, except if my backend is in JS, there's a cognitive cost to adding another language to the stack.
I could use plv8, but there's a more subtle preference here for JS to wrap SQL, rather than the reverse (plus tooling is less convenient, e.g. if you're writing Typescript).
exactly! this is the ecosystem that I'm a part of that inspired me to build this :)
I do agree about making sure you have experience writing PL/pgSQL and would also add that you should make sure you have a good test-driven environment when writing code in the db.
OTOH, having dug into PostGraphile a bit, I personally wouldn't advocate for pushing so much backend logic into the DB.
Like, if you decide to do auth and TOTP in the DB, you'll end up implementing it in PL/pgSQL. Writing core security logic in a less-familiar language feels like it adds risk.
Also, for smaller projects your backend is often just a single server, so moving auth in into the DB doesn't save you from managing distributed state.
[1] https://www.youtube.com/watch?v=XDOrhTXd4pE