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

101–110 of 113 posts

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

#101

Post by est »

underwater wrote: post #75
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…

Whether JavaScript is a good fit for a news site and whether news sites should be single page apps are two separate questions. It's possible to build a server rendered React app without requiring any client JavaScript execution at all. News sites are also more complex than you would assume. I went from building products at Facebook to a large news site. What shocked me was the surface area of the user facing products…

> It's possible to build a server rendered React app

What's the advantage of server rendered React app over server rendered anything e.g. php jsp etc?

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

#102

Post by dmitriid »

djmashko2 wrote: post #77
dmitriid wrote: post #44

A website that should heavily depend on caching relies on tech that allows only POST requests (non-cacheable, non-idempotent) and hopes for workarounds later

GraphQL definitely allows GET and supports HTTP caching just as well as any other kind of API!

GETs for GraphQL are awkward at best

The caching section in GraphQL docs is cringe worthy, and, as evidenced by the article, that's exactly what Times are going to do: try to slap global ids everywhere and pretend it's ok

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

#103

Post by andrewingram »

thomasfoster96 wrote: post #81
andrewingram wrote: post #51

Earlier quoted context omitted.

Used Relay Classic for a year and a half, been using Relay Modern for a month or so. You are absolutely right, the documentation situation is terrible. The fact that the new mutation API has practically zero documentation is troubling. I've been sticking with it though, and I am enjoying it. I feel like I have a greater grasp of what's going to be executed and when than I ever did with Relay Classic, and the file siz…

Have you been using normal Relay or one of the forks/modified versions that supports server-side rendering? The fact that Apollo Client supports server-side rendering out of the box was a big plus for me. > the file size + performance improvements are worth the cost of admission in my mind. Is this Relay Classic vs Relay Modern or Relay vs Apollo?

The libraries that support server-side rendering aren't forks, they sit alongside Relay. But yes i've been using them for well over a year without any issues. I haven't tried it with Relay Modern yet, but there are examples out there of how to do it.

Relay Modern is 20% of the size (or 5 times smaller) than Relay Classic, which (if my calculations are correct, I don't have equivalent environments set up) is just over half the size of React Apollo + Apollo Client.

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

#104

Post by underwater »

est wrote: post #101
underwater wrote: post #75

Earlier quoted context omitted.

Whether JavaScript is a good fit for a news site and whether news sites should be single page apps are two separate questions. It's possible to build a server rendered React app without requiring any client JavaScript execution at all. News sites are also more complex than you would assume. I went from building products at Facebook to a large news site. What shocked me was the surface area of the user facing products…

> It's possible to build a server rendered React app What's the advantage of server rendered React app over server rendered anything e.g. php jsp etc?

You can make use of the JavaScript ecosystem. React is a nice was to structure code. There are a tonne of modules available on npm, etc. If and when you do want to build client elements you can reuse parts of your code.

That said, I'm not aware of anyone doing this at scale. I know the BBC were considering it. My company will be using it to product AMP pages from our JS stack.

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

#105

Post by jorblumesea »

stephenboyd wrote: post #100
jorblumesea wrote: post #32

Earlier quoted context omitted.

React is a view library and it does this very well. It doesn't have all the bells and whistles like Angular and it's plethora of helpers ($HTTP etc) or complex dependency injection. I would argue it's the perfect candidate for this purpose. What does a news site need? Articles? Ads? Basic nav? Angular or Ember would be overkill. And with Redux, it's very easy to think about complex UI state. My only complaint with Re…

You might like Preact: https://github.com/developit/preact It's a 3kb React alternative with the same API.

Interesting, thank you

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

#106

Post by roucoulawan »

That's cool to have here a synthetic explanation on how Relay can be more familiar.

I think I would just still be more attracted by Appollo framework which is more a redux-like syntax, so more consistent with all the workflow of the apps I used to develop. But maybe Relay has better benchmarks?

Also, if I want to stay REST but with optimist transactions between the backend and frontend, I prefer lighter lib like https://github.com/tonyhb/tectonic or even I just write some fast redux-saga watchers that helps to make my frontend always synchronized when my app calls a mutating db request.

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

#107

Post by reconbot »

This is very similar to the stack we use at BDG Media (bustle.com, romper.com, etc) We use Amazon Lambda, GraphQL, a custom model layer with data loader and redis, and preact. We haven't seen a clear benefit from Relay or Apollo with out front end apps (tbd on our admin apps) but we have enjoyed the Relay spec to help set server side conventions.

GraphQL has helped us make an api that is easy to understand, easy to change and and easy to use. We love it.

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

#108

Post by dbbk »

reconbot wrote: post #107

This is very similar to the stack we use at BDG Media (bustle.com, romper.com, etc) We use Amazon Lambda, GraphQL, a custom model layer with data loader and redis, and preact. We haven't seen a clear benefit from Relay or Apollo with out front end apps (tbd on our admin apps) but we have enjoyed the Relay spec to help set server side conventions. GraphQL has helped us make an api that is easy to understand, easy to c…

I thought Bustle was big on Ember and Ember FastBoot, has that changed?

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

#109

Post by dbbk »

daliwali wrote: post #39
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,…

The string building approach is the fastest, and it's the benchmark to beat. Any other abstraction is just piling more work on top and is generally just a more inefficient way to output HTML. The most lightweight pseudo-DOM implementations are still going to be significantly slower than string concatenation, and I have benchmarks to back up that claim [0]. Realistically, a server-side rendered JS app is also going to…

I'd imagine at the Times' scale they're not server-side rendering every page view though. I'm sure they'd be caching the HTML result at the CDN level.

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

#110

Post by ruslan_talpa »

dustinmr wrote: post #66
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…

Here's a project that might be interesting. https://github.com/postgraphql/postgraphql

Technique inspired by PostgREST and graphql spin "stolen" (in a good way) from subZero :), although a completely different implementation method then subZero
Post reply on HN