GraphQL is all cool and dandy until you have files to send over. I am aware that you can send it via blob, but who does store images as blobs in database??? I also held discussions about converting blobs on the backend or sending them over to the third parties that can handle it and store it as a file with url of the image in response. Took significant amount of time to process it all and that was just bad UX. Remember - your users are using your app and they don't really care what's under the hood.
REST API over fetching and under fetching can be resolved on the REST API, I am sure that you do it yourself if you are fullstack so you have control what is sent over which API route or if you are frontend, I know it is difficult, but please try to communicate with, you know, backend guy who handles the REST API routes. It's not so hard.
I have used both, both have their use cases. GraphQL for Jamstack sites is great, for much writing to the DB and especially for files handling I don't find it so attractive.
Sending blob is not strange . you can do it also in REST, and inside backend you can convert it into file, store the name in database and file in your storage
In this case you'll get all data related to group_id=23 which is not needed. In our case we want to get only the post title that has group_id=23. For REST we get all data related to that group id but for GraphQL we'll only get the value that we asked for, nothing more.
Which might perform just as well, but it's more than the UI should care about, and has some concerns.
Perhaps this is written instead:
GET/Groups?$filter=UserNamelike'jsmith1958`
where the SQL will now be very unoptimized:
SELECT*FROMGROUPSWHEREUserNameLIKE'%JSMITH1985%'
Or perhaps they decide to filter on a non-indexed column (Since the UI doesn't know or care what columns are indexed).
And as much as we'd all like to say: "Code review" the truth is, I'm inheriting tech debt from dozens of coders around the world where this has slipped through the cracks.
The UI folks often don't know the intricacies of the API or DB. The expectation of the architecture should be forgiving enough that you can't write a really bad query. And IMO a good API along with using swagger is the ideal route.
Ideal isn't always best though, and I can see where someone might choose GraphQL:
But in the conclusion I said that Graphql is not always the best choice. You'll use it depending on the structure of your app and the type of data you want to play with. Makes sense?
It's pretty fair to say that GraphQL being primarily concerned with the query side of things lets you construct complex graph lookups by design. If anything it's also what makes it difficult to deal with on the backend side because of permissions, caching and such.
However, it's not fair to say REST doesn't allow granular selections when it doesn't at all cover whether or not you can return selective filtering or selective returns. It's entirely left up to the implementer, and if you follow a standard that's RESTful like jsonapi.org then partial selects and filtering is covered.
Then it would certainly have more to do with specific implementations, not GQL over all REST implementations.
REST is after all, just a set of concepts. I'd a well designed RESTful service is faster than 90% of all GQL APIs.
If you put a well designed GraphQL API against a well designed REST API:
They probably tie overall. Sometimes they would be equal, sometimes each one would be faster.
Ideally, if I was debating between a new application and needed to decide between a webAPI and REST, vs GraphQL I'd consider:
Industry Support
Readability
Maintainability
Performance
RESTful APIs win 3/4 of those IMO. If performance became my only concern, I'd grab a demo database and do some hard testing. If GraphSQL won, but within a margin of error: I'd still pick REST because of it's other strengths.
I mean, I've recommend changes on tech stacks because of performance before.
EF 6 to EF 7: reduced queries by 50%.
EF 7 to Dapper: 75% reduction.
Those are huge performance gains. If GraphQL could do that for a given design, I'd be on it.
In fact, I am a little curious what I could do with it. But I suspect I can keep a RESTful service, using Dapper (I am a fullstack .NET guy) more performant than a graphql API...
GraphQL is all cool and dandy until you have files to send over. I am aware that you can send it via blob, but who does store images as blobs in database??? I also held discussions about converting blobs on the backend or sending them over to the third parties that can handle it and store it as a file with url of the image in response. Took significant amount of time to process it all and that was just bad UX. Remember - your users are using your app and they don't really care what's under the hood.
REST API over fetching and under fetching can be resolved on the REST API, I am sure that you do it yourself if you are fullstack so you have control what is sent over which API route or if you are frontend, I know it is difficult, but please try to communicate with, you know, backend guy who handles the REST API routes. It's not so hard.
I have used both, both have their use cases. GraphQL for Jamstack sites is great, for much writing to the DB and especially for files handling I don't find it so attractive.
just my 2c
Sending blob is not strange . you can do it also in REST, and inside backend you can convert it into file, store the name in database and file in your storage
You can add Content-Type to the response in REST, put the path directly to "src" attribute to your img.
If your API is under or over fetching: You wrote a poor API method. It's not about REST vs New ShINy TeKS.
And where I haven't used GraphQL, I have used something with a similar concept ( OData) and everything about the concept to me, is weird and wrong.
The logic behind over fetching is that you can't specify which resources you want in REST, you get result and then filter it to get what you want.
If you need to filter data, you might be missing a route (for example getting a specific thing with
/api/things/:id).You can also use path argument to filter out things (with
/api/things?group_id=23) or even stick those arguments in the request's body.In this case you'll get all data related to
group_id=23which is not needed. In our case we want to get only the post title that hasgroup_id=23. ForRESTwe get all data related to that group id but forGraphQLwe'll only get thevaluethat we asked for, nothing more.And this is why I say your API is bad, and it isn't on the fault of REST if this is your problem.
There's nothing wrong with simple methods, that return exactly what you need.
According to your case what do you think this API will return? I want us to be in the same line.
And also remember that here we're focusing on the amount of data to be returned.
I would expect a single or list of group ids that the user belongs to. Depending on what a group is, and if the user could be in multiple groups.
(as an off the cuff example).
using odata, and I believe GraphQL the query would look something like:
Which might perform just as well, but it's more than the UI should care about, and has some concerns.
Perhaps this is written instead:
where the SQL will now be very unoptimized:
Or perhaps they decide to filter on a non-indexed column (Since the UI doesn't know or care what columns are indexed).
And as much as we'd all like to say: "Code review" the truth is, I'm inheriting tech debt from dozens of coders around the world where this has slipped through the cracks.
The UI folks often don't know the intricacies of the API or DB. The expectation of the architecture should be forgiving enough that you can't write a really bad query. And IMO a good API along with using swagger is the ideal route.
Ideal isn't always best though, and I can see where someone might choose GraphQL:
But in the conclusion I said that Graphql is not always the best choice. You'll use it depending on the structure of your app and the type of data you want to play with. Makes sense?
It's pretty fair to say that GraphQL being primarily concerned with the query side of things lets you construct complex graph lookups by design. If anything it's also what makes it difficult to deal with on the backend side because of permissions, caching and such.
However, it's not fair to say REST doesn't allow granular selections when it doesn't at all cover whether or not you can return selective filtering or selective returns. It's entirely left up to the implementer, and if you follow a standard that's RESTful like jsonapi.org then partial selects and filtering is covered.
yes, but then GraphQL in this case is faster than REST. right?
Faster how? And faster than what exactly?
Faster than REST through EF 4? Maybe, possibly, even probably.
Faster than REST using Dapper or EF 6/7? Likely not. Assuming similar scope and queries.
I would be interested to see how some problems are solved in GraphQL, vs more traditional solutions.
Most of my original comment was also towards Ivan, and agreeing with his comment.
When I say faster I mean
data fetchingandlow bandwidthThen it would certainly have more to do with specific implementations, not GQL over all REST implementations.
REST is after all, just a set of concepts. I'd a well designed RESTful service is faster than 90% of all GQL APIs.
If you put a well designed GraphQL API against a well designed REST API:
They probably tie overall. Sometimes they would be equal, sometimes each one would be faster.
Ideally, if I was debating between a new application and needed to decide between a webAPI and REST, vs GraphQL I'd consider:
Industry Support
Readability
Maintainability
Performance
RESTful APIs win 3/4 of those IMO. If performance became my only concern, I'd grab a demo database and do some hard testing. If GraphSQL won, but within a margin of error: I'd still pick REST because of it's other strengths.
I mean, I've recommend changes on tech stacks because of performance before.
EF 6 to EF 7: reduced queries by 50%.
EF 7 to Dapper: 75% reduction.
Those are huge performance gains. If GraphQL could do that for a given design, I'd be on it.
In fact, I am a little curious what I could do with it. But I suspect I can keep a RESTful service, using Dapper (I am a fullstack .NET guy) more performant than a graphql API...
It always depend on the kind of project you're building. But still at the end of the day you find both REST and GraphQL to be good.