Open Warxcell opened 2 months ago
Yes we thought about it Do you have a use case for it in production?
Backend-for-frontend pattern? Instead Frontend query things one-after-another + their relationship - backend could have ready-to-use query for frontend, for example: /api/homepage
- which returns all data needed for homepage.
I've meant if you specifically need to use it in your production product?
I don't need graphql to rest yet, but if I need it , i would use it this way.
Thanks, the reason I'm asking is that we are looking for a design partner to work with getting it into production
Thanks, the reason I'm asking is that we are looking for a design partner to work with getting it into production
I think I could possibly help. I've done same thing as proof-of-concept for PHP's implementation of GraphQL.
It would be very cool if it was possible to write normal graphql queries/mutations/subscriptions and expose them thru REST rather than automatically generated endpoints based on graphql types.
That way you can tailor the data for specific client (Backend For Frontend pattern) - and nothing else.
Wundergraph has it: https://docs.wundergraph.com/docs/architecture/wundergraph-rpc-protocol-explained