[nawgz]

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.