←back to thread

How and why GraphQL will influence the Sourcehut alpha

(sourcehut.org)
153 points michaelanckaert | 4 comments | 11 Jun 20 04:46 UTC | HN request time: 0.863s | source
Show context
WhatIsDukkha ◴[11 Jun 20 06:44 UTC] No.23485847[source]▶
I don't understand the attraction to Graphql. (I do understand it if maybe you actually want the things that gRPC or Thrift etc gives you)

It seems like exactly the ORM solution/problem but even more abstract and less under control since it pushes the orm out to browser clients and the frontend devs.

ORM suffer from being at beyond arms length from the query analyzer in the database server.

https://en.wikipedia.org/wiki/Query_optimization

A query optimizer that's been tuned over decades by pretty serious people.

Bad queries, overfetching, sudden performance cliffs everywhere.

Graphql actually adds another query language on top of the normal orm problem. (Maybe the answer is that graphql is so simple by design that it has no dark corners but that seems like a matter of mathematical proof that I haven't seen alluded to).

Why is graphql not going to have exactly this problem as we see people actually start to work seriously with it?

Four or five implementations in javascript, haskell and now go. From what I could see none of them were mentioning query optimization as an aspiration.

replies(19): >>23485889 #>>23485918 #>>23485953 #>>23485962 #>>23486202 #>>23486714 #>>23486794 #>>23487403 #>>23487603 #>>23487611 #>>23487709 #>>23488354 #>>23488907 #>>23489619 #>>23489986 #>>23490334 #>>23491786 #>>23492176 #>>23497167 #
1. cnorthwood ◴[11 Jun 20 13:56 UTC] No.23488907[source]▶
I don't see GraphQL as an ORM type solution, I see it more like a replacement for REST.
replies(1): >>23489005 #
2. AsyncAwait ◴[11 Jun 20 14:05 UTC] No.23489005[source]▶
What would be the advantage of GraphQL over gRPC in a REST replacement scenario?
replies(1): >>23490132 #
3. jakevoytko ◴[11 Jun 20 15:54 UTC] No.23490132[source]▶
I'm only passingly familiar with gRPC, so forgive me if it offers some kind of linking like what I describe below.

In REST (and seemingly in gRPC), you define these siloed endpoints to return different types of data. If we're imagining a Twitter REST API, you might imagine Tweet and User endpoints. In the beginning it's simple - the Tweet endpoint returns the message, the user ID, and some metadata. You can query the User

Then Twitter continues to develop. Tweets get media attachments. They get retweets. They get accessibility captions. The Tweet endpoint expands. The amount of information required to display a User correctly expands. Do you inline it in the Tweet? Do you always require a separate request to the User, which is also growing?

As the service grows, you have this tension between reusability and concision. Most clients need only some of the data, but they all need different data. If my understanding of gRPC is correct, it would have this similar kind of tension: business objects that gain responsibilities will likely gain overhead with every new object that is added, since the clients have no way of signaling which ones they need or don't need.

In GraphQL, you define your object model separately from how it's queried. So you can define all of these things as separate business objects: a Tweet has a User, Users have Tweets, Tweets can link to Media which has accessibility caption fields, etc. Starting from any entry point to the graph, you can query the full transitive closure of the graph that you can reach from that entry point, but you don't pay for the full thing.

This relaxes the tension between reusability and concision. Each querier can request just the data that it needs, and assuming the backend supports caching and batching when appropriate, it can have some assurances that the backend implementation is only paying for what you use.

replies(1): >>23490677 #
4. GordonS ◴[11 Jun 20 16:44 UTC] No.23490677{3}[source]▶
Thanks for posting this - I think your Twitter example is first I've ever read where I've actually been able to see any real benefit over REST.