Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How and why GraphQL will influence the Sourcehut alpha

sourcehut.org

Post reply on HN
Print view View original

151–160 of 232 posts

Re: How and why GraphQL will influence the Sourcehut alpha

#151

Post by jakevoytko »

AsyncAwait wrote: post #131
cnorthwood wrote: post #129

Earlier quoted context omitted.

I don't see GraphQL as an ORM type solution, I see it more like a replacement for REST.

What would be the advantage of GraphQL over gRPC in a REST replacement scenario?

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.

Re: How and why GraphQL will influence the Sourcehut alpha

#152

Post by matt_kantor »

cletus wrote: post #65

So I've now had the opportunity to use both GraphQL and protocol buffers ("protobufs" is the more typical term) professionally and I have some thoughts on this. 1. Protobufs use integer IDs for fields. GraphQL uses string names. IMHO this is a clear win for protobufs. Changing the name of a field of GraphQL is essentially impossible. Once a name is there it's there forever (eg mobile client versions are out there for…

> 3. Protobuf's notions of required vs optional fields was a design mistake that's now impossible to rectify without breaking changes.

Can you elaborate on this?

I've barely used protobufs, but in thrift I've found optional fields to be very useful.

Re: How and why GraphQL will influence the Sourcehut alpha

#153

Post by staticassertion »

kabes wrote: post #42
searchableguy wrote: post #33

Earlier quoted context omitted.

That is upto the graphql framework and the consumers of them. Graphql is just a query language. You need to have data loader (batching) on the backend to avoid n+1 queries and some other similar stuff with cache to improve the performance. You also have cache and batching on the frontend usually. Apollo client (most popular graphql client in js) uses a normalized caching strategy (overkill and a pain). For rate/abuse…

"You have to calculate the burden of the query before you execute it so you don't end up crashing your database." This sounds like disaster waiting to happen.

It's not nearly as complex as paging, which has a similar purpose of limiting single-query complexity.

Re: How and why GraphQL will influence the Sourcehut alpha

#154

Post by kodablah »

umvi wrote: post #150
WhatIsDukkha wrote: post #31

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/w…

Super useful for bandwidth sensitive situations where you need to piece together a small amount of data from several APIs that normally return a large amount of data.

Pardon my naivete, are the benefits of the flexibility that GraphQL give worth the unpredictability costs (or costs of customizing to add limits) of that same flexibility compared to writing a tailored server side call to do those calls and return the limited data instead?

Re: How and why GraphQL will influence the Sourcehut alpha

#155

Post by real_ben_michel »

WhatIsDukkha wrote: post #31

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/w…

Having seen many product teams implement graphQL, concerns were never around performances, and more around speed of development.

A typical product would require integrations with several existing APIs, and potentially some new ones. These would be aggregated (and normalised) into a single schema built on top of GraphQL. Then the team would build different client UIs and iterate on them.

By having a single queryable schema, it's very easy to build and rebuild interfaces as needed. Tools like Apollo and React are particularly well suited for this, as you can directly inject data into components. The team can also reason on the whole domain, rather than a collection of data sources (easier for trying out new things).

Of course, it would lead to performance issues, but why would you optimise something without validating it first with the user? Queries might be inefficient, but with just a bit of caching you can ensure acceptable user experience.

Re: How and why GraphQL will influence the Sourcehut alpha

#156

Post by GordonS »

kodablah wrote: post #154
umvi wrote: post #150

Earlier quoted context omitted.

Super useful for bandwidth sensitive situations where you need to piece together a small amount of data from several APIs that normally return a large amount of data.

Pardon my naivete, are the benefits of the flexibility that GraphQL give worth the unpredictability costs (or costs of customizing to add limits) of that same flexibility compared to writing a tailored server side call to do those calls and return the limited data instead?

Yeah, I just don't get it - even if you use GraphQL, you're going to have to do server-side code to make the calls to the different backends.

Maybe it's just that the backend devs in my last project werenyevery good, but the backend GraphQL code was ridiculously complex and impossible to reason about.

Re: How and why GraphQL will influence the Sourcehut alpha

#157

Post by satvikpendem »

kodablah wrote: post #154
umvi wrote: post #150

Earlier quoted context omitted.

Super useful for bandwidth sensitive situations where you need to piece together a small amount of data from several APIs that normally return a large amount of data.

Pardon my naivete, are the benefits of the flexibility that GraphQL give worth the unpredictability costs (or costs of customizing to add limits) of that same flexibility compared to writing a tailored server side call to do those calls and return the limited data instead?

Yes, as this is the main reason that Facebook created GraphQL, it is expensive for mobile phones to query that much data. Something else interesting is that while you begin to write the tailored server side call, and you optimize it, you will end up with something that looks like GraphQL anyway.

Re: How and why GraphQL will influence the Sourcehut alpha

#158

Post by kodablah »

satvikpendem wrote: post #157
kodablah wrote: post #154

Earlier quoted context omitted.

Pardon my naivete, are the benefits of the flexibility that GraphQL give worth the unpredictability costs (or costs of customizing to add limits) of that same flexibility compared to writing a tailored server side call to do those calls and return the limited data instead?

Yes, as this is the main reason that Facebook created GraphQL, it is expensive for mobile phones to query that much data. Something else interesting is that while you begin to write the tailored server side call, and you optimize it, you will end up with something that looks like GraphQL anyway.

Server-to-server GraphQL seems much more reasonable as both sides are controlled. It's the client-to-server I have less of a justification for compared to targeted calls w/ individual, limited contracts that are quantifiable and optimizable. I have witnessed the costs of allowing highly flexible data fetching from the client once it grows large.

Re: How and why GraphQL will influence the Sourcehut alpha

#159

Post by iso-8859-1 »

square_usual wrote: post #72
procinct wrote: post #46

Earlier quoted context omitted.

Especially considering they employed the BDFL.

No longer the BDFL, unfortunately.

The BDFL is a position that you have for life. It is embedded in the definition. So it is impossible to shed the title.

Re: How and why GraphQL will influence the Sourcehut alpha

#160

Post by hn_throwaway_99 »

Based on the top comments in this thread, I can see my previous attempts to dispel mistaken beliefs around graphql have failed, but I'll still try!

1. The biggest mistake GraphQL made was putting 'QL' in the name so people think it's a query language comparable to SQL. It's not: https://news.ycombinator.com/item?id=23120997

2. Some benefits of GraphQL over REST: https://news.ycombinator.com/item?id=23124862

Post reply on HN