Re: GQL - Explain to me what abstraction layer should exist between the data model and what data is loaded into the client? I’ve never understood why injecting arbitrary complexity on top of the data model is wise.
Perhaps unfettered write access has its problems, and GQL has permissions that handle this issue plenty gracefully, but I don’t see why your data model should be obfuscated from your clients which rely on that data.
In my view the abstraction layer should be in the domain of the application.
Let's say your software is HR software and you can add and remove employees. The abstraction is "Add an employee with these details". The data model should be completely independent of the abstraction. I.e. nobody should care how the model is implemented (even if in practice it's maybe some relational model that's more or less standard). Similarly for querying employees. Queries should not be generic, they should be driven by your application use cases, and presumably the underlying implementation and data model is optimized for those as well.
But I get it the GQL can be that thing in a more generic schema-driven thing. It still feels like a layer where you can inadvertently create the wrong contract. Especially if, as I think the case is, that different teams control the schema and the underlying models/implementation. So what it seems to be saving teams/developers is needing to spell out the exact requirements/implementation details of the API. But don't you want to do that?
How do people end up use GQL in practice? what is the layer below GQL? Is it actually a SQL database?
For instance, while I work in small teams, I’ve relied on Hasura GraphQL-Engine a lot for my api. This is a full GQL API automatically generated from your SQL schema, Postgres being the best supported DB. GQL relations are available across foreign keys (or manual joins which I never use), so a well defined normalized schema can have deeply nested queries executed easily with full type safety for the consumer.
Taking an HR example, you could query for an employee, their PTO status and accrual history, their manager, and their reports all in one nice easy query that no one has to write any business logic for, just a schema set up with employees, manager, reports, and PTO tables joined on ID keys.
And in such a case, what abstraction does the backend team need to put in front of the schema? I can’t motivate what this means myself. A well designed DB schema is truly a beautiful contract, and with table and column comments you can even get intellisense docs in the IDE for the front end team building the client.
On the flip side, I agree the write operation should be done thru an API when there is complexity and requirements beyond just writing one row to one table, but read operations are much more graceful and speedier to define in GQL than REST.
Perhaps unfettered write access has its problems, and GQL has permissions that handle this issue plenty gracefully, but I don’t see why your data model should be obfuscated from your clients which rely on that data.