Until recently, if an enterprise wanted a source of truth for content from multiple sources, they would have to create their own middleware between frontend code and various content sources.
Building this sort of system sounds simple — you query a few APIs, stitch them together, and deliver content via a unified API that the frontends access. Thus, all content flows through this mechanism.
In practice, it becomes challenging immediately. Getting the content is the easy part. Stitching and delivering is the really hard part. It takes knowing how your frontends are going to use the information and caching effectively so that the frontends get the content as quickly as possible.
One tool that has helped enterprises in this regard is GraphQL. GraphQL is a query language (that’s what “QL” stands for) developed by Facebook to help control the number of queries sent by any given page. GraphQL is built for simplifying the complex query needs of a single view in an application. Thus, it’s a great fit to solve many of these stitching problems.
However, GraphQL doesn't solve the challenges of stitching content together on its own. It requires additional orchestration to effectively serve as content middleware. You'd still have to manage the infrastructure of your GraphQL service, while handling the caching and coordination of the various content sources.