GraphQL in Gloo Platform 2.2
As mentioned in our Gloo Platform 2.2 release blog, the 2.2 release included some major additions on the GraphQL front around data sources, performance, security, and developer productivity. Let’s take a deeper look at the features we’ve added in each of these areas.
New Resolvers: gRPC and Mock
While REST APIs still represent the largest number of existing APIs in the API landscape, gRPC is the go-to choice for many teams for inter-service communication in Kubernetes. The new gRPC resolver for Gloo GraphQL provides the ability to use one or more existing gRPC APIs as the data source for your GraphQL APIs.
We have also added a new Mock Resolver that provides the ability to return static data from a resolver definition without the need for an upstream data source. This feature is particularly useful in the early stages of proving out a GraphQL schema design, as it allows clients to interact with a full schema with example data. Once the schema design has been validated by clients, simply replace the mock data with real data using a gRPC or REST resolver.
GraphQL presents some unique challenges when it comes to caching compared to REST APIs. For example, GraphQL operations are most commonly invoked over HTTP POST, which is not compatible with traditional caching approaches based on HTTP GET. Even when using HTTP GET, GraphQL operations must be passed as query parameters, which can run into character limits among other issues. Fortunately, the GraphQL community has come up with a novel way to deal with this problem using query hashing.
Query hashing involves computing a hash for a given GraphQL query and then passing that hash instead of the full GraphQL query string on subsequent invocations. This has some immediate performance benefits for large GraphQL query bodies, as clients only pass the query hash. Since we can safely pass the query hash using a query parameter with HTTP GET, it also means we can unlock traditional HTTP caching approaches like Edge CDN caching. Better still, you can enable this for any GraphQL API in Gloo Platform using declarative policy:
apiVersion: resilience.policy.gloo.solo.io/v2 kind: GraphQLPersistedQueryCachePolicy metadata: name: bookinfo-query-cache namespace: bookinfo spec: applyToRoutes: - route: labels: route: graphql-bookinfo config: cacheSize: 1000
In some cases, it may be desirable to limit operations against your schema to a predetermined set of queries, preventing intentional or unintentional abuse of your GraphQL APIs. Query hashing is a great fit for this use case — simply include an allow list of query hashes in your caching policy, and you have locked down your GraphQL API to just those operations!
apiVersion: resilience.policy.gloo.solo.io/v2 kind: GraphQLPersistedQueryCachePolicy … config: allowedQueryHashes: - 4b5aa540520d96aa073dbb8ded86bdb405429d08c5d942f8a24ca1a3d5b3ecf6
The Gloo Platform UI now includes an integrated GraphQL Explorer page for each GraphQL API. Based on the popular GraphiQL package and fully integrated with the Gloo Platform UI, Explorer allows you to browse schema definitions, generate GraphQL queries, and execute GraphQL operations. You can access Explorer by clicking on the “Explore API” button on the details page for any GraphQL API.
Schema stitching: Now available in 2.3 Beta
As we look forward to the Gloo Platform 2.3 release, we’re excited to announce that support for schema stitching is now available in Gloo Platform 2.3.0-beta1. Schema stitching is an alternative approach to Apollo Federation for creating a single, unified GraphQL API from multiple subgraphs. We’ll have an in-depth look at this feature in our Gloo Platform 2.3 release blog. For now, you can find detailed information and examples in the latest GraphQL documentation.