That being said, the Pro REST perspectives do scare me away from GraphQL in production. But seeing some posts about PostGraphile + Persisted Queries is interesting.
Also, research papers would have been nice to address but I am satisfied with the many hours this took to compile. A future follow-up may be necessary.
GraphQL server is a special case of the BFF pattern, and the whole purpose here is to decouple FE from the underlying data model on the BE, and let both to iterate faster without blocking each other.
> GraphQL server is a special case of the BFF pattern, and the whole purpose here is to decouple FE from the underlying data model on the BE, and let both to iterate faster without blocking each other.
This isn't inherently an anti-pattern.
> GraphQL server is a special case of the BFF pattern, and the whole purpose here is to decouple FE from the underlying data model on the BE, and let both to iterate faster without blocking each other.
A) Says who? B) Why do we have to follow that specific dogma?
Why not to expose SQL interafce or DynamoDB API directly to the client? ;)
While tools like AWS AppSync, Hasura, & PostGraphile accelerate initial development, the bulk of SW Engineering costs are adding new features & providing ongoing support and maintenance.
That said, there are uses cases where this might be a good pattern - e.g. limited distribution internal tooling.
Direct access to SQL is a great example of something that is not an antipattern. It's just one approach of many, with strengths and weaknesses.
In my use-case adding new features and support is the majority of eng work. We find Hasura is valuable here in reducing the cost of doing so - especially compared to traditional REST implementations.
Came across this blogpost that happens to describe where something like hasura sits and how it decouples product dev (app + bff) from data api (microservice + db) dev.
Think of Hasura as a GraphQL BFD (backend for data) instead of a GraphQL BFF.