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

React, Relay and GraphQL: Under the Hood of the Times Website Redesign

open.nytimes.com

Post reply on HN
Print view View original

11–20 of 113 posts

Re: React, Relay and GraphQL: Under the Hood of the Times Website Redesign

#11

Post by raarts »

ruslan_talpa wrote: post #8
scottmf wrote: post #6

Earlier quoted context omitted.

Which n+1 problems doesn't dataloader solve?

It eliminates n+1 but not in a perfect way. If you have a 3 level query (3 tables), the best you can hope for is to get 3 sequential queries, like get first level, collect the ids, request the second level, collect the ids, get 3rd level. It gets even more complicated teh more levels you and the bigger the dataset returned. all of this can be done using a single join which is one roundtrip and it's faster.

Thank you, thank you. A critical piece of information.

Re: React, Relay and GraphQL: Under the Hood of the Times Website Redesign

#12

Post by zackify »

colemorrison wrote: post #2

I've looked at GraphQL a number of times. Does anyone have any practical examples of integrating it with backend(s), APIs, and/or specific databases? So instead of "we use GraphQL, much love" + basic example and how it looks on React - a "here's how we take that structure and resolve it and return it." Because that structure looks amazingly sweet - but if in the background it's requiring circles of work, work and rew…

I agree. All of the examples are trivial. There are a lot of nice things about graphql. Yet there are a lot of problems and annoyances other things don’t have such as query batching. Even authorizing certain graphql queries / mutations is not a trivial thing. I’ve been able to solve a couple of these things in my own app, but it’s just not something built into the spec.

Re: React, Relay and GraphQL: Under the Hood of the Times Website Redesign

#13

Post by mambodog »

ruslan_talpa wrote: post #8
scottmf wrote: post #6

Earlier quoted context omitted.

Which n+1 problems doesn't dataloader solve?

It eliminates n+1 but not in a perfect way. If you have a 3 level query (3 tables), the best you can hope for is to get 3 sequential queries, like get first level, collect the ids, request the second level, collect the ids, get 3rd level. It gets even more complicated teh more levels you and the bigger the dataset returned. all of this can be done using a single join which is one roundtrip and it's faster.

If you have low latency queries (eg. because most things hit cache rather than db) sequential queries aren't as much of a problem. Being able to join everything into one query, on the other hand, is a luxury which can be hard to maintain at scale.

In the 'join in SQL' case you could identify particular cases which are doing sequential queries and implement a different loader which just does one. It's not automatic but perhaps in most cases it's not necessary to do this step anyway. In the worst case you're back to doing as much work as you would for a bespoke API endpoint, but that's not the typical case. How much of a problem this ends up being in practice very much depends on the type of app you're building and how you intend to scale it.

Re: React, Relay and GraphQL: Under the Hood of the Times Website Redesign

#14

Post by jarym »

ruslan_talpa wrote: post #5
colemorrison wrote: post #2

I've looked at GraphQL a number of times. Does anyone have any practical examples of integrating it with backend(s), APIs, and/or specific databases? So instead of "we use GraphQL, much love" + basic example and how it looks on React - a "here's how we take that structure and resolve it and return it." Because that structure looks amazingly sweet - but if in the background it's requiring circles of work, work and rew…

You've hit a (pain) point. While graphql reduces the amount of trips to the backend for the browser, those round trips get pushed down to a lower level, between backend and db. The reference graphql-js implementation, while at first looks so easy, you just write a resolver for a field, makes it oh so easy to have terrible n+1 problems. dataloader helps a bit but it's not as optimal as it can be. You need to be very c…

That's really cool - we're doing the same thing, translating entire queries into a single SQL statement!

Re: React, Relay and GraphQL: Under the Hood of the Times Website Redesign

#16

Post by djmashko2 »

colemorrison wrote: post #2

I've looked at GraphQL a number of times. Does anyone have any practical examples of integrating it with backend(s), APIs, and/or specific databases? So instead of "we use GraphQL, much love" + basic example and how it looks on React - a "here's how we take that structure and resolve it and return it." Because that structure looks amazingly sweet - but if in the background it's requiring circles of work, work and rew…

This is definitely a real problem and we just launched a website yesterday which we hope will grow into a resource for this kind of more advanced content: http://www.graphql.com/guides/

You can also see a lot of examples of GraphQL server code for JS here: https://github.com/apollographql/launchpad

It includes connecting to DBs, APIs, etc.

Re: React, Relay and GraphQL: Under the Hood of the Times Website Redesign

#17

Post by foota »

ruslan_talpa wrote: post #9
foota wrote: post #7

Earlier quoted context omitted.

You don't have to worry so much about n+1 (once you're using dataloader) as much as you do deeply nested queries, or queries that run against a large number of datatypes.

i am not sure i follow, the deeper the query or bigger the returned dataset, the worse the performance of a dataloader type solution (see my other comment).

We're agreeing here, I think. I'm saying that after taking care of the n+1 problem by using dataloader, you still have to worry about deeply nested queries.

Re: React, Relay and GraphQL: Under the Hood of the Times Website Redesign

#18

Post by ruslan_talpa »

mambodog wrote: post #13
ruslan_talpa wrote: post #8

Earlier quoted context omitted.

It eliminates n+1 but not in a perfect way. If you have a 3 level query (3 tables), the best you can hope for is to get 3 sequential queries, like get first level, collect the ids, request the second level, collect the ids, get 3rd level. It gets even more complicated teh more levels you and the bigger the dataset returned. all of this can be done using a single join which is one roundtrip and it's faster.

If you have low latency queries (eg. because most things hit cache rather than db) sequential queries aren't as much of a problem. Being able to join everything into one query, on the other hand, is a luxury which can be hard to maintain at scale. In the 'join in SQL' case you could identify particular cases which are doing sequential queries and implement a different loader which just does one. It's not automatic bu…

Saying join is a luxury is a dangerous thing :) (for impressional devs :)) 99% of projects are not "at FB scale" :) so join is exactly the right thing to use, it's been tuned over decades so until your scale/dataset does not outgrow one box (and there are big boxes now), you are not going to do a better job then the query optimiser (cause after all that is what you are trying to do).

Re: React, Relay and GraphQL: Under the Hood of the Times Website Redesign

#19

Post by ruslan_talpa »

jarym wrote: post #14
ruslan_talpa wrote: post #5

Earlier quoted context omitted.

You've hit a (pain) point. While graphql reduces the amount of trips to the backend for the browser, those round trips get pushed down to a lower level, between backend and db. The reference graphql-js implementation, while at first looks so easy, you just write a resolver for a field, makes it oh so easy to have terrible n+1 problems. dataloader helps a bit but it's not as optimal as it can be. You need to be very c…

That's really cool - we're doing the same thing, translating entire queries into a single SQL statement!

I hope you are using PostgreSQL! :) Check out PostgREST and the types of queries it generates
Post reply on HN