- 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 should AWS do -> provide Postgres or similar as a database choice
If you're interested a postgres option you could check out Supabase GraphQL[1] which is based on pg_graphql [2], a native PostgreSQL extension.
You define your schema in SQL (including any indexes you'd like) and it reflects a full GraphQL API. With that stack, the example you gave about filtering for security would use be solved using a Row Level Security [3] policy where the work all occurs on the DB.
While not a part of pg_graphql, using Supabase as a backend also handles Auth [4] & Storage [5] (both OSS) which covers most of the Amplify bases
[1] https://supabase.com/docs/guides/api#graphql-api-overview [2] https://github.com/supabase/pg_graphql [3] https://www.postgresql.org/docs/current/sql-createpolicy.htm... [5] https://supabase.com/docs/guides/auth [5] https://supabase.com/docs/guides/storage
I had this issue when trying to implement an AST type for pg_graphql[1] back when it was written in SQL [2]. In the end we used a JSON type which was much less constrained. That might be solvable using pg_jsonschema [3] if you really wanted to have a good time though
[1] https://github.com/supabase/pg_graphql
[2] https://github.com/supabase/pg_graphql/blob/34cc266da972d356...