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

After 6 years, I'm over GraphQL

bessey.dev

Post reply on HN
Print view View original

531–540 of 721 posts

Re: After 6 years, I'm over GraphQL

#531

Post by culi »

4hg4ufxhy wrote: post #497
culi wrote: post #449

Earlier quoted context omitted.

This isn't actually that terrible since these fields are cached by a client-side library like Apollo. If the query has already been made elsewhere then it won't be doing any extra work The only downside is if one of those unused fields changes due to a mutation then all components using that field will rerender (ofc I'm assuming React here). Again, not the biggest concern if you've got your memoization set up correct…

You missed the actual downside of this only works if there is no mutations in the background from other clients/processes making your cache stale.

you can poll or subscribe within GQL. The same solutions you'd use with a rest-based api

Re: After 6 years, I'm over GraphQL

#532

Post by lbourdages »

PurpleRamen wrote: post #530

> Tab Grouping, Vertical Tabs, and our handy Sidebar will help you stay organized no matter how many tabs you have open — whether it’s 7 or 7,500. Not sure if this will be good. This reads like they will add Vertical Tabs as a Sidebar, like all the other vertical tab-addons doing it now. But since the Quantum-update there is demand for a second sidebar dedicated for tabs, because as it's now, sidebar is really annoyi…

I think you replied to the wrong post :)

Re: After 6 years, I'm over GraphQL

#534

Post by RHSeeger »

serpix wrote: post #102
RHSeeger wrote: post #89

Earlier quoted context omitted.

Can you explain what you mean by this? The GraphQL API you expose allows only a certain schema. Sure, callers can craft a request that is slow because it's asking for too much, but - Each individual thing available in the request should be no less timely to handle than it would via any other api - Combining too many things together in a single call isn't a failing of the GraphQL endpoint, it's a failing of the caller…

Then we just come back full round trip to REST where the backend clearly defines what is allowed and what is returned. So using GraphQL it is unnecessary complicated to safeguard against a caller querying for all of the data and then some. For example the caller queries nested structures ad infinitum possibly even triggering a recursive loop that wakes up somebody at 3am.

But GraphQL doesn't allow for infinitely nested queries; the query itself has to include as much depth as it wants in the response.

> Then we just come back full round trip to REST

Except that GraphQL allows the back end to define the full set of fields that are available, and the front end can ask for some subset of that. This allows for less load; both on the network and on what the back end needs to fetch data for.

From a technical perspective, GraphQL is (effectively) just a REST API that allows the front end to specify which data it wants back.

Re: After 6 years, I'm over GraphQL

#535

Post by RHSeeger »

danielheath wrote: post #103
RHSeeger wrote: post #89

Earlier quoted context omitted.

Can you explain what you mean by this? The GraphQL API you expose allows only a certain schema. Sure, callers can craft a request that is slow because it's asking for too much, but - Each individual thing available in the request should be no less timely to handle than it would via any other api - Combining too many things together in a single call isn't a failing of the GraphQL endpoint, it's a failing of the caller…

The problem is that the client team can - without notice - change their query patterns in a way that creates excess load when deployed. When you use the "REST" / JSON-over-HTTP pattern which was more common in 2010, changes in query patterns necessarily involve the backend team, which means they are aware of the change & have an opportunity to get ahead of any performance impact.

And the client team using a REST API can do the exact same thing, by making more calls. There's no real difference between "more calls" and "same amount of calls, but requests more data".

That being said, it's a lot easier to setup caching for REST calls.

Re: After 6 years, I'm over GraphQL

#536

Post by hi-v-rocknroll »

hansonkd wrote: post #177
mattbrewsbytes wrote: post #140

Earlier quoted context omitted.

> RPC and REST are just more straightforward to monitor, log, cache, authorize and debug. REST API's are a proven solution for the problem of other apps, including front-ends, needing data from a data store. Using JSON is much improved over the days of XML and SOAP. Beyond that there haven't been advancements in technology that cause fundamental shifts in that problem space. There have been different opinions about s…

