Production Setup

Getting the most out of Relay in production requires a few extra steps. This page covers a list of best practices for taking Relay to production.

Persisted Queries (Trusted Documents)

One of GraphQL's key innovations is that it enables clients to define arbitrary queries. While this unlocks a lot of flexibility, it also opens the doors to abuse. Scrapers can use GraphQL to scrape data from your site, and malicious users can use GraphQL to send large requests to your server that cause a denial of service. To prevent this, we recommend using Persisted Queries also know as Trusted Documents.

With Persisted Queries, the set of queries that the client can send is locked in at build time. This means that scrapers and malicious attackers are limited to sending only the queries used by the client, just like REST. It also has the added benefit that the client code only needs to include an single id for each query rather than the whole query text.

Relay Lint Rules

A key principal of Relay is data colocation where each component defines its own data dependencies. It's critical to How Relay Enables Optimal Data Fetching. However, this is often unintuitive for developers who are used to fetching data in a single query. Relay's ESLint rules can help enforce this pattern by ensuring no component fetches fields which it does not itself use.

We recommend using the eslint-plugin-relay, especially the relay/unused-fields rule.

Running the Relay Compiler in CI

We recommend committing Relay's generated artifacts to source control along with your application code. This ensures generated types are present without needing an additional build, and allows for inspection of generated artifacts in code review. To ensure the generated artifacts are always in sync with the source code, we recommend running the Relay compiler in CI and ensuring it does not change any generated files. A example bash script which checks for changes can be found here.