Seems like at that point exposing each query as an OpenAPI endpoint would achieve pretty much the same thing.
Then again having GraphQL as the definition for them is probably still not bad, I'll just have to write something that converts them to SQL::Abstract 2 trees once I get around to porting it to TS.
It would be the same thing except with Benje's approach, you're basically using GraphQL as a developer tool to create those end points instead of writing code to do it.
And you don't have to write something to convert them to SQL if you're using PostgreSQL, because Benje's already written it for you.
postgraphile does look like it'll handle basic cases pretty nicely but I've gone through the docs and didn't find anything like an explanation of what SQL queries it ends up mapping to - do you happen to know if there's one I missed, or a list of examples of GraphQL + corresponding SQL, or something?
PostGraphile compiles GraphQL directly to SQL. The SQL is "custom" in that it's specific to the GraphQL operation, though naturally it does follow rules. For example, Hasura does the same thing, and among the rules that it follows is that it uses `LEFT LATERAL JOIN` between tables (at least, on PostgreSQL). Full disclosure, I work for Hasura, so I'm not super familiar with the style of SQL PostGraphile generates but one thing you can do is just have PostGraphile report back the generated SQL for inspection:
