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

41–50 of 113 posts

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

#41

Post by scottmf »

bobwaycott wrote: post #38
notadoc wrote: post #36

Putting aside all of the technical fun, from a pure reader perspective of any website sometimes I miss just simple boring HTML with a bit of CSS to make it more pleasant and readable. I don't know about anyone else, but particularly from a consumption standpoint I miss the days of 100k webpages. I'm always stunned, but at the same time never surprised, when you discover a single webpage is 35+ MB, consuming 2GB of RA…

If anywhere is the place to find others who miss the days of small HTML pages with CSS, especially for reading, HN is that place. :)

Seems like it's all you ever see here lately. I really should avoid reading HN comments on new web technologies.

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

#42

Post by scottmf »

TekMol wrote: post #34
stephenboyd wrote: post #27

Earlier quoted context omitted.

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 li…

You mean www.nytimes.com ? Is that already the new react powered version? As a sidenode, it does feel sludgy: - Scroll is not smooth. - It does not adapt well to different browser sizes - After a few seconds the page "jumps down" But the reason might simply be the overkill of JS,animations, overlapping elements (like the static header), ads, dynamically loaded stuff and other crap. When I turn off JS, some of the pro…

They're not using React right now. If you read the article it says they'll be introducing the new version over the next several months.

A lot of this "JS is slow, what happened to good old HTML and CSS, get off my lawn" stuff is simply confirmation bias.

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

#43

Post by scottmf »

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

Take a look at Apollo.

https://github.com/apollographql/apollo-client

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

#45

Post by eyelidlessness »

TekMol wrote: post #35
jasim wrote: post #31

Earlier quoted context omitted.

Even if we don't use React on the client side, it can act as an excellent server-side view templating language. This is because React inverts the templating model on its head. A typical template is an HTML file (or some variation of it) within which the dynamic content is inserted using string interpolation. A React view on the other hand is a piece of Javascript code which can compose small snippets of view as JSX,…

But is this nytimes approach? How does a server side React app look like? Is it basically a node application then?

> But is this nytimes approach?

It pretty much has to be, there is no way NYT is giving up showing up in search results.

> How does a server side React app look like? Is it basically a node application then?

There is almost certainly Node somewhere in the pipeline. It's possible to build static content with Node/React as well, but NYT has dynamic server functionality as well so it would not surprise me if there's at least a Node layer in production.

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

#46

Post by pcurve »

notadoc wrote: post #36

Putting aside all of the technical fun, from a pure reader perspective of any website sometimes I miss just simple boring HTML with a bit of CSS to make it more pleasant and readable. I don't know about anyone else, but particularly from a consumption standpoint I miss the days of 100k webpages. I'm always stunned, but at the same time never surprised, when you discover a single webpage is 35+ MB, consuming 2GB of RA…

There is a lot of technology for technology sake to be found in American web sites.

My favorite counter example is sankei news site. http://www.sankei.com/

All their pages end in .html.

Do view source and vast majority if byte is used for actual text content, rather than javascript and markups.

Mobile friendly too, but you wouldn't know it because they disabled responsive view unless it's visited from an actual phone. No premature mobile view with hamburger kicking in when viewing it on desktop.

Comparison of View source between two sites is quite amusing.

view-source:http://www.sankei.com/smp/

view-source:https://mobile.nytimes.com/

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

#47

Post by andrewingram »

foota wrote: post #17
ruslan_talpa wrote: post #9

Earlier quoted context omitted.

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.

This is true, but most complex UIs tends to result in queries that spread wide rather than deep. It takes some deliberate contrivance or fairly unusual real-world cases to get to more than 3-4 levels of nested relationships, and this is often the point at which you'd be thinking to deferred/lazy loading in the client anyway.

I've spent a significant amount of time over the last year or so optimizing GraphQL servers built on domain-driven services (i.e. joins aren't an option) and managed to get to equal (or very marginally worse) performance to existing handcrafted endpoints that returned equivalent data (it was possible to build the same UI, even though the payloads weren't identical).

There are areas where GraphQL is inherently inefficient (trying to work on ways to mitigate these issues), but the reality is that deeply-nested UI appears to be less of a problem than I originally thought it would be.

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

#48

Post by hliyan »

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…

Sometimes I worry whether GraphQL is analogous to ORMs: a theoretically elegant attempt to solve an impedance mismatch between a data source and its consumer, but one that ultimately just shifts or redistributes the impedance to different layers of the codebase...

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

#49

Post by andrewingram »

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

I'd say build out your GraphQL server under the assumption that joins aren't always an option, but allow them as an optimization where possible.

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

#50

Post by andrewingram »

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…

Here's a high-level article about performance in general, but it shows how a UI and query could map to (for example) a function-driven API (this could be local to the server or remote):

https://dev-blog.apollodata.com/optimizing-your-graphql-requ...

Examples more specific to a particular backend technology feel redundant because my assumption is that once you're in the land of calling functions, we don't need to hold your hands anymore.

The most important thing is to be aware of the different batching strategies that are available to you in each GraphQL implementation because I believe this is the most critical part of getting a GraphQL server to perform well with anything other than a graph database.

Post reply on HN