GraphQL allows us to define our data model on the server using a graph schema which is the most natural way of describing
the relationships within our data.  To feed our model with data we define "resolvers" that tell GraphQL how to populate our
graph model with the various data from our db. The resolvers use the db's own query language (SQL, NoSQL, or Graph query
language, etc) to resolve queries against the graph model we define.

With each components in the UI component tree declaring its own data dependencies, GraphQL/Relay automatically creates a
projection of the graph data model we define on the server that maps to the UI component tree,
thus allowing us to have an application-agnostic data model on the server that reflects the natural relationships in the data and that
alone, as opposed to how the data is structurally related in the UI, 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, mutation resolvers, and routes (which may
be recursively mapped to components, thus allowing complex navigable UI state transitions). GraphQL Server and Relay take
care of the rest.

The Facebook Relay team is also working on providing time travel facility (time based app state inspection) for React/Relay
apps, 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, and prevents the front-end developer of taking advantage of
the "one data model everywhere" principle. With GraphQL/Relay everbody, be them web, mobile or 3rd party developers, works
with the same generic 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 custom solutions.

In one fell swoop, GraphQL/Relay eliminates a host of cost centers such as RESTful APIs, ORM/OGM, client/server caches, and
brittle client-side architectural patterns like Flux/Redux.