What I have to say is especially applicable in situations where your consumers need to make calls to more than one service for a single purpose. But still applicable in all cases where you're needing to retrieve data from different resources for any consumer - even if those resources' endpoints live in the same service.
We've all seen 'REST' APIs with endpoints like /accountPageData that do a collection of things, compiling information about a bunch of different resources and throwing the resulting response at the client.
And if you haven't seen that, you've definitely seen chains of promises in the frontend to handle making calls to multiple endpoints to collect all of the data you need for a page or component.
In either case, an alternative approach is to build a nice, clean RESTful API that doesn't contain any of the resource combining BS I wrote about earlier. Then adding a GraphQL layer between that API and your consumer(s). This means your APIs stay RESTful and your consumer(s) can ask for whatever bespoke data combinations they want without polluting your pristine APIs.
Overall an approach like this is a teaser to the world of Backends For Frontends or BFFs.
Having said all of that, my typical advice when it's early in development is to build with REST until it starts hurting or getting ugly. At which point, consider a simple BFF layer to keep your APIs clean and your frontend developers sane.
Kamran Ayub is a technologist, speaker, and Pluralsight author and specializes in building full-stack solutions with a focus on modern web technology and cloud native architecture.
Yeah, this is how we approach it at work (i.e. "an enterprise"). We have something called the "UI facade" which is just a GraphQL layer that talks to our Java REST services that are owned by other teams AND our microservices (session service, auth service, etc.) that we own. Then any client, our UI or another team or another service, can use our GraphQL layer to fetch only what they need without worrying about where it comes from, versioning, auth tokens, etc. It's amazing.
If you are only writing GQL over one REST API and you own both layers, I would just do GQL since its de-facto more flexible and will scale over time super well.
I had the same thought like it is not good for uploading images or other hypermedia, I was searching for a suggestion, and I got the almost same though I had and I figure it out that it is not a bad idea to keep both rest and GraphQL together, thank for your suggestion.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Why not both?
What I have to say is especially applicable in situations where your consumers need to make calls to more than one service for a single purpose. But still applicable in all cases where you're needing to retrieve data from different resources for any consumer - even if those resources' endpoints live in the same service.
We've all seen 'REST' APIs with endpoints like /accountPageData that do a collection of things, compiling information about a bunch of different resources and throwing the resulting response at the client.
And if you haven't seen that, you've definitely seen chains of promises in the frontend to handle making calls to multiple endpoints to collect all of the data you need for a page or component.
In either case, an alternative approach is to build a nice, clean RESTful API that doesn't contain any of the resource combining BS I wrote about earlier. Then adding a GraphQL layer between that API and your consumer(s). This means your APIs stay RESTful and your consumer(s) can ask for whatever bespoke data combinations they want without polluting your pristine APIs.
Overall an approach like this is a teaser to the world of Backends For Frontends or BFFs.
Having said all of that, my typical advice when it's early in development is to build with REST until it starts hurting or getting ugly. At which point, consider a simple BFF layer to keep your APIs clean and your frontend developers sane.
you make me think of the point of view of an introduction video on GraphQL I've seen, saying that it does not replaces RESTful APIs.
Yeah, this is how we approach it at work (i.e. "an enterprise"). We have something called the "UI facade" which is just a GraphQL layer that talks to our Java REST services that are owned by other teams AND our microservices (session service, auth service, etc.) that we own. Then any client, our UI or another team or another service, can use our GraphQL layer to fetch only what they need without worrying about where it comes from, versioning, auth tokens, etc. It's amazing.
If you are only writing GQL over one REST API and you own both layers, I would just do GQL since its de-facto more flexible and will scale over time super well.
Best answer so far
I had the same thought like it is not good for uploading images or other hypermedia, I was searching for a suggestion, and I got the almost same though I had and I figure it out that it is not a bad idea to keep both rest and GraphQL together, thank for your suggestion.