[sorenbs]

Correct, you are running at least two separate GraphQL APIs.

If you look at the architecture of modern tech companies they are already moving in this direction. Facebook has TAO for data access, and twitter has Strato: https://about.sourcegraph.com/graphql/graphql-at-twitter/ The purpose of these data services is to enable feature developers to focus on their feature instead of worrying about infrastructure, caching and scalability. Prisma is an open source version of that same pattern.

To the question of whether you should expose your database API to other internal services or not. This very much depends on the kind of architecture you are choosing. If you are building microservices you typically want to ensure that only the microservice owning the data can access and update it.

Facebook has a quite different approach where TAO enforces access control policies, and all services can query the same data. We'll explore how Prisma can support this pattern in the future.

[adamkl]

To further this point a bit, because of GraphQLs introspection capability, it becomes easy to combine and proxy existing GraphQL services without redeclaring the schema every time. If you take a look at what Prisma is doing, it’s creating a GraphQL schema based of an underlying data source which you can then generate bindings off of to include in other applications (think auto-generated client bindings via SOAP WSDL files.

At my company, we are taking a different approach by defining GraphQL APIs that are essentially exposing pure data (similar to Prisma) and then we are merging them and proxying them through multiple layers that augment and alter the schema and data as it passes through.

We can do this because we are leveraging The ability to inspect and alter the abstract syntax trees that power GraphQL under the hood.

[sorenbs]

This sounds like a super interesting approach Adamkl! Do you have something written up about this somewhere?

[adamkl]

I've had a few discussions about doing a formal write-up of what we are doing, but for now I can only provide a brief overview:

Our data APIs map from existing SOAP/XML services to small GraphQL sub-sections of our greater API.

Then, we merge those small APIs together with Apollo's graphql-tools, similar to what Airbnb is doing[1].

Now we are starting work on our proxy/processing layers using this[2] work-in-progress.

[1]https://medium.com/airbnb-engineering/reconciling-graphql-an...

[2]https://github.com/adamkl/graphql-proxy