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

GraphQL: A Retrospective

verve.co

Post reply on HN
Print view View original

21–30 of 48 posts

Re: GraphQL: A Retrospective

#21

Post by lacogubik »

ergothus wrote: post #13
avitzurel wrote: post #11

Earlier quoted context omitted.

1) Not true. GraphQL can work with GET and you can have cached queries (to avoid the query string length). This means, you can cache and you can do whatever you want with caching rules (source: We are running it in production for a long time) 2) This is largely up to you. You can have it as a thin skin or you can rely more on your server side logic. For us, we chose to have the frontend only handle presentation logic…

> GraphQL can work with GET So I've heard, which is why I chose my wording carefully. Does anyone actually do that?

Yes, we do [1]

We use GET for queries and POST for mutations. Though we are not caching our GETs atm.

[1] https://functional.works-hub.com

Re: GraphQL: A Retrospective

#22

Post by danr4 »

Off-topic if employees of the company are here: Friendly suggestion to work on the home page. I couldn't for the life of me understand what it is that company is about. The headline says NOTHING, and the paragraph after it is so confusing.

Re: GraphQL: A Retrospective

#23

Post by vga805 »

ergothus wrote: post #13
avitzurel wrote: post #11

Earlier quoted context omitted.

1) Not true. GraphQL can work with GET and you can have cached queries (to avoid the query string length). This means, you can cache and you can do whatever you want with caching rules (source: We are running it in production for a long time) 2) This is largely up to you. You can have it as a thin skin or you can rely more on your server side logic. For us, we chose to have the frontend only handle presentation logic…

> GraphQL can work with GET So I've heard, which is why I chose my wording carefully. Does anyone actually do that?

Apollo has a persisted queries option. And there's a PR open on relay modern for it. At least for queries, both of these let's you store the query itself on the server then use a GET request with a query hash and variables.

We use this at First Look Media on some of our sites.

Re: GraphQL: A Retrospective

#24

Post by vga805 »

ergothus wrote: post #7

I haven't yet had much luck in finding a GraphQL review that addresses my general concerns (I'm frontend). 1) GraphQL almost always means everything is POST, removing CDN and browser caching of GET-like requests is gone (and ServiceWorker caching just got much more complicated, nigh-impossible if CORS is involved). Everyone says "oh, clients can do better caching", as if that's not true without GraphQL. Still, the ca…

1. can be addressed with persisted queries. Apollo has this option: https://blog.apollographql.com/persisted-graphql-queries-wit...

and Relay Modern has a PR open for it.

Doing something similar without one of these graphql client libraries shouldn't be too tough.

Re: GraphQL: A Retrospective

#25

Post by seangrogg »

Someone wrote: post #16
seangrogg wrote: post #14

Earlier quoted context omitted.

I have no skin in this game, but... 1) This is more of a client implementation issue than a GraphQL issue; there's nothing about the GraphQL spec that mentions what HTTP method to use. Most people use POST because it makes the most sense in the general case but there's no reason you can't move the query from a POST body to a GET query string. 2) This question seems odd to me. The real win from GraphQL is a reduction…

