Streamline 8 Everyday Tasks of a GraphQL Developer with Inigo

Overview

GraphQL is a great technology for organizations to modernize and scale their APIs across teams. But what is often overlooked is the complexities of GraphQL development that overload a developer's day-to-day activities. Also, with the advent of DevOps and API platform teams, many developers find themselves partly responsible for monitoring the GraphQL services and fixing production issues as they arise. Most developers just want to write code and focus on delivering features, so tools that streamline GraphQL for developers are immensely valuable.

Here are the ways Inigo’s GraphQL platform helps developers throughout their day and simplifies building and maintaining GraphQL services, and how Inigo aligns with the typical daily responsibilities of a GraphQL developer:

1. Monitoring for errors and optimizing the performance of GraphQL services that are running in production

Inigo provides detailed observability to quickly identify recent and frequent errors across all GraphQL services, aligning with a developer’s need to maintain reliable and performant APIs. Developers log into Inigo and view dashboards that give a high-level overview of the health of the GraphQL services that they are responsible for, including the ability to drill down into each subgraph.

For Inigo’s users, we see developers using Inigo several times a day to check on the current state of their services, whether they are running in production or non-production deployments.

2. Implementing data security, including authentication and authorization

Inigo provides robust security features, including JWT token authentication and Role-Based Access Control (RBAC) for field-level security based on the GraphQL schema. Additionally, Inigo implements GraphQL query protection and rate-limiting capabilities to provide additional security. Finally, GraphQL introspection should be secured using RBAC, so disabling introspection in production is unnecessary.

Even better, developers do not need to write a line of code to leverage these security features of Inigo. Instead, Inigo applies policies created in YAML that configure RBAC, rate-limiting, query protection, and more. This separation of concerns is welcome to developers mired in writing complex authentication and authorization code directly into their GraphQL resolvers.

3. Managing deployment and continuous integration of GraphQL services

Inigo allows your team to effectively implement a GitOps workflow for building and maintaining GraphQL services using Inigo. The YAML policies discussed in #2 can be checked into a Git rep and applied during the CD phase of the build pipelines. This applies to any Inigo YAML configuration, from Services to Subgraphs. This is possible by integrating the Inigo CLI into the build pipelines.

The Inigo CLI can also trigger Schema Checks and Publishing during development and CI, as discussed in #4.

4. Ensuring Quality with Code Reviews and Automation

Just doing code reviews for GraphQL service changes isn’t enough. Tools and automation are needed to supplement code reviews to give the full picture if any code or schema changes will cause problems, including breaking changes, new instability, or performance degradation. For example, developers will not immediately recognize if a GraphQL schema change will have unforeseen consequences, such as breaking existing GraphQL clients' queries. If Apollo Federation is used, there is also a high risk for composition errors that will not be initially obvious.

Inigo provides two main benefits when it comes to supplementing code reviews and ensuring that quality code gets delivered to production.

1. The Inigo CLI can be plugged into the CI pipeline, including GitHub Actions, to ensure the schema changes are valid and will not break existing clients and also not break composition for Apollo Federation. Even better, the developers can check for breaking changes on their local machine using the Inigo CLI before creating a pull request.
2. Inigo’s observability can be used for Test environments to observe for new errors or performance issues before they ever make it to a production rollout. This will be even more effective if integration tests are run that fully exercise the GraphQL APIs daily.

5. Developing and maintaining GraphQL schemas

If GraphQL schema changes are needed, a developer will need the proper context to make schema changes. This is where Inigo comes in where it’s easy to see:

1. The currently published schemas, including the supergraph and subgraphs
2. A full history of the schema changes made over time with the ability to diff the schemas
3. The ability to see analytics data to the field level for the schema and also see a heat map of the utilization of the schema by existing GraphQL clients

As such, a developer can leverage Inigo’s schema tracking and analytics to view the schema’s evolution before introducing any further changes to the GraphQL schema.

6. Collaborating with teams to maintain coding standards and practices

GraphQL schemas are the foundation of building GraphQL services, and if the schemas are inconsistent across teams and services, there will be problems with maintenance, including implementing Federation in the future.

An organization should standardize how schemas are formatted and implement proper naming conventions. While developers will do their best to follow these conventions, mistakes are bound to happen, and that’s where Schema Linting comes in.

The Inigo CLI supports Schema Linting, which will validate the current schema’s adherence to the standards. The developer can run the Schema Linting on their local machine, and the Inigo CLI can be used in the CI pipeline to run a Schema Linting step as part of the build process.

7. Implementing GraphQL Services (Subgraphs)

While Inigo cannot help developers write code (leave AI to that), it will help developers implement their subgraphs when using Apollo Federation. Often, a developer will only have easy access to some of the subgraphs on which their subgraph depends for composing a supergraph.

Using the Inigo CLI and the LocalCompose configuration, developers can easily extend and override other subgraphs, even if they don’t have direct access to the other subgraph schema. This flexibility helps accelerate the development of subgraph services.

8. Collaborate on Writing GraphQL Queries

Last but not least, developers will need to implement GraphQL queries. Using Inigo’s Explorer, developers can easily construct new queries, save those queries, and share the queries with other developers. This collaboration enables developers to write more effective queries and speeds up the development process.

Conclusion

In conclusion, Inigo is an indispensable tool for GraphQL developers, adeptly addressing daily challenges. By providing comprehensive solutions for monitoring, security, deployment, quality assurance, schema management, team collaboration, and query development, Inigo not only enhances the efficiency of GraphQL development but also ensures the high quality and security of the end product.

Inigo’s ability to integrate seamlessly into existing workflows, coupled with the convenience of its features like the Inigo CLI, observability dashboards, and Explorer, makes it a valuable asset in the developer's toolkit. Ultimately, Inigo's well-rounded approach to streamlining GraphQL development allows developers to focus more on creativity and innovation while efficiently handling the complexities of API development and maintenance. This makes Inigo not just a tool but a partner in the journey of GraphQL API development.

Ready to take the next steps with Inigo? You can:

1. Get started for free at app.inigo.io
2. Book a demo today at inigo.io/demo
3. Ask questions on our Slack channel