GraphQL is becoming a standard for north-south (server-client) data exchange schemas. It’s not a buzzword anymore. I suppose the popularity of GraphQL is due mostly to its two key features: very flexible schema and query modeling and … the server-side resource aggregation.
Data modelling and querying offers the user a BFF (Backend for Frontends) pattern straight out of the box. Any type of client can query for different sets of properties, or elements of the data-graph, without knowing all the details of how these nodes are being fetched.
The queries are processed by resolvers that encapsulate all the data processing details. Moreover, the resolvers can be written in virtually any programming language of choice – probably with the leading TypeScript representation, mostly due to the Apollo GraphQL Toolset including all the Enterprise GraphQL Management tools.
One of the added values on how the GraphQL queries are being processed is the easiness of aggregating all kinds of federated resources into a single GraphQL Schema.
In the recent Technology Radar report, this technique has been selected in the TRIAL category, which means it can be successfully used at scale, on production.
The most popular way of implementing the schema aggregation is probably the Apollo Federation. Using this library, you can very easily define a gateway just by providing it with the sub-schema’s URLs:
Note that this is a great way to decouple and federate the business logic processing vertically, per domain to different services, while still maintaining the aggregated facade schema that makes the overall data repository much easier to use for the end user and lets you query multiple data sources within a single HTTP request.
Server-side resrouce aggregation with REST services
If you’d like to aggregate the REST services, you can just implement the business logic over the set of different query resolvers. We used this approach implementing our open-source storefront-api eCommerce data gateway and for implementing the Salesforce Commerce Cloud integration PoC for Vue Storefront.
Many people use Mulesoft for the same purpose. It is great but is probably not required for simpler and leaner use cases where the Apollo Federation or just custom data resolvers are more than enough.
In the example above—taken from the Salesforce Commerce Cloud GraphQL bridge we prepared for the purpose of the Vue Storefront Salesforce CC integration—you can see how easily we can aggregate federated schemas into a single GraphQL repository. In this case, we’re using NodeJS API Client to call the SFCC OCAPI, REST services and then just render them out into a defined GraphQL Schema.
The client which is querying our GraphQL doesn’t need to know exactly how and from where the data is fetched. Encapsulation is one of the top GraphQL Resolvers values because, with this hidden complexity, users can build very complex data structures including inter-data source relationships. The data being aggregated on the server side can be cached via a CDN (Content Delivery Network) to save the HTTP round trips which are required when using a simple REST data fetching schema.
Published October 13, 2020
