GraphQL/Relay: The End of Redux? ... Perhaps.

GraphQL-Relay-Redux.md

GraphQL allows us to define a model of our data on the server using a graph schema, which is the most natural way of describing the stuctures and relationships in our data. To feed our model with data, we define resolvers that use the db's own query language (SQL, NoSQL, or Graph query language, etc) or in-memory objects to resolve queries from the UI against the graph data model we define.

With each components in the UI component tree declaring its own data dependencies, GraphQL/Relay creates a projection of the graph data model that maps to the UI component tree, thus allowing us to have an application-agnostic data layer on the server, while at once giving us and UI-specific projection of the data. The queries from GraphQL server to the database are composed in an efficient manner based on the aggregate data dependencies that are declared by each component in the UI component tree, thus eliminating redundant queries to the database.

GraphQL allows us to have a generic graph data model that can express all the relations between our data and that can be conceptually defined atop our db schema, and then visualized and comprehended without any knowledge of the internal SQL/NoSQL/Graph schema of our db, making it easier for front end folks and customers to work with, where our GraphQL Schema defined data model acts as an abstraction layer between the DBA realm (where writing GraphQL query resolvers and optimizing db structure happens) and the Application Developer realm, where the GraphQL Graph Schema and React/Relay components are constructed.

Relay also allows for mutation events from the UI to propagate to the GraphQL server which sync it to the db, while rendering the UI optimistically, and then merging to most current UI state. It can also update the UI when an external mutation (from another process/user) is recorded by the db.

Given how UI data dependencies are specified declaratively, the front end developer's job becomes a much more pleasant task consisting of simply building components and specifying their data dependencies and mutation resolvers. GraphQL and Relay take care of the rest. Also, Relay apps are regular React apps, so everything that can be done with a React app can be done with A React+Relay app, including access to the lifecycle methods and local state of components.

The Facebook Relay team is also planning on providing time travel facility (time based app state inspection) for React/Relay apps (potentially using the dev tools part of Redux) making solutions like Redux not only redundant but also very brittle in comparison as they hard code the app state data structure which if not done super carefully could mean a lot of rework as the UI evolves (although Redux recently introduced Reselect plugin that can provide user-defined projections on top of that hard coded structure, it can still lead to a mess of hand-wired projections in the code that have to be detangled and redefined when the data dependencies of a given UI component (or component tree) changes. With GraphQL/Relay everbody, be them web, mobile or 3rd party developers, works with a graph model of the data, and GraphQL does the rest, in combination with Relay (where Relay is currently available for React and very soon React Native apps) or other Relay-inspired solutions.

Finally, GraphiQL, the GraphQL IDE, provides a great way for exploring GraphQL schemas (the graph data models) and debugging client side queries.

In one fell swoop, GraphQL/Relay/GraphiQL eliminate a host of cost centers, conveniences and tools such as RESTful APIs, ORM/OGM, client/server caches, and client-side solutions like Flux/Redux that aren't deep enough.

Based on the fact that only a deep architecture like GraphQL/Relay could allow us to change the UI without manual/imperative rework of the data<->UI wiring, which cannot be done with by a client-side-only framework like Redux, I asked folks at Facebook if Redux is going to be made obsolete by GraphQL/Relay. Their reply seems more political than technical, and I can't really buy into it unless I buy into the idea that "Farmework XYZ" is always changing so it will never become obsolete. The truth is if Redux is to fit together with Relay it will need to be changed radically that it won't be the same thing.

![twitter exchange] (http://i.imgur.com/0aBjEGL.png)

###References

1. [Building a GraphQL Server with Node.js and SQL] (https://www.reindex.io/blog/building-a-graphql-server-with-node-js-and-sql/)

More coming soon... 2. ###Updated 1:

(after a Twitter chat with @en_JS (Joseph Savona), one of the GraphQL/Relay developers at Facebook)

Any app state that is not sync'd to the db is not something that Relay encompasses right now, but there is an ongoing [discussion] (facebook/relay#114) for handling things like form validation where the validation logic resides on the server and state updates from sources other than the db (e.g. websocket)

These important scenarios will be addressed according to the Relay Roadmap (https://github.com/facebook/relay/wiki/Roadmap):

1. API for resolving fields locally: #431.

2. Support querying & compiling client-only fields by extending the server schema, and a means for writing data for these fields into the cache: #114.

###Update 2:

@gaearon (Dan Abramov), author of Redux, was gracious enough to tweet this, and I give him a lot of credit for doing so.

Here is a section of the very long conversation that Dan started:

![twitter conversation] (http://i.imgur.com/BD2Wu5m.png)

###Update 3:

My follow up conversation with Dan below

![twitter follow up] (http://i.imgur.com/43lsGJo.png)