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

21–30 of 113 posts

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

#21

Post by lioeters »

sAbakumoff wrote: post #15

I tried Relay but found it ridiculously stupid that I need to change the graphql API on my server in order to satisfy the relay concepts(universal id, connections) so we rejected the idea and decided to go with the good old fashioned redux

I appreciate your perspective, as I've been considering whether to invest time into learning GraphQL. It's informative to know that it's not suitable for some use cases. Probably could have done without the inflammatory adjectives.. ;)

As far as the criticism, would you be kind enough to explain what you mean by "relay concepts", and how GraphQL failed to satisfy those needs?

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

#22

Post by mden »

TekMol wrote: post #20

Do you guys think it makes sense for a newspaper to use React for the frontend? I would think React might make sense for realtime dashboards and similar webapps. But does it make sense for displaying articles, navigation and ads?

Why not? Newspapers are fairly complex websites too and React is amazing at reducing code complexity, especially when compared to using vanilla js. There are other libraries that would also work great, but then it's comparing pros and cons and there is little reason React can't win in such a comparison.

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

#23

Post by djmashko2 »

lioeters wrote: post #21
sAbakumoff wrote: post #15

I tried Relay but found it ridiculously stupid that I need to change the graphql API on my server in order to satisfy the relay concepts(universal id, connections) so we rejected the idea and decided to go with the good old fashioned redux

I appreciate your perspective, as I've been considering whether to invest time into learning GraphQL. It's informative to know that it's not suitable for some use cases. Probably could have done without the inflammatory adjectives.. ;) As far as the criticism, would you be kind enough to explain what you mean by "relay concepts", and how GraphQL failed to satisfy those needs?

I think the parent is saying something different: They were happy with GraphQL for their API, but weren't happy with the requirements the Relay client library imposed.

My interpretation is that they are now using a GraphQL API but fetching from it with regular HTTP fetches and managing data with Redux on the frontend.

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

#24

Post by mambodog »

ruslan_talpa wrote: post #18
mambodog wrote: post #13

Earlier quoted context omitted.

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).

Fair enough. What I'm trying to get at is that you need to pay attention to the cost of the real world queries which are actually being executed against your API, and then optimize. I'm not sure that SQL is a magic bullet there either (you can still request too much data at once, for example).

In practice this probably means adding some logging of how long requests take and graphing it (say, 95th percentile request time) from time to time to spot pathological queries. Even better if you can automate it. I think this is stuff that everyone should be doing (after a certain stage), regardless of whether you are using GraphQL or a bespoke JSON API.

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

#25

Post by TekMol »

mden wrote: post #22
TekMol wrote: post #20

Do you guys think it makes sense for a newspaper to use React for the frontend? I would think React might make sense for realtime dashboards and similar webapps. But does it make sense for displaying articles, navigation and ads?

Why not? Newspapers are fairly complex websites too and React is amazing at reducing code complexity, especially when compared to using vanilla js. There are other libraries that would also work great, but then it's comparing pros and cons and there is little reason React can't win in such a comparison.

    Why not?
My expectation is that the site does the templating on the client then. And my experience with websites that do that is that they load slow, behave sludgy and suffer from all kinds of display errors.

This might be a worthwile tradeoff to quickly build a highly interactive realtime interface. But for a newspaper? As a user I would be very much turned off to endure all that just to read an article.

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

#26

Post by linkmotif »

TekMol wrote: post #20

Do you guys think it makes sense for a newspaper to use React for the frontend? I would think React might make sense for realtime dashboards and similar webapps. But does it make sense for displaying articles, navigation and ads?

React (or similar library) makes sense whenever you want to have the ability to reason easily about state in your UI application. So if your UI accumulates any kind of user-introduced state, like text input, some kind of toggle, React provides a very pleasant mental model.

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

#27

Post by stephenboyd »

TekMol wrote: post #25
mden wrote: post #22

Earlier quoted context omitted.

Why not? Newspapers are fairly complex websites too and React is amazing at reducing code complexity, especially when compared to using vanilla js. There are other libraries that would also work great, but then it's comparing pros and cons and there is little reason React can't win in such a comparison.

Why not? My expectation is that the site does the templating on the client then. And my experience with websites that do that is that they load slow, behave sludgy and suffer from all kinds of display errors. This might be a worthwile tradeoff to quickly build a highly interactive realtime interface. But for a newspaper? As a user I would be very much turned off to endure all that just to read an article.

Endure it? Try visiting the NY Times. It doesn't load slow, behave sludgy, or suffer from display errors. And SPAs are a faster experience when you know the user is going to be looking at multiple pages, like how people typically read newspapers.

If the user is on any hardware from the past 7 years, a React developer would have to do some distinctly bad programming to make it behave sludgy. Any poor performance is likely to be from the same things that make a classic static page slow: large media files and tracking scripts.

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

#28

Post by jarym »

ruslan_talpa wrote: post #19
jarym wrote: post #14

Earlier quoted context omitted.

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

Yes, Postgres all the way. We don't use PostgREST though we construct the same type of queries.

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

#29

Post by davnicwil »

TekMol wrote: post #25
mden wrote: post #22

Earlier quoted context omitted.

Why not? Newspapers are fairly complex websites too and React is amazing at reducing code complexity, especially when compared to using vanilla js. There are other libraries that would also work great, but then it's comparing pros and cons and there is little reason React can't win in such a comparison.

Why not? My expectation is that the site does the templating on the client then. And my experience with websites that do that is that they load slow, behave sludgy and suffer from all kinds of display errors. This might be a worthwile tradeoff to quickly build a highly interactive realtime interface. But for a newspaper? As a user I would be very much turned off to endure all that just to read an article.

One of the really powerful features of React is that server rendering of the views is trivial. This makes it very compelling even for content sites, where as you rightly say, time to first meaningful render of said content really matters after you hit the URL in your browser.

You could even write an entirely server-rendered web application, or a static website, in React should you be so inclined. In fact, I do the latter for my (very simple) personal site at https://davnicwil.com!

Nothing about React obliges you to do client rendering, a SPA app, or anything complex at all. It's, at the end of the day, just a view rendering library.

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

#30

Post by s_kilk »

linkmotif wrote: post #26
TekMol wrote: post #20

Do you guys think it makes sense for a newspaper to use React for the frontend? I would think React might make sense for realtime dashboards and similar webapps. But does it make sense for displaying articles, navigation and ads?

React (or similar library) makes sense whenever you want to have the ability to reason easily about state in your UI application. So if your UI accumulates any kind of user-introduced state, like text input, some kind of toggle, React provides a very pleasant mental model.

But what the hell kind of state is involved in rendering a static page of text with a few images?
Post reply on HN