”there's no reason you can't move the query from a POST body to a GET query string.” There’s disagreement on whether it is within the http spec ( https://stackoverflow.com/questions/978061/http-get-with-req... ), but you can also send a body with a GET request, and you wouldn’t be alone in that; Elastic uses it, too ( https://www.elastic.co/guide/en/elasticsearch/reference/curr... )

Yeah, I originally was going to put that into my reply but I figured talking about the fact that GET bodies are technically doable would open its own can of worms.

Re: GraphQL: A Retrospective

#26

Post by lilactown »

donatj wrote: post #8
revskill wrote: post #6

The best part about Graphql is that it's a query language for API. It was my dream years ago to have a query language from my frontend code. Using REST always seems a smell to me.

It's not really a query language. Certainly not a general purpose query language. It's more of a somewhat flexible RPC , honestly. It smells like a query language from a distance, but when you get close it smells much more of SOAP. For instance say I'm receiving a list of widgets, but I only need the red ones. Unless the API developers explicitly foresaw the need to include a color filter, I can't filter that on thei…

Something like datalog would have been much more impressive, but then the burden of implementing a parser for your upstream services would have probably been way too much of a burden. It's too general to be useful :(

Re: GraphQL: A Retrospective

#27

Post by dobs »

andrewingram wrote: post #19

One point of clarification (or correction, not quite sure) - using GraphQL as an API Gateway (as opposed to the GraphQL server directly talking to the data layer) for 1st-party clients is actually pretty common in the GraphQL world. What's less common is using the GraphQL server for service-to-service communication, though i've been aware of people using it this way for my entire 3 years with GraphQL. I'm not yet con…

One service-to-service case where I've found GraphQL extremely useful is report generation.

For example, in one case we had around a dozen services with fairly typical REST APIs, a few of which we wanted to pull large inter-related sets of information from. Using GraphQL allowed us to:

- Have a single large-but-human-readable query to retrieve all report data.

- Analyze deep nesting up front to determine opportunities for caching and eager loading.

- Abstract details regarding what data was coming from what service, plus handle any quirks (e.g. inconsistent auth strategies) at the GraphQL layer.

Without having to make many modifications to the underlying services. We also saw a two-order-of-magnitude performance improvement that would otherwise have required building out a lot of service-specific awareness into our reporting service.

Granted reporting is a unique case, but the simplified gateway layer and potential for query analysis are also major advantages as the number of API consumers grows.

Re: GraphQL: A Retrospective

#28

Post by AaronFriel »

GraphQL is a curious beast. Developed by Facebook as part of one of its many attempts to solve a fundamental problem for engineers: how to loosely couple the frontend and backend, while maximizing query performance and allowing flexibility in the frontend.

GraphQL does this, yes, but it's not particularly _smart_ about how caching works or how to avoid the Select N+1 problem. Their solution* is the blunt hammer that is Facebook's dataloader project which is basically: aggressively cache data model, pretend databases and joins and SQL doesn't exist, throw away any hope for ACID/consistency. Dataloader for example exposes all sorts of new and exciting types of inconsistency. This is hand-waved away because, I guess, consistency is boring and user expectations are low or irrelevant. (A comment with a missing edge to a post is invisible, a post with a missing edge to a comment has 0 comments. It'll all work itself out in the end.)

Curiously, Facebook went a long way down the road to fixing _this exact problem_ on the backend with a library called Haxl, written in Haskell. Haxl allows expressing relations between multiple data stores in a way that _looks_ like using an ORM, but under the hood creates a query and obviates the Select N+1 problem: a function which appears to select a post and for each comment retrieve an edge to the person who posted it will perform a single SELECT against the database, maintaining consistency with that store. There's no fundamental reason that couldn't be written in most dynamically typed languages or ORMs (though Haskell provides some really nice type level guarantees).

What's bizarre to me is that the former took off, and the latter is largely unknown outside the Haskell community.

* - Other ORMs have recognized this, and there are efforts underway for GraphQL backends in Python (Graphene) and Ruby, at least, to solve this.

Re: GraphQL: A Retrospective

#29

Post by ctulek »

AaronFriel wrote: post #28

GraphQL is a curious beast. Developed by Facebook as part of one of its many attempts to solve a fundamental problem for engineers: how to loosely couple the frontend and backend, while maximizing query performance and allowing flexibility in the frontend. GraphQL does this, yes, but it's not particularly _smart_ about how caching works or how to avoid the Select N+1 problem. Their solution* is the blunt hammer that…

I didn’t understand why you have to use caching with DataLoader. I am also not sure about what you mean by inconsistency. The n + 1 query problem is usually solved by making two consecutive queries to the database. One for the root element and one for the total list of all edges, thanks to DataLoader. What is the problem with that?

Re: GraphQL: A Retrospective

#30

Post by tirumaraiselvan »

AaronFriel wrote: post #28

GraphQL is a curious beast. Developed by Facebook as part of one of its many attempts to solve a fundamental problem for engineers: how to loosely couple the frontend and backend, while maximizing query performance and allowing flexibility in the frontend. GraphQL does this, yes, but it's not particularly _smart_ about how caching works or how to avoid the Select N+1 problem. Their solution* is the blunt hammer that…

Hasura GraphQL engine also is a Haskell based engine that solves the N+1 query problem by compiling the incoming request into a single SQL query: https://github.com/hasura/graphql-engine/tree/master/server

EDIT: /s/package/engine

Post reply on HN