What news from AWS re:Invent last week will have the most impact on you?
Amazon Q, an AI chatbot for explaining how AWS works.
Super-fast S3 Express storage.
New Graviton 4 processor instances.
Emily Freeman leaving AWS.
I don't use AWS, so none of this will affect me.
Software Development

React with GraphQL for Architecting Apps

May 18th, 2015 9:58am by
Featued image for: React with GraphQL for Architecting Apps
Feature image by StartBlogging Onlinevia Flickr Creative Commons.

As we’ve seen with React, Facebook is not afraid to experiment with revolutionary ways to architect apps, and question many long accepted best practices of web development. For example, Facebook’s React eschewed templates and opted to instead both manipulate and present data in Javascript. Given that React works so fundamentally differently than usual client side code, traditional means of fetching data didn’t allow React to shine at it’s very best.

The first approach Facebook published was the Flux pattern. There have been various framework implementations of the Flux pattern, and many React applications opt to use the Flux pattern. However, not everyone opted to use Flux for their React applications; it turned out that even Facebook themselves were developing alternative ways to architect their React applications. Enter Relay and GraphQL.

The central idea behind Relay and GraphQL is that view code is the best place to locate data-fetching code. To do this, each React component will specify its needed data using GraphQL queries; Relay will then fetch the data specified by GraphQL. You might be wondering what the value added of Relay is, and why doesn’t GraphQL hit the server itself for the data, instead of just specifying data needs. The reason is each GraphQL query does not map to Relay doing one server request, as doing this would carry major performance penalties; this would be inefficient because you will often specify the same data dependency in multiple places.

Instead, Relay will take all the different queries sent to it and batch them together. This means if you had multiple React components specifying via GraphQL the same data dependency, they will both get their data from the same server request via Relay. To me, this feels similar to how React components state all of their rendering needs to the virtual DOM, which then diffs itself with the actual DOM before doing any manipulations. Both the virtual DOM and Relay allow React developers to explicitly state the needs of their components, without having to try and be minimal for performance reasons.

GraphQL Queries

Let’s talk a little bit more about this idea of only grabbing a subset of a model’s data. It is very common for a React component to correspond to a particular model on our backend. However, it is likely that there isn’t a one-component-to-one-model relationship. What’s more likely is an app will have various view components, each of which consists of parts of a particular model. Because of this, it doesn’t make sense for each view to grab every attribute of a model; with GraphQL, the React component can specify the precise attributes it needs, and that’s all it will get in return.

A user record in a database can contain many fields related to that user. Let’s say we are making a box on our site that displays a user’s name, age and state. In our database we have several other fields of information about a user, perhaps non-pertinent data, such as the user’s preferences for email notifications, or private data such as the user’s phone number.

Here’s what the GraphQL would look like, for getting only the data we care about:

Which would give us:

The way this works is fairly intuitive. Outside of where we are specify the user ID, we have essentially written some JSON: we specified the keys but left the values missing. GraphQL responds by filling in those JSON values by using the passed in ID, and responds with a fully JSON-compliant response. GraphQL is also hierarchal in nature, allowing you to further nest the parameters of your request.

In the context of our above query, let’s say we also wanted to return the user’s avatar, and make it have a size of 100:

Which would give us:

The Path Ahead

While GraphQL will have great first level support for Relay upon its official release, GraphQL will also work well as a stand-alone piece of technology. I think there will be many exciting applications of GraphQL in the near future, both inside and outside of Relay. While substantially different from how most developers are used to fetching data for their applications, the reasoning behind the changes is solid, and the technology is being vetted in production by Facebook. Keep an eye out for future news, as Facebook releases more technical details on GraphQL.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.