Content federation, and when a sync beats it
Partner
HyGraph's pitch is content federation: one GraphQL layer over its own models and over remote sources, so a page composes from several systems in one query instead of a fetch per source. That is a real pattern. The open question is whether composition happens at read time, or whether the data gets copied into one store first.
On shipped work our answer has usually been the second one. We sync Kyruus provider data into Prismic for CLS Health, and we land CrewAI's published Ghost posts in Contentful as drafts. We weigh HyGraph against Contentful, DatoCMS, and Sanity when copying is the wrong move. Monogram is a HyGraph partner.
Visit Partner Site
Federation
Where a federated graph earns its extra hop
- One graph over many sources, at read time
Federation resolves several sources behind one query at read time, which is genuinely different from copying them into one store first. Every CMS behind a live build on this site assumes a single store instead. So the question is not whether federation works. It is whether composition belongs at read time or at sync time.
- We usually resolve it before the request
For CLS Health we pulled provider data from the Kyruus Health API into Prismic using integration fields, syncing every thirty minutes. Editors then work in one system, and the page stops depending on somebody else's uptime. A federated query hands that dependency back, on every single request.
- A publishing pipeline can be the federation layer
CrewAI's writers stay in Ghost because it is the better writing tool. We built a pipeline that lands every published post in Contentful as a draft, so editorial keeps its tool and marketing keeps the gate on what ships. Querying Ghost live would have given up that gate.
- The extra hop is a cache you lose
Our standing position on GraphQL is that caching is harder than REST by design, because a query is usually a POST body that shared caches will not touch. Federating a remote source at read time puts an upstream dependency behind that same wall, where the CDN cannot cover for it.
- Federation will not fix a bad content model
We treat content modeling as engineering work, and the rule we hold to is model content types, not pages. A schema named after a URL breaks at the next layout no matter how many systems feed it. Federation widens the graph. It does not correct what is in it.
- Where we would actually reach for it
When the remote data is too large or too volatile to copy, and a thirty minute sync would be stale on arrival, federation stops being a convenience and starts being the design. That is the fight HyGraph wins over Contentful, DatoCMS, and Sanity. No HyGraph build has appeared in our published work yet.