GraphQL is an excellent technology with a great ecosystem, and we’re still early in the adoption curve for enterprises that maintain a large set of GraphQL APIs. Yet, controlling your destiny with GraphQL is challenging for various reasons, such as the lack of visibility and security in GraphQL itself. When using GraphQL in production at scale, additional tools and services are needed to maintain your APIs.
For some GraphQL vendors, such as Apollo Graph Inc., moving GraphQL tools and services into a SaaS offering, GraphOS, makes sense. Yet, Apollo’s goal is to host your entire GraphQL infrastructure, including the GraphQL gateway. Additionally, GraphOS offers observability and security features that are proprietary to the Apollo tech stack. This comprehensive model naturally causes vendor lock-in and gives Apollo control over your GraphQL destiny. To make matters worse, Apollo tech stack users are being forced into upgrading and/or migrating technologies, and lower-tier offerings of GraphOS have become unaffordable for many.
Another example is AWS AppSync, which is an AWS-native GraphQL gateway. What if you want to migrate to Google Cloud and Hasura, for example? This is a very different tech stack, but it’s still possible to migrate away while keeping GraphQL technologies agnostic to your tech stack. By staying agile with your GraphQL deployments and not putting all your eggs in a single GraphQL basket, you can maintain some level of control over your GraphQL destiny. This is where neutral GraphQL vendors like Inigo can help.
You can make confident decisions on your future with a GraphQL vendor by deeply understanding your GraphQL graph, including specific key measures. It’s impossible to predict the true cost of migrating to another GraphQL gateway or server without understanding the impact on your team and API users. By understanding this true cost, you can take control of your destiny with GraphQL.
Inigo’s purpose is to provide observability, security, and manageability of your GraphQL APIs while still being agostic to what GraphQL server or gateway you might be running. If you’re considering changing your GraphQL server or gateway, Inigo gives you the data and insights you need to make the right decisions on moving forward.
So, what metrics and actionable intelligence does Inigo provide that allows you to control your GraphQL destiny? Let’s walk through them:
Having a high-level view of your overall graph utilization is essential so you know where to focus first on analyzing your graph. Having the big-picture view will allow you to plan and prioritize a deeper analysis of your graph. By having actionable insights, you will be able to move forward with further analysis and decision-making.
By understanding specifics about where the heavy usage is in your graph, you can take mitigating steps to reduce the risk of outages or errors when you modernize or migrate the GraphQL server or gateway underpinning your graph.
When modernizing or migrating GraphQL technologies, it’s best to reduce the scope as much as possible and eliminate unused functionality to achieve a quick win. With a reduced scope, less work needs to be done, and the risk level goes down.
Some users of your API are likely to be more business-critical than others, and understanding their specific patterns of usage of your graph is critical to adequately supporting them while introducing change into your GraphQL deployment.
You may consider changing the underpinnings of your graph if performance bottlenecks originate from the GraphQL server or gateway. Expensive queries with significant depth and height can also cause bottlenecks, especially for frequently used queries.
Not only do you want to understand where, when, and why errors are occurring in your graph, it’s essential to know where the hotspots are. These hotspots indicate where additional errors are likely to occur, especially when introducing change.
You will likely face four choices when it comes to controlling your GraphQL destiny when working with a GraphQL vendor such as Apollo Graph, Inc.:
By capturing the key measures outlined in this article, making a decision will be straightforward, as you will have the data you need to weigh the pros and cons of each option. You and your team will be able to move forward with confidence that you made the right decision!
For example, suppose you have a very brittle graph with numerous hotspots and error-prone operations. In that case, kick the can, focus on improving the underlying GraphQL services, and start decoupling them from a vendor-specific GraphQL implementation. With the actionable intelligence gleaned from Inigo, you can plan and prioritize your efforts to get the quick wins you need before reevaluating your options.
No matter your decision, Inigo can help you along the way. Using the key measures and actionable intelligence, you can continue to monitor for improvements over time and make sure you are prepared to introduce change, whether it’s driven by moving to a new GraphQL server or gateway or potentially adopting a SaaS that offers a cloud-hosted gateway.
For example, suppose you need to modify your GraphQL schema to refactor or prune your graph. In that case, you can closely monitor the ongoing graph usage to ensure that your API users no longer use deprecated operations, objects, and fields. This process will take time, and Inigo makes it easy!
Try Inigo today to start taking control of your GraphQL destiny! Learn more and get started with a free trial at app.inigo.io.