REST APIS suck for nested resources. GraphQL is a huge breakthrough in managing them. Ever seen an engineer do a loop and make n+1 REST calls for resources? It happens more often then you think because they don't want to have to create a backend ticket to add related resources to a call. With internal REST for companies I have seen so many single page specific endpoints. Gross. > There have been different opinions ab…

Perhaps that's the case for server-side transactions and ORMs over REST and gRPC to coordinate rather than allowing the front-end to diddle with data however it likes.

And, resources with an index option obviously should have a db index or unique index.

The challenges with GraphQL are that it makes it too easy to DoS services, leak internal data, break referential integrity, and there were a great deal of tools, infrastructure, and monitoring systems already available for REST (and gRPC to a degree).

Company standards for REST and coding style can and should be set in the diff review pipeline. Another facet is setting standards to minimize duplication of effort or exposing a greater attack surface.

Re: After 6 years, I'm over GraphQL

#537

Post by RHSeeger »

foobarian wrote: post #183
jerf wrote: post #161

Earlier quoted context omitted.

My blocker on ever using GraphQL is generally if you've got enough data to need GraphQL you're hitting a database of some kind... and I do not generally hand direct query access to any client, not even other projects within the same organization, because I've spent far too much time in my life debugging slow queries. If even the author of a system can be surprised by missing indices and other things that cause slow q…

It seems there is a recent trend of using adapters that expose data stores over graphql automatically, which is kind of scary. The graphql usage I'm used to works more or less the same as REST. You control the schema and the implementation, you control exactly how much data store access is allowed, etc. It's just like REST except the schema syntax is different. The main advantage of GraphQL IMO is the nice introspect…

> It seems there is a recent trend of using adapters that expose data stores over graphql automatically, which is kind of scary.

I think that's the part where I have a disconnect. To me, both REST and GraphQL likely need to hit the database to get their data, and I would be writing the code that does that. Having the front end's call directly translated to database queries seems insane. The same would be true if you wrote a REST API that hit the database directly and took table/field names from query parameters; only... we don't do that because it would be stupid.

Re: After 6 years, I'm over GraphQL

#538

Post by RHSeeger »

int_19h wrote: post #458
foobarian wrote: post #179

Earlier quoted context omitted.

> changes in query patterns necessarily involve the backend team, How does this follow? A client team can decide to e.g. put up a cross-sell shelf on a low-traffic page by calling a REST endpoint with tons of details and you have the same problem. I don't see the difference in any of these discussions, the only thing different is the schema syntax (graphql vs. openapi)

GQL is far more flexible wrt what kind of queries it can do (and yes, it can be constrained, but this flexibility is the whole point ). Which means that turning a cheap query into an expensive one accidentally is very easy. A hand-coded REST endpoint will give you a bunch of predefined options for filtering, sorting etc, and the dev who implements it will generally assume that all of those can be used, and write the…

> and yes, it can be constrained, but this flexibility is the whole point

Flexibility within the constraints of what the back end can safely support.

To me, the "whole point" of GraphQL is to be able to have the client ask for only the data they need, rather than have a REST API that returns _everything_ and letting the front end throw away what they don't need (which incurs more load).

If you can't support returning certain configurations of data, then... don't.

Re: After 6 years, I'm over GraphQL

#540

Post by wasyl »

joegibbs wrote: post #514
nfw2 wrote: post #453

Earlier quoted context omitted.

Whitelisting the queries that clients can use in prod actually doesn't seem like a bad option to avoid a lot of these security issues, assuming you control the clients

Yeah but then you’ve basically just remade REST, but the queries are stored in the frontend instead.

I don't understand this argument, how is it "remade REST" if you still don't need to implement and maintain an endpoint with exactly the data that clients need? Persisted/whitelisted queries require much less backend effort, and are decidedly different from REST, the only similarity is in having a closed set of possible actions. Perhaps you're thinking in terms of public APIs where I agree limiting available GraphQL queries makes little sense. But for internal APIs, whitelisting whatever queries current clients need isn't any less convenient
Post reply on HN