4 ms·
To further this point a bit, because of GraphQLs introspection capability, it becomes easy to combine and proxy existing GraphQL services without redeclaring th
by adamkl 8y ago
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 8y agoThis sounds like a super interesting approach Adamkl! Do you have something written up about this somewhere?
- adamkl 8y agoI'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-and-thrift-at-airbnb-a97e8d290712 https://medium.com/airbnb-engineering/reconciling-graphql-an... [2]https://github.com/adamkl/graphql-proxy https://github.com/adamkl/graphql-proxy