Live data from Hacker News

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

open.nytimes.com

81–90 of 113 posts

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

#81

Earlier quoted context omitted.

I strongly suggest that you look at Apollo's GraphQL offerings. My 'aha' moment with GraphQL came while reading the docs for their GraphQL server[0]. IMHO Relay doesn't make a lot of sense. Apollo Client [1] has a much better feature set for most use cases, doesn't need React and is better documented. [0] http://dev.apollodata.com/tools/graphql-tools/resolvers.html [1] http://dev.apollodata.com/core/

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?

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

#82
post #76
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.

GitHub is bugged, by your criteria.

Yup! GitHub's wrong too. We have media queries for a reason--because user agent sniffing and "mobile sites" leads to incorrect results. This is one.

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

#83
post #46
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…

> All their pages end in .html.

Do you not understand how URL rewriting works?

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

#84

Earlier quoted context omitted.

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.

Aha, thanks for the clarification. Upon reading the comment again, I see that it's Relay that didn't suit his use case, not GraphQL.

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

#85

Earlier quoted context omitted.

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?

Well, I just imagined that the devs of the library may be come across your comment and be offended/saddened to hear it being called "ridiculous" and "stupid". But then again, it sounds like you have good reasons to be frustrated with it, so why not. I recently saw someone write, "Webpack is ridiculous" - I suppose there's nothing wrong with inflammatory adjectives if it's backed up by evidence/experience.

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

#87
post #30

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?

Initial page load might be marginally slower, although it's not hard to thrown down the bare minimum and lazy load the rest, but every subsequent page load will be faster and much less intrusive.

I'd say react is a perfect fit for this type of thing. A basic news site it might be, but there's a lot more going on under the hood than you'd imagine.

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

#88
post #78

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

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

You can easily do that with a RESTful API too.

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

#89
post #41

Earlier quoted context omitted.

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.

I wish there were some way to avoid being subject to resume driven development when I'm on the internet. Alas, it's not to be, because instead of taking a step back and asking "do we need this" we get webdevs asking "how can I force fit the latest shiny bauble into my professional CV." And we end up with react graphQL node AWS kubernetes docker rube goldberg machines pumping tens of millions of bytes of data and billions of bytes of markup and JavaScript through Kafka all to serve up news text.

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

#90

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…

On the server side it's very similar to REST. You define your types in a schema file, and then write functions that go fetch the data for each type. These functions are called resolvers.

For example you have a Product type, and then write the resolver function that queries the database and/or another API. When you have the data, you pass it back to the client via Apollo or Relay.

The big advantage over REST is that the client can define what data it wants and how it wants it. If you are full stack dev this isn't such a great advantage, but for bigger projects where front/back are spread among many engineers this can be an advantage. Also, since the schema defines the types, your API is almost self documented so to speak.

The big disadvantage is authentication and authorization. We kept using REST for authentication, and we couldn't find any ready made solution for role based authorization like you have in Express, Hapi, etc.

I think a combination of REST and GraphQL is the better approach.

Post reply on HN