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...
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.