For further actions, you may consider blocking this person and/or reporting abuse
Read next
API Security Testing Tools: Key Features & 8 Tools to Know
Pynt.io -
From Idea to Launch: Mistakes to avoid in your Development process
Namubiru Rose -
Dynamic Values: Transforming API Testing for Real-World Scenarios
Wanda -
Top 6 SOAP API Documentation Tools to Streamline Your Development Process
Walse -
Top comments (11)
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.
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.
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.
As the others said, it depends on requirements and needs.
Taking from GraphQL vs REST: Overview:
I don't think they can be pitted against in every case, it really depends on what you need. You can also use both as it's suggested in the article :)
I feel that most devs are misusing GraphQL and what they really should be using is the JSON API specs for their REST API. It offers most of the features that people are looking for when migrating to GraphQL.
That said; I think probably 80% of devs only use GraphQL for Relay and not as a standalone/public API.
I've liked working with GraphQL recently, it can be a very powerful tool if you know what you're building.
REST is of course more standard and more people are familiar with it. To that end, it depends on who's going to be consuming it.
It really depends on how you expect the data to be used. If unsure I'd go REST to be more standard.
There are specific times where Graphql is much better than REST like APIs. By default I would stick with REST style APIs unless you have a specific reason to use GraphQL. GraphQL is better for Facebook, but for most apps it's adding a lot of complexity. I remember a long time ago being really excited about ORMs like hibernate and how simple they made database access. Nowadays I'm also appreciating the simplicity of using SQL when writing non CRUD database operations (bulk ops and reports, for example). The ORM hides complexity, but also obscures performance issues. GraphQL is like that. It moves complexity around, and this could be the right move for you, but I think most of the time you might as well safe yourself the code bloat.
I've never used GraphQL, but if I was starting a project I'd use it because it looks cool af.