DEV Community

loading...

Discussion on: 4 reasons why you should use GraphQL over REST APIs

blessingartcreator profile image
Blessing Hirwa Author

And also remember that here we're focusing on the amount of data to be returned.

Thread Thread
athomsfere profile image
Austin French

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:

GET /Groups?$filter=UserName eq 'jsmith1958` & $select='groupId'
Enter fullscreen mode Exit fullscreen mode

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=UserName like 'jsmith1958`
Enter fullscreen mode Exit fullscreen mode

where the SQL will now be very unoptimized:

 SELECT * FROM GROUPS
     WHERE UserName LIKE '%JSMITH1985%'
Enter fullscreen mode Exit fullscreen mode

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:

  1. Prototyping
  2. Rapid Development
  3. New Applications with relatively narrow scope
Thread Thread
blessingartcreator profile image
Blessing Hirwa Author

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?

Thread Thread
kitsunde profile image
Kit Sunde

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.

Thread Thread
blessingartcreator profile image
Blessing Hirwa Author

yes, but then GraphQL in this case is faster than REST. right?

Thread Thread
athomsfere profile image
Austin French

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.

Thread Thread
blessingartcreator profile image
Blessing Hirwa Author

When I say faster I mean data fetching and low bandwidth

Thread Thread
athomsfere profile image
Austin French

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

Thread Thread
blessingartcreator profile image
Blessing Hirwa Author

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.

Some comments have been hidden by the post's author - find out more