As in, write your entire application in SQL? That sounds like a nightmare of epic proportions. Every time I've tried to use SQL for anything more general-purpose (like string manipulation, say) I've wanted to gouge my eyes out by the end.
More broadly, this just seems like it would sharply limit how you could extend the application in the future. What if at some point you want to query a web API for some additional data with which to enrich what you're returning from your database? (Not an unusual situation, in my experience.) You'd be stuck trying to make web requests from SQL, which again seems needlessly painful.
Note that I'm not against the basic idea of "do as much data-munging in SQL as possible" - in my experience that's a great way to ensure that your application stays fast and efficient. It' just all the ancillary things surrounding the data-munging for which I don't think SQL is the best fit.
- PostgREST (https://postgrest.org/): REST API for PostgreSQL
- PostGraphile (https://www.graphile.org/) GraphQL API for PostgreSQL
- pg_graphql (https://github.com/supabase/pg_graphql) GraphQL API for PostgreSQL
- Hasura (https://hasura.io/) GraphQL API for various databases
If you want to blend data from a web API and you're content with GraphQL, for some use-cases (not all, but some), there are options:
- Apollo Federation (https://www.apollographql.com/apollo-federation/)
- GraphQL Mesh (https://the-guild.dev/graphql/mesh)
- Hasura Remote Schema (https://hasura.io/blog/tagged/remote-schemas/)
If you want more control over the web API and you were going to fetch the data within your Python back-end and process it there, for some use-cases (not all, but some), there are options:
- pg_http (https://github.com/pramsey/pgsql-http)
Life is about trade-offs. Doing the work in SQL is not without its drawbacks, but it's also not without its benefits, and that's true for doing the work in a general-purpose language as well. Whatever the drawbacks of doing it in SQL, one of the benefits has got to be eliminating the impedance mismatch (for people who regard that mismatch as a problem, and the OP seems to be one such person). What I claim is that doing the work directly in the database shouldn't be ruled out in general (the specifics of a given use-case may rule it out in particular) any more than the other common patterns (API hand-written in Python, for instance) shouldn't be ruled out in general.
> What I claim is that doing the work directly in the database shouldn't be ruled out in general (the specifics of a given use-case may rule it out in particular) any more than the other common patterns (API hand-written in Python, for instance) shouldn't be ruled out in general.
Hear hear.
With PG's COMMENT feature one can enrich SQL schema with the sorts of metadata one needs for UI generation.
Here's a script that generates a JSON view of a PG SQL schema enriched with JSON from COMMENTs: https://github.com/twosigma/postgresql-contrib/blob/master/s... and https://github.com/twosigma/postgresql-contrib/blob/master/s...
Generating HTML?? No, generate UI declarations from the SQL schema (enriched with extra metadata) then interpret those in JS in minimal static pages that use JS to talk to PostgREST.
PG has a `COMMENT` statement that can be used to attach commentary to every single schema element -- tables, columns, views, indices, etc., all can have free-form commentary. Use JSON COMMENTs and then extract the whole schema using the pg_catalog as one big JSON blob, then post-process to generate UIs. See below for links.