This blog will explore common patterns, benefits and limitations of standalone GraphQL, how to combine GraphQL with Envoy Proxy, and how Gloo Gateway puts platform and application development teams on a path to success with GraphQL.
GraphQL is a significant advancement in the API landscape that puts API clients in control of the data they consume. This is revolutionizing front end development by simplifying and optimizing data access and observability for API clients. While this is new and exciting, it’s important to recognize the GraphQL APIs are still APIs, with all the responsibilities and considerations associated with providing access to your organization’s data.
Patterns and benefits of GraphQL
The benefits of GraphQL have led to explosive growth over the last several years, establishing it as a leading choice for new APIs in organizations.
While there is no prescribed approach to how GraphQL is adopted, it’s very common to see organizations take an incremental approach to introducing GraphQL alongside their existing APIs. Some common patterns include:
- A simple monolith fronting a single existing REST or gRPC API with a GraphQL endpoint
- A composed monolith with multiple existing REST and gRPC APIs into a single GraphQL API endpoint (e.g. BFF – backend for frontend)
- Federated GraphQL schemas into a single unified graph using a technology like schema stitching
- A hybrid graph that can scale to hundreds or thousands of subgraphs across organizational, cluster, and cloud boundaries.
No matter where you start, it’s important to consider how the technology you adopt for GraphQL scales to cover these use cases.
GraphQL provides many benefits for the Application Interface including:
- Client-specific data views – APIs clients are in complete control of the data they consume, allowing a single GraphQL API to service multiple types and versions of clients simultaneously.
- Simplicity – GraphQL provides a single entry point to an entire graph. There’s no need to keep track of all the API endpoints your front end needs to grab data from; all data is accessible via a single endpoint.
- Efficiency – GraphQL APIs return exactly what we need for requests and nothing more. REST APIs are designed with the backend in mind and return all resource data clients, whether they need it or not. This is known as overfetching and can have significant performance implications for bandwidth and resource-limited clients. Even if the client is not resource-constrained, parsing through a ton of data you don’t need adds unnecessary complexity to API interactions.
- Completeness – Dealing with multiple backend APIs means you may need to query one API to get a list of resources and then make multiple round trips to other APIs to get dependent resources. Otherwise you’ll be underfetching and not getting everything you need. GraphQL allows you to get all the data you need in a single request.
- Client compatibility with schema evolution – Some API clients struggle when an API schema changes to include additional fields they weren’t designed to process. GraphQL API clients always request the data they need and will by design skip new fields that they can’t handle.
These capabilities have driven many companies to adopt GraphQL for their APIs, such as Intuit, KLM, Lyft, New Relic, PayPal, Facebook, Pinterest, Twitter, GitHub, AirBnB, Audi, Yelp, and Starbucks.
Operational requirements for GraphQL
While these benefits are amazing, they still must be combined with Application Network policies to provide a safe and resilient API surface area. GraphQL doesn’t provide this functionality out-of-the-box, but it’s essential to address these needs too:
- Authentication and authorization – GraphQL APIs provide access to business-critical data and must be secured appropriately. Given that GraphQL APIs generally compose multiple backend APIs together, they can become a dangerous attack vector without authentication and authorization of API clients. There have been multiple news stories about attackers gaining escalated data access through improperly secured GraphQL APIs.
- Rate limiting – Rate limiting is even more important for GraphQL as all clients are hitting a single endpoint and the ‘cost’ of a given operation can vary widely. This requires extensions to traditional rate limiting to perform cost analysis of a given GraphQL request against a specified limit/budget.
- Observability – traditional API metrics including success, failure and latency need to be augmented with field-level usage information to make informed decisions on how schemas can evolve (e.g. removing fields from a schema that aren’t used). Tracing is important to understand where time is spent in each request: query execution, resolvers for upstream data, etc.
- Web application firewall (WAF) – GraphQL operations can be used to implement DOS attacks (e.g. unbounded query depth) unless GraphQL-specific application firewall policies are in place along with the traditional WAF protections.
- Data loss prevention (DLP) – GraphQL APIs can return sensitive data, just like every other type of API. Leveraging DLP to protect sensitive data from escaping trust boundaries is a critical component of your overall data security posture.
Running GraphQL and Envoy Proxy separately
A common approach we see with customers doing GraphQL today is they pick up a GraphQL framework and write some code to resolve multiple upstream data sources into a GraphQL API. They integrate with a number of libraries in the process and produce an application deployment that is then managed by the platform team. The platform team owns the operational responsibility for the health and availability of this deployment, but the story doesn’t end there. The GraphQL Server is an API and needs to be protected, so the platform team fronts the GraphQL API with a proxy (gateway or sidecar).
The proxy in this architecture is managed as cloud-native infrastructure: it’s configured declaratively, compatible with modern Kubernetes platform patterns, and based on the leading proxy technology in the market: Envoy Proxy. The GraphQL server is a separate deployment requiring code changes to modify and evolve behavior – it also represents an extra network hop and additional operational overhead to maintain. There’s nothing fundamentally wrong with this approach, but we feel there’s a more efficient way to support GraphQL in an application architecture to simplify the lives of application development teams and platform engineering teams alike.
Embed GraphQL with Envoy Proxy in Gloo Gateway to make life easier
Solo.io is already a leader in the gateway and mesh space for application networking considerations. We are adding the GraphQL benefits to provide a complete solution to customers looking to deploy GraphQL APIs.
Solo.io knows Envoy Proxy inside and out. We enhance and create new Envoy filters to help our customers make the best use of Envoy in their platform. When we think about GraphQL from an application networking standpoint, we consider it to be an additional protocol layer (let’s call it Layer 8) that Envoy can be enhanced to understand natively. We have implemented a full-featured GraphQL server component as an Envoy filter to support everything you need in GraphQL directly in the proxy layer.
This results in a drastically simplified and optimized platform architecture that consolidates GraphQL and Application Network considerations into a single component in your architecture: the proxy. The benefits of this approach include
- Completely eliminates the development and operational expense of maintaining separate application deployments for each GraphQL server.
- Optimizes performance with a native C++ filter implementation in Envoy, eliminating extra network hops to a separate GraphQL server.
- GraphQL capabilities are based on declarative configuration, just like the rest of your cloud-native infrastructure. Fully compatible with CI/CD and GitOps workflows.
- Leverages the existing capabilities Solo.io provides via Envoy, there’s no need to integrate with third-party libraries to create resolvers or GraphQL-specific policies.
- Application development teams simply provide a schema definition and configuration to wire upstream resolvers into the fields in their schema. Even simpler, teams can leverage automatic discovery and generation of GraphQL APIs from existing REST and gRPC APIs.
- Instantly enables GraphQL in any architecture where you have a proxy, scaling from the simplest use cases to the most advanced federated multi cloud environments.
How GraphQL runs in Gloo API gateways and service mesh
First, Solo.io provides key language support in its GraphQL server, including fields, arguments, aliases, variables, directives, queries, unions etc. This makes it easy for a team to migrate their current GraphQL solution over to Gloo Gateway.
In addition, GraphQL server and config management is all declarative. This means that all your GraphQL resolver configuration can live as YAML resources that you can check into your source repository. Platform and application development teams can now receive all the benefits of a GitOps workflow, including configuration change reviews, history and changelog tracking. This also provides an easy way to revert back to a previous git commit in the event that a bug is introduced into the system.
Gloo GraphQL also makes it especially easy to migrate from existing APIs over to GraphQL APIs without ever touching a line of application code. We call this schema discovery and auto-generation. Let’s say you have gRPC, SOAP, and REST API microservices running in your Kubernetes cluster. Gloo can discover these API specifications and definitions, and translate them directly into GraphQL schemas and resolvers. Now your clients can issue GraphQL queries to the GraphQL server, and the server will handle translating those queries into the respective API protocols, as well as translating the responses back into the GraphQL response that the client expects.
These are just a few of the many features we offer around GraphQL in the Gloo platform. Stay tuned for additional blog entries where we’ll dive into the architecture and roadmaps for GraphQL, but for now be sure to check out our GraphQL sessions from SoloCon – join us!
- Introducing GraphQL for Gloo with Keith Babo, Sai Ekbote
- Secure Gateway & GraphQL Server: Choose Two, Deploy One with Kevin Dorosh, Adam Sayah
- Hands on with GraphQL with Sai Ekbote, Keith Babo
- Using Envoy Proxy as a GraphQL Engine Workshop with Adam Sayah, Keith Babo
Learn more on our product page for GraphQL.
If you’d like to join our beta for GraphQL on Gloo Gateway, sign up for a demo here.
