A JavaScript Framework That Gives React a Larger Scope – InApps Technology

The long anticipated Relay JavaScript UI Framework for React came out recently. In case you haven’t heard of it, React is a JavaScript library released by Facebook as a new approach to creating user interfaces. While popular JavaScript frameworks such as Angular and Ember have taken a more “batteries included” approach to their design — including everything from HTTP libraries to UI routers — React was decidedly more minimal in its approach. Relay is a JavaScript framework for building data-driven React applications.

In the words of the official React site, it is “Just the UI” and “Lots of people use React as the V in MVC [model-view-controller].”

While the minimality of React was in many ways refreshing, it brought questions that were left unanswered, and many developers were left unsure exactly of how to architect a website using React.

Facebook’s Flux architecture served as one approach. However, while Flux provided some guidance in how to design a user interface using React, it didn’t answer all questions.

Much like React, Flux didn’t aspire to be a framework. It is a design pattern, instead of a formal framework. The Flux code released by Facebook contained a simple centralized dispatcher, and not much more. The user had the responsibility of the dispatcher to properly implement a Flux architecture. A large number of architectural questions without predefined best practices or patterns still existed.

However, with the release of Relay, React becomes a full-fledged framework that carries a much broader scope. React and Relay work together to provide a more out-of-the-box solution. Regardless of your background though — be it working with RESTful backends or Flux React apps — Relay has a lot of changes that require a degree of acclimation.

What about Flux?

Relay borrows some concepts from Flux, but also changes many things.

Relay has been described as both an “evolution” of Flux, and as a simplification of Flux.

One way it simplifies is in the area of stores. In Flux applications, instead of traditional MVC models, Flux has the somewhat related concept of data stores. For each React component there is often a corresponding store for that component. With Relay, there is instead one centralized store for all of your data, instead of each component having its own corresponding store.

Additionally, Flux triggers data changes through a construct called “actions” while Relay uses something called “mutations.” Mutations are a little more powerful than actions, in that they also manage data on the server.

This brings us to our next big point: Relay apps talk to a GraphQL endpoint instead of REST endpoints.

Making GraphQL a Requirement

Unlike many frontend frameworks, Relay is not backend agnostic; you are required to implement a GraphQL endpoint for your Relay application. While React can easily be dropped into any project and experimented with, this isn’t as much the case with Relay. Relay applications have three upfront requirements that must be met: A GraphQL schema, a GraphQL server and Relay itself.

GraphQL Schema

While we have discussed querying GraphQL in a previous post, there was not yet any specification about how to define the schema that query would run against. Since then, Facebook has provided a JavaScript reference implementation of GraphQL that we can use to define schemas. However, it is also possible to make a language of your own choosing. For example, a member of the community has provided an implementation of GraphQL in Ruby.

GraphQL Server

The next major component is a GraphQL server. This sever will be used to load up and interface with the GraphQL schema. Facebook has provided an Express.js reference implementation, but again, you are free to implement this using your preferred stack.

Relay

The last component is Relay itself. At a high level, Relay wraps existing components inside Relay components, and then uses the Relay version of these components instead. However, this isn’t 100 percent magic, and you must provide some additional code when creating your Relay wrapper. Specifically, you will be providing the GraphQL data queries necessary for this component. This follows the Relay design principal of colocation of queries with their corresponding views.

While some might say this violates proper separation of concerns, this isn’t necessarily the case. The data queries necessary for a given component or view are an integral part of it, and extracting it out is more of a separation of technologies than a separation of concerns. This is similar in spirit to how React does not believe the separation of views and controllers makes sense, and instead colocates them together in JSX files.

The other nice part about this colocation is it allows Relay to do a lot of query optimizing for us.

If multiple queries require the same piece of data, Relay will efficiently batch and aggregate these queries together for you. This has the potential for huge wins, compared to typical REST-style applications. For example, if you were pulling information for an endpoint in multiple locations on your site, you will often be sending a GET request for each place you need this data. You could instead attempt to aggregate these yourself, but this will make the application substantially more difficult to reason about. In comparison, the Relay approach allows us to have the simple conceptual model of declaring our data needs in each place we need it, but have the performance benefits of placing all the queries in one location. It’s a pretty big win-win.

Summary

Despite the radical changes proposed by React, it has so far been quite successful and is rapidly winning developer mind share. While MVC was long hailed as the one and only way to do things, React has successfully challenged that assumption. With GraphQL and Relay, Facebook is now questioning the current gold standard of having RESTful API backends. Maybe in the not too distant future, GraqhQL endpoints will be preferred over RESTful endpoints. It will be fascinating to see if the new ideas proposed by Relay will be just as successful as those brought to us by React.

Feature image: “IGFR complexed with allosteric inhibitor” by Enzymlogic is licensed under CC BY-SA 2.0.