10 ms·
React, Relay and GraphQL: Under the Hood of the Times Website Redesign
- colemorrison 9y agoI'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 rework... Anyhow, maybe I just don't understand it enough.
- zrail 9y agoIf you're using Rails there's a very good gem with some great examples: https://github.com/rmosolgo/graphql-ruby https://github.com/rmosolgo/graphql-ruby Ryan supports development with a pro version that has a bunch of neat features, including built-in support for a handful of common authorization frameworks. I highly recommend it.
- tylerpachal 9y agoWe are using the Sangria[0] framework with a Play[1] app. Sangria does all of the GQL related stuff and Play dos the usual server stuff. Sangria's documentation is quite good, but the part that answers your question will be in the "Schema Definition"[2] section, which is where you describe the schema of your graph, and how each field is resolved. [0] http://sangria-graphql.org http://sangria-graphql.org [1] https://www.playframework.com https://www.playframework.com [2] http://sangria-graphql.org/learn/#schema-definition http://sangria-graphql.org/learn/#schema-definition
- ruslan_talpa 9y agoYou'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 careful. To be optimal, you'll basically need to write very complex resolvers that inspect the AST themselves and fetch the data optimally which at that point is almost as writing your custom execution module. That is basically what i did, custom execution module to translate a graphql request to a single sql query (https://subzero.cloud/ https://subzero.cloud/)
- scottmf 9y agoWhich n+1 problems doesn't dataloader solve?
- foota 9y agoYou don't have to worry so much about n+1 (once you're using dataloader) as much as you do deeply nested queries, or queries that run against a large number of datatypes.
- ruslan_talpa 9y agoi 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).
- foota 9y agoWe'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.
- andrewingram 9y agoThis 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.
- thomasfoster96 9y agoI 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 http://dev.apollodata.com/tools/graphql-tools/resolvers.html [1] http://dev.apollodata.com/core/ http://dev.apollodata.com/core/
- fishnchips 9y ago+1 to that. I'm working on a (mostly) GraphQL application with a Rails backend and a React frontend with a touch of Redux. I really wanted to like Relay but the documentation was lacking (I suspect that a major API change is to blame) and the amount of boilerplate is prohibitive. On the other hand Apollo Client is straightforward, framework agnostic with great React bindings. As a web development veteran I feel that I've never been as productive as with this particular stack.
- andrewingram 9y agoUsed 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 size + performance improvements are worth the cost of admission in my mind.
- thomasfoster96 9y agoHave 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?
- 9y ago
- zackify 9y agoI agree. All of the examples are trivial. There are a lot of nice things about graphql. Yet there are a lot of problems and annoyances other things don’t have such as query batching. Even authorizing certain graphql queries / mutations is not a trivial thing. I’ve been able to solve a couple of these things in my own app, but it’s just not something built into the spec.
- djmashko2 9y agoThis is definitely a real problem and we just launched a website yesterday which we hope will grow into a resource for this kind of more advanced content: http://www.graphql.com/guides/ http://www.graphql.com/guides/ You can also see a lot of examples of GraphQL server code for JS here: https://github.com/apollographql/launchpad https://github.com/apollographql/launchpad It includes connecting to DBs, APIs, etc.
- andrewingram 9y agoHere'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-request-waterfalls-7c3f3360b051 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.
- ruslan_talpa 9y agoassuming all your data comes form the same database, you can reduce one graphql query to one sql query that you can run on PostgreSQL (which is not a graph database). So batching is not the only option (and probably not the best)
- mrskitch 9y agoI've written a fair bit about it. We use it at AppNexus internally for our UI's, and it simply maps back to a REST API. Since each API has its quirks and oddities, it's a nice abstraction layer for consistency. http://joelgriffith.net/lessons-learned-wrapping-a-rest-api-with-graphql/ http://joelgriffith.net/lessons-learned-wrapping-a-rest-api-... For starters
- fiatjaf 9y agoAs 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 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.)
- pier25 9y ago> 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.
- pier25 9y agoOn 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.
- ohthehugemanate 9y agoWe're using graphql in front of a Drupal 8 data engine, with a variety of other data sources behind that. It's also for a publishing company, that has a bunch of different front end sites all served from the same content store... But with separate development groups. We're using the youshido graphql library for it... Though now that development is further along, I wish we'd chosen the webonyx one. A good GraphQL backend resolves the graph into query results efficiently, rather than just field by field. But that does take a but of getting used to....
- sAbakumoff 9y agoI 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
- lioeters 9y agoI 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?
- djmashko2 9y agoI 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.
- sAbakumoff 9y agoYes exactly, thanks for your help.
- lioeters 9y agoAha, thanks for the clarification. Upon reading the comment again, I see that it's Relay that didn't suit his use case, not GraphQL.
- sAbakumoff 9y agoWhat's wrong with inflammatory adjectives?
- lioeters 9y ago
- TekMol 9y agoDo 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?
- mden 9y agoWhy 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.
- TekMol 9y agoWhy 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.
- stephenboyd 9y agoEndure 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.
- TekMol 9y agoYou 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 problems go away.
- notadoc 9y agoPutting 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 RAM, and consuming CPU as if it were a midrange video game.
- bobwaycott 9y agoIf anywhere is the place to find others who miss the days of small HTML pages with CSS, especially for reading, HN is that place. :)
- scottmf 9y agoSeems like it's all you ever see here lately. I really should avoid reading HN comments on new web technologies.
- sidlls 9y agoI 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.
- chc 9y agoEverybody's job looks easy when you don't have the full list of requirements and a deadline in front of you. What looks like resume-padding may in fact be the best way to fulfill a requirement you didn't know they had.
- savanaly 9y ago
- publicopinionsa 9y agoWhy have you picked Relay over Apollo customer?
- dmitriid 9y agoA website that should heavily depend on caching relies on tech that allows only POST requests (non-cacheable, non-idempotent) and hopes for workarounds later
- djmashko2 9y agoGraphQL definitely allows GET and supports HTTP caching just as well as any other kind of API!
- dmitriid 9y agoGETs 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
- xiaoma 9y agoThe sad irony of all of this is that I regularly view the NYT without JavaScript because the experience is so much better without.
- pier25 9y agoIs anyone else here writing their GraphQL queries / REST calls in their components? IMO coupling the data layer with the presentation layer is a terrible idea.
- roucoulawan 9y agoThat'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 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.
- reconbot 9y agoThis 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.
- dbbk 9y agoI thought Bustle was big on Ember and Ember FastBoot, has that changed?
- reconbot 9y agoWe still use Ember and fastboot on a few applications but it's being replaced for the user side of bustle. I believe we did it because we were able to get faster and smaller server side renders and a smaller js payload. I spend more on the infrastructure side so I can't speak to the exact reasonings.