How confident are you that changes to your API won’t break any clients? Not having confidence in knowing what could break when you release changes to your graph can grind teams to a halt and cause all sorts of problems for clients consuming your graph.
In this article, we’ll look at how adopting a DevOps culture can help you evolve your graph faster, improve communication around your data graph, as well as the role Apollo plays in achieving a DevOps workflow for your data graph.
What is DevOps?
DevOps is a set of practices that combines software development and IT operations. It aims to shorten the systems development life cycle and provide continuous delivery with high software quality. DevOps shares a lot of principles with Agile software development.
Implementing DevOps is not just about tools; it is also about how people work and the processes they use. DevOps is about unifying the engineering teams responsible for running an application or service in production.
Ideally, one team manages all aspects of the service, including security and testing functions. In larger organizations, there may still be some functional specialization. Still, it remains critical that the process and communication focus on the end-to-end delivery of the entire service.
How does DevOps help me ship more quickly and reliably?
One of the major benefits of adopting GraphQL is the ability to gradually evolve your API over time instead of being locked into versioning and large releases. However, as with all things, there’s an associated cost. Because it’s not a large coordinated effort to release changes to a graph, it’s pretty easy to change or remove a type or field that will break one or more clients.
Communication between everyone who consumes and maintains the graph can break down as your graph grows. To consistently meet clients’ needs, we need to evolve a graph gradually, but we want to be able to do so quickly and reliably.
By adopting a DevOps culture and blending operations with development, we can greatly improve communication around a data graph. Improved communication leads to shorter feedback loops, fewer errors, and faster deployments.
Under a DevOps model, development and operations are no longer “siloed.” Instead, graph usage data is used in the build, test, and planning phases of a graph’s lifecycle.
How does Apollo help me with DevOps?
At Apollo, we believe that data graphs are the epicenter of communication for teams and companies that adopt GraphQL. It’s why we’ve invested so heavily in creating the tooling needed to set up DevOps best practices for GraphQL APIs. Apollo provides a platform on top of a schema registry that works together to help you at each stage in the DevOps lifecycle.
Apollo offers various tools to help you develop your API faster. From Apollo Explorer, a cloud-based GraphQL IDE specifically tailored to GraphQL developers, to numerous open-source libraries, Apollo is deeply invested in helping developers build data graphs faster.
When developing locally, you can use development graphs, which enables you to use all of Apollo Explorer’s powerful features (like intelligent search and variable extraction) with your locally running GraphQL server.
Schema checks in Apollo Studio help you collaborate on your graph with confidence. Checks validate your schema changes against historical operations to ensure changes will not break existing clients.
For federated graphs, we also understand how important it is to have visibility of your graph’s composition. That’s why we’ve introduced build checks and webhooks to help you better understand the impact of schema changes, update your data graph faster, and allow more teams to contribute to the graph safely.
Our new Rover CLI helps you safely publish and fetch GraphQL schemas (monolithic and federated) from the Apollo schema registry. It is the successor to the Apollo CLI as the primary command-line tool for working with graphs.
When it comes to deploying federated graphs, Apollo provides managed federation. With managed federation, your gateway is no longer responsible for fetching schemas from your subgraphs on startup. Instead, your subgraphs push their schemas to the Apollo schema registry, verifying that they successfully compose into a federated schema. Studio then updates your graph’s latest configuration on composition success and makes your changes available to your gateway.
Apollo Studio’s observability features give you insight into every way your graph is being used and helps you find what’s wrong, what’s new, or what’s recently changed and take action.
Tracing – Automatically trace your operation’s resolvers, even across federated services, with no added configuration in Apollo Server. Visualize how your resolvers execute, identify bottlenecks, track headers and variables associated with your requests, and more.
Clients – See precisely which clients are querying your graph and what operations they’re sending — track changes to operations, performance degradations, and error spikes across client versions.
Deprecations – Studio’s field-level usage tracking tells you precisely which of your clients last used each of your schemas fields, giving you the confidence to deprecate fields and sunset them without breaking any active usage of your graph.
Aside from observability around graph performance, Apollo Studio also provides a history of your schema, daily reports, and schema change notifications to help keep you and your team(s) informed.
With Apollo Studio, you can view everything about your graph in one place – what data types exist, their documentation and interrelationships, the services that implement them, who are using them, when they last changed, when they last changed, and explore your graph with Apollo Explorer.
When it comes to scaling beyond a single graph, Workbench can help you design a federated graph from the comfort of your editor without changing code or running servers.
Adopting a DevOps culture provides your team(s) with the safety, trust, and agency needed to ship changes to your data graph quickly and reliably. Apollo provides an extensive platform that helps GraphQL API developers put DevOps best practices in place by providing CI/CD and observability for your graphs.
To get started with Apollo Studio, head to studio.apollographql.com/dev.
Stay in our orbit!
Become an Apollo insider and get first access to new features, best practices, and community events. Oh, and no junk mail. Ever.
Make this article better!
Was this post helpful? Have suggestions? Consider so we can improve it for future readers ✨.