Should we be using two GraphQL tiers? : <p>I work on a project that uses a single GraphQL schema to expose data from REST APIs to various clients.  The schema design is "owned" by the front-end teams, and is shaped to represent the universe as they see it.  This neatly decouples the UI from the API tier, and is working fairly well.
Some (poorly designed but essential) APIs are relatively complex, and require domain knowledge (aka business logic) to compose the data into a form that maps to the UI schema, but that business logic is changing, as legacy APIs are pulled apart and rewritten - the problem therefore is twofold:</p>

<ol>
<li>We have unwanted business logic in the resolvers that populate GraphQL query responses</li>
<li>When an API team produce a new version of their service, and wants it to be called, the UI team are not necessarily ready to update their resolvers to call it</li>
</ol>

<p>I am considering introducing a second GraphQL instance that acts as the domain model, which will be owned by the API teams, and abstracts the details of how to call each API, and compose raw data to be consumed by the UI schema.  It does introduce a small performance overhead, but on the plus side, decouples the Schema from the API implementation detail.</p>

<p>In researching this approach I have not found examples of this being attempted elsewhere so wondered if I'd missed any, or if this represents an anti-pattern that should be avoided?  </p>
