I found the Relay documentation to be opaque, incomplete, and downright confusing at times. The docs were often missing the why behind certain decisions; instead, you had to follow along and figure it out yourself. Apollo’s documentation isn’t perfect, but it is much more thorough and beginner-friendly. [ed: i would agree based on brief perusal]
For a more in-depth look, read why Gatsby uses GraphQL.
Eliminate frontend data boilerplate — no need to worry about requesting & waiting for data. Just ask for the data you need with a GraphQL query and it’ll show up when you need it
Push frontend complexity into queries — many data transformations can be done at build-time within your GraphQL queries
It’s the perfect data querying language for the often complex/nested data dependencies of modern applications
Improve performance by removing data bloat — GraphQL enables you to select only the data you need, not whatever an API returns
How should we get (meta)data / content? What is the "data layer" for this system?
The content fetching divides into two parts:
Tasks
Analysis (in progress)
Next.js data fetching can be done in two ways:
We want to use the
getServersideProps
method for our use case. There's a repo with helpful examples to see how data fetching works in Next. https://github.com/vercel/next.js/blob/canary/examplesWhat we want ...
fetch could use graphql, raw queries it doesn't matter ...
gatsby ...
Inbox (misc)
Inbox on Graphql approach
Summary
https://gist.github.com/nikolasburk/36cae3e7f79074a34c4d64f1428c96ac - https://www.prisma.io/blog/relay-vs-apollo-comparing-graphql-clients-for-react-apps-b40af58c1534- 3y old and old version of relayExcellent critique of next.js SSR approach: https://en.paqmind.com/blog/ssr-is-not-the-future and recommendations on how to approach (jan 20 2020)
This section of gatsby doc is useful https://www.gatsbyjs.org/docs/graphql-concepts/#why-is-graphql-so-cool
For a more in-depth look, read why Gatsby uses GraphQL.