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

71–80 of 113 posts

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

#71

Post by sAbakumoff »

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?

What's wrong with inflammatory adjectives?

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

#72

Post by linkmotif »

s_kilk wrote: post #30
linkmotif wrote: post #26

Earlier quoted context omitted.

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?

My experience has been that this kind of thing is very rare.

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

#73

Post by pcurve »

eropple wrote: post #70
pcurve wrote: post #46

Earlier quoted context omitted.

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…

> 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 Bug, not feature. If I'm viewing a site in a narrow window, I expect it to collapse responsively. That site doesn't.

I can assure you it's not a bug. Many Asian sites have fixed width on desktop. They do not make their sites with 4-5 different media query break points.

Personally I prefer this because information is always in the same place regardless of browser size. I don't have to worry about it moving around or hiding.

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

#74

Post by eropple »

pcurve wrote: post #73
eropple wrote: post #70

Earlier quoted context omitted.

> 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 Bug, not feature. If I'm viewing a site in a narrow window, I expect it to collapse responsively. That site doesn't.

I can assure you it's not a bug. Many Asian sites have fixed width on desktop. They do not make their sites with 4-5 different media query break points. Personally I prefer this because information is always in the same place regardless of browser size. I don't have to worry about it moving around or hiding.

Fine--misfeature. Bug in the spec. Having to squint and scroll sideways and zoom is awful user-facing behavior.

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

#75

Post by underwater »

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. There were so many little one-off pieces of functionality and randomly integrated services. Tools like React and Relay make it much easier to manage this complexity and promote code reuse.

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

#76

Post by fiatjaf »

eropple wrote: post #70
pcurve wrote: post #46

Earlier quoted context omitted.

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…

> 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 Bug, not feature. If I'm viewing a site in a narrow window, I expect it to collapse responsively. That site doesn't.

GitHub is bugged, by your criteria.

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

#77

Post by djmashko2 »

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!

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

#78

Post by fiatjaf »

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…

As a standalone all-by-myself indie developer I was skeptical of GraphQL when it first appeared, but later I discovered it is much easier to develop APIs for my own consumption with GraphQL. The basic GraphQL boilerplate seems bad, but is actually fun to write and makes total sense. And once you have the structure in place it is super easy to add functionality.

Plus bonuses if you have more than one database or are mixing data from your database and external APIs in your backend responses.

Please try it for a small project, it is unbelievable, but you'll probably enjoy it.

(For the record: I've just used https://github.com/graphql-go/graphql and Lokka on the client, because it is simple and does nothing fancy, it's a thin wrapper over XHR, I think.)

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

#79

Post by andrewingram »

ruslan_talpa wrote: post #57
andrewingram wrote: post #54

Earlier quoted context omitted.

I mean to structure your server in such a way where you're not trying to automatically convert your entire query AST into a single massively complicated SQL query. It's true that in simple cases, one complex query can be the fastest way to get the data you need, but you leave this territory pretty quickly. It's perfectly valid to identify subtrees of your query that would benefit from being executed as a database que…

I kind of understand why you'd think it's a massively complicated query. You are probably thinking the types of joins on two tables on random columns with weird conditions which go into full table scan. I am talking about queries/joins between tables that have foreign keys between them, like client/project/task/comment. I bet 90% of graphql schemas expose those kinds of relations between types. For those type of rela…

I use a programming language that is 1-2 orders of magnitude slower than C, should I switch today?

I get my data for a full UI within the budget i've allowed for uncached scenarios (100ms, but I want to go to 50ms). The approach you're suggesting will (in some circumstances) give me some short-terms win in terms of throughput and response times, but you've not said anything to suggest that I won't lose these benefits as I gradually transition into a domain-driven or micro-services (yuck) architecture.

I like to build my GraphQL servers under the assumption of a domain-driven architecture (because that's where all the projects I've worked on seem to end up, your mileage may vary), and then shoe-horn in some short-term performance tricks when I can.

I'm possibly a special snowflake here, but it's been a long time since i've had the opportunity to work on a project where I can go straight to the DB. Be it Elastic Search, a 3rd party, ill-advised micro-services, or complex logic in-between storage and presentation; nothing has quite been a pure DB project in the last 6-7 years.

Of course, you could argue this is premature architecture ;) but many of these complexities are from day one, or at least pretty early in a project's life.

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

#80

Post by savanaly »

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

After reading my ceremonial 1000th testimony about how HN user prefers sites with less CSS I'm about done with it though. We get it! Engineers are proud of how little they care for white space and colors! Can we talk about something else in the top comments of any page about website design?
Post reply on HN