Embracing GraphQL - A Collaborative Journey.webp

large_Embracing GraphQL - A Collaborative Journey.webp

medium_Embracing GraphQL - A Collaborative Journey.webp

small_Embracing GraphQL - A Collaborative Journey.webp

thumbnail_Embracing GraphQL - A Collaborative Journey.webp

Explore the collaborative journey of adopting GraphQL, detailing its phases from initial exploration to compliance, and highlighting the evolution of teams, tools, and strategies needed for effective GraphQL integration in diverse business environments.

## Introduction

The journey of adopting GraphQL technology is a shared adventure, characterized by unique challenges and common trends. As we delve into the stories of fellow GraphQL adopters, it becomes evident that the journey is not a solitary quest, but rather a collective effort involving multiple stages of growth, exploration, and innovation.

We all go through similar phases: Some organizations try to leverage existing supporting tools, some build in-house, and others defer to off-the-shelf solutions. Nevertheless, as the Graph evolves, our teams and needs evolve with it.

Understanding these phases and GraphQL’s lifecycle can help expedite your GraphQL roadmap and hopefully help identify any missing GraphQL building blocks so your org can scale confidently. 

![Embracing GraphQL - A Collaborative Journey Steps.webp](/uploads/Embracing_Graph_QL_A_Collaborative_Journey_Steps_5952d6cf42.webp)

## The Phases of GraphQL Adoption

### GraphQL Exploration
In many organizations, there's usually a 'GraphQL champion', perhaps someone like you. This person might start their first GraphQL project or bring experience from previous projects. Their aim could be anything from experimenting with GraphQL as a side project to introducing new functionalities in a product, or even replacing older REST APIs.

The first step in GraphQL adoption often begins with a basic setup - typically a single GraphQL server connected to one database. This is where key decisions are made about exploring GraphQL, drawing on the wealth of resources and tools available in the GraphQL community.

Choosing the right implementation and tools is crucial at this stage, keeping in mind that different teams within your organization might select different GraphQL tools or implementations based on their specific needs.

As your team gains more experience with GraphQL, the structure of your GraphQL implementation may evolve. This could lead to adopting a federated architecture, where different teams manage their own services (known as subgraphs). These subgraphs are then integrated and managed by a federated gateway, creating a cohesive and unified schema from multiple sources.

### Developer Safeguards: Building a Strong Foundation

This phase, which I like to call the ‘Developer Safeguards’ phase, focuses on expanding the GraphQL toolbox and laying a strong foundation for future development. 

This phase integrates specific GraphQL concepts into the development lifecycle by applying a declarative shared configuration and integrating it with development management tools like CI/CD.

Essential tools often adopted during this phase include:
- Schema Checks: Ensuring that GraphQL schemas are robust and error-free.
- Operation Registry: Efficient management of GraphQL operations.
- Schema Registry and Composition: Organizing and managing multiple GraphQL schemas.
- Linting: Maintaining code quality and consistency.

### Acceleration
In the ‘Acceleration’ phase, the adoption of GraphQL gains momentum. Here, multiple teams might start offering GraphQL endpoints, and the responsibility for the operability of the graph often shifts to broader API/Platform teams, who own a broader API mandate.

Collaboration is needed to speed up product delivery between GraphQL subgraph tenets, the platform team, and the frontend teams. This phase includes exploring tools for:
- Advanced GraphQL Observability: Gaining deeper insights into GraphQL operations.
- Performance and Cost Analysis: Understanding and optimizing the resource utilization.
- SubGraph Trace: Tracing and troubleshooting GraphQL queries.
- Elevate GraphQL Errors: Identifying and prioritizing critical errors.
- Assessing GraphQL System Health: Maintaining the overall health of the GraphQL system.

This is a pivotal stage. The first reaction is to try and leverage existing REST API tools to help with GraphQL's missing building blocks. In some organizations, these tools are sufficient, but in others, it's realized that existing REST tools lack the necessary breadth to support a free-form API like GraphQL.

![Embracing GraphQL - A Collaborative Journey Gaps.webp](/uploads/Embracing_Graph_QL_A_Collaborative_Journey_Gaps_301b07c9d7.webp)

### Intelligence

The third stage, termed the “Intelligence” phase, marks a point where GraphQL’s influence extends beyond just the frontend and backend engineering teams. It involves GraphQL collaboration as it starts impacting various organizational teams, including:
- Business Teams: Seeking operational reporting.
- Product Teams: Looking to understand feature impacts.
- DevOps: Handling infrastructure and operability.

Discussions now revolve around product insights, anomaly detection, alerts, schema management, coverage, and history.

![Embracing GraphQL - A Collaborative Journey Players.webp](/uploads/Embracing_Graph_QL_A_Collaborative_Journey_Players_183e774d12.webp)

### Compliance and Governance
The final phase addresses GraphQL’s penetration into large organizations across Fortune 500, especially in sectors like finance. The ability to answer audit trail questions like “Who can access what?” and later on, “Who accessed what?” poses organizations with new hurdles. 

This phase involves integrating security concepts such as RBAC and rate-limiting into day-to-day GraphQL operations in a declarative and abstract manner, necessitating the involvement of security and compliance teams.

## Conclusion
The journey of adopting GraphQL is a testament to the power of collaboration and innovation. Each phase represents a crucial step in integrating this transformative technology across diverse business landscapes. Without cross-team efforts, appropriate tooling, and clear expectation-setting, the path to adopting GraphQL can be challenging. 

As the GraphQL community continues to evolve, so too does its potential to revolutionize how we think about and manage APIs in the modern digital ecosystem.

Can you pinpoint where your organization currently stands in this journey? Can you identify your gaps?


Embracing GraphQL - A Collaborative Journey

large_top_10_benefits_inigo_over_graphos.webp

medium_top_10_benefits_inigo_over_graphos.webp

small_top_10_benefits_inigo_over_graphos.webp

thumbnail_top_10_benefits_inigo_over_graphos.webp

top_10_benefits_inigo_over_graphos.webp

Switch from GraphOS to Inigo: Top 10 Benefits You Can't Ignore!

At the industry events [GraphQLConf](https://inigo.io/blog/graphqlconf_2023_recap/), [GraphQL Summit](https://inigo.io/blog/graphqlsummit_2023_recap/), and API World, we noticed a clear message: Users of Apollo Studio and GraphOS are looking for alternatives. Despite its range of features, GraphOS falls short in critical areas such as observability and security. Moreover, its pricing structure and rigid deployment demands are compelling Apollo customers to consider other options.

Responding to this customer demand, Inigo has enhanced its platform, positioning it as a [seamless substitute for Apollo GraphOS](https://inigo.io/apollo-vs-inigo/) without compromising on the superior [observability](https://inigo.io/observability/) and [security](https://inigo.io/security/) features that set Inigo apart. 

## Top 10 Benefits of Inigo Over GraphOS

Inigo’s superior feature set directly translates to improving the everyday experience of using GraphQL for developers, operators, architects, and managers of GraphQL services, including the dedicated API Platform Teams that are becoming more commonplace in large organizations. 

Here are the Top 10 benefits of swapping out GraphOS for Inigo:

### 1. Take Your Existing Apollo GraphQL Deployments To the Next Level

Inigo readily supports Apollo's open-source [Server](https://docs.inigo.io/product/agent_installation/javascript_apollo_plugin), [Gateway](https://docs.inigo.io/product/agent_installation/javascript_apollo_gateway), and [Router](https://docs.inigo.io/product/agent_installation/rust_apollo_router). You can easily integrate Inigo with your existing Apollo deployments by installing the Inigo agent, streamlining your setup process. Migrating from GraphOS to Inigo is straightforward, and you can leverage Inigo’s [schema composition](https://inigo.io/managed_federation/) and [schema-checking](https://inigo.io/managed_schema/) features for a smooth transition with Apollo Federation. Best of all, you can immediately leverage all of the other benefits of Inigo to take your Apollo deployments to the next level!

### 2. Freedom to Choose and Scale for the Future

As your organization's use of GraphQL evolves, so must the adaptability of your teams and technologies. Relying solely on vendor support tailored for the Apollo stack may prove restrictive, particularly when various departments within your organization require diverse GraphQL implementations to meet their unique technical demands. Inigo offers a versatile management platform that integrates effortlessly with [any GraphQL server](https://docs.inigo.io/product/agent_installation/) configuration, ensuring a uniform GraphQL management experience throughout your enterprise. Inigo combines robust power with unparalleled flexibility.

### 3. Spare Your Developers from GraphQL Complexities

Inigo goes above and beyond GraphOS to make GraphQL simpler for developers. Inigo instills a *separation of concerns* between GraphQL observability and security and the GraphQL implementation code that developers need to write. Inigo’s configuration-as-code approach can supplant hundreds of lines of code for query protections, JWT authentication, RBAC, rate-limiting, logging, tracing, and more. Introducing Inigo to your developers and adopting its features can be done gradually, and it’s not a one-size-fits-all approach.

### 4. Improve Collaboration for Building and Operating GraphQL Services

Developers, Architects, and Operators involved in GraphQL services require a collaborative approach to successfully develop, deploy, monitor, and maintain these services. While GraphOS provides fundamental collaborative tools through its GraphOS Explorer, Inigo takes this a step further by integrating features of Explorer with enhanced analytics and schema management, achieving a level of integration not possible in GraphOS. 

Inigo also simplifies the collaboration process by allowing users to share direct links to pertinent Analytics data, such as error reports or performance metrics, streamlining the diagnostic process. Additionally, Inigo enables the creation of user groups with defined roles and responsibilities, ensuring that information can be shared effectively without compromising access control. 

### 5. Improve Standards for Your GraphQL Services

Enterprises employing GraphQL across multiple teams often grapple with standardizing their GraphQL schemas. This challenge is further intensified by the complexities of managing supergraph schemas with Apollo Federation. Developers need robust tools that can be used locally to facilitate schema modifications while adhering to set standards and compliance requirements. Inigo addresses these issues with its advanced GraphQL Schema Linting feature that parallels GraphOS’s linting capabilities. 

Additionally, Inigo's suite of developer tools, coupled with its configuration-as-code approach, simplifies the enforcement of standardization. It also provides sophisticated schema-checking functionalities that aid in normalizing schemas and preempting composition errors, ensuring smooth integration and consistency across the enterprise's GraphQL architecture.

### 6. Make Informed Decisions on How to Evolve Your GraphQL Schemas

GraphOS lacks the detailed analytics required to thoroughly examine client interactions with your API and schema. In contrast, Inigo captures comprehensive data, logging every type, field, and directive queried, and correlates this data to the actual GraphQL clients, providing valuable metrics. This information can be superimposed on your GraphQL schema to create visual heat maps, offering clear insights into how clients are utilizing your schema. 

With Inigo, you can drill down to the specific details of who queried what and when including the frequency of each query. This level of detail empowers you to proactively safeguard against potential breaking changes and to strategically plan the future development of your schema. Inigo stands alone in providing these deep analytics that are essential for fully understanding the performance and use of your GraphQL APIs. 

### 7. Optimize Your GraphQL Services More Easily with Real-Time Performance Data

Inigo offers a comprehensive solution for monitoring GraphQL performance by capturing 100% of query performance data, in contrast to GraphOS, which only captures a small sample. This complete data collection with Inigo means you'll have access to accurate p95 metrics, crucial for pinpointing performance irregularities and bottlenecks that might remain unnoticed with partial data. Additionally, Inigo enables you to trace poorly performing queries to the precise moment they occurred, allowing for a more straightforward comparison with other monitoring tools and a much easier diagnosis of any dips in performance.

### 8. Improve Error Capturing and Alerting for GraphQL Operations

While GraphOS provides basic features to capture and alert on GraphQL errors, Inigo elevates this functionality by allowing users to categorize and prioritize errors, ensuring that teams focus on the most critical issues first. Inigo’s advanced capabilities include custom GraphQL directives tailored to trigger alerts for only the most severe errors, thus mitigating the risk of alert fatigue. Adopting Inigo transforms your GraphQL error-capturing and alerting capabilities, ensuring that your GraphQL monitoring is effective and efficient.

### 9. Make Compliant, Mission-Critical GraphQL Services Possible

The adoption of GraphQL in mission-critical enterprise environments hinges on its ability to meet rigorous compliance standards. These standards often encompass service-level agreements (SLAs) that specify exacting performance, uptime, and security criteria. 

For sectors like finance and healthcare, compliance takes on an even greater significance due to the necessity of meticulously tracking client data access and the capacity to conduct thorough audits. Features essential for maintaining such compliance, including rate limiting, role-based access control (RBAC), advanced performance monitoring and alerting, and audit trails, are beyond the capabilities offered by GraphOS. 

Moreover, compliance often demands versatile deployment strategies for GraphQL servers and gateways, such as on-premises or private cloud deployments, while also needing to align with SaaS applications. Inigo stands out as the sole provider with the comprehensive features and tools required to construct GraphQL services that align with the high compliance standards of mission-critical enterprise operations.

### 10. Understand the Business Value Your GraphQL Services Are Providing

If your organization is just beginning to adopt GraphQL, you might be facing the considerable task of shifting from established REST or even traditional SOAP services to this new technology. A hurdle in adopting GraphQL is that it can act as a layer over existing backend services, potentially masking critical API usage metrics, which are key to understanding GraphQL's business impact. Such a lack of clear data can make it hard to argue for increased investment in GraphQL.

Inigo offers a solution with its sophisticated analytics tools, which shed light on how GraphQL services are used, right down to individual subgraphs. This insight allows for a detailed analysis of your schema's efficiency and gaps, helping to chart a purposeful path for the integration of GraphQL across your organization. Inigo's detailed analytics are essential for demonstrating the value of GraphQL, offering a depth of understanding that GraphOS simply does not provide.

## GraphOS vs. Inigo Feature Comparison

Inigo matches and surpasses the capabilities of GraphOS in critical areas, including observability, analytics, security, managed federation, and developer tools. Inigo effectively fills the gaps found in GraphOS, and a direct comparison between the two platforms is shown in the following table:

![inigo_graphos_feature_comparison_table.webp](/uploads/inigo_graphos_feature_comparison_table_d7a927f526.webp)

As you can see in the table, there are quite a few differences between GraphOS and Inigo. Still, Inigo surpasses GraphOS for critical features that users of GraphQL want to improve their day-to-day experience with GraphQL.

## Conclusion

In the fast-paced tech environment where GraphQL has become a critical part of many organizations’ API strategies, choosing the right platform to manage your GraphQL services is pivotal. Inigo emerges not just as an alternative but as a beacon of advancement for those who seek not only to keep pace but to lead in innovation.

Inigo represents a strategic opportunity for businesses to maintain the continuity of their GraphQL operations with minimal pipeline disruption, escape the constraints of vendor lock-in, and ensure compatibility with the existing tech stack.

More than just a tool, Inigo is a safeguard for your developers, a catalyst for rapid GraphQL adoption, and a trusted vendor that understands the needs of an evolving tech landscape. It offers a unique blend of flexibility, security, and insightful analytics that not only rectifies the shortcomings of GraphOS but propels your GraphQL capabilities into a new realm of potential.

By choosing Inigo, you're not just upgrading your GraphQL management platform; you're investing in a partnership that understands the complexities of modern API ecosystems. You're gaining a collaborator dedicated to your growth, one that provides the clarity and control necessary to transform data into actionable insights, turn challenges into opportunities, and convert technological potential into tangible business success.

Here's a quote from one of our satisfied customers highlighting the benefits they've experienced with Inigo:

> *Just wanted to let y’all know that Inigo has been so dope for helping us understand customer impact when something goes wrong. We can see how many unique users were affected in a few clicks. Love that Analytics tab!*

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

1. Get started for free at [app.inigo.io](https://app.inigo.io)
2. Book a demo today at [inigo.io/demo](http://inigo.io/demo)
3. Ask questions on our [Slack channel](https://slack.inigo.io/)

Top 10 Benefits of Inigo’s Replacement for GraphOS

large_graphql-summit-recap.webp

medium_graphql-summit-recap.webp

small_graphql-summit-recap.webp

thumbnail_graphql-summit-recap.webp

graphql-summit-recap.webp

Last week, Inigo had the privilege of attending the GraphQL Summit in San Diego. During the event, we had the opportunity to interact with a wide range of attendees, including both active GraphQL users and contributors from the open-source GraphQL community. We gathered valuable insights on the primary challenges faced by those who are currently using GraphQL in production or are in the process of implementing it.

## Overview
Last week, Inigo proudly participated in the [GraphQL Summit](https://summit.graphql.com) in San Diego, where we engaged with a diverse crowd of GraphQL users and some members of the open-source GraphQL community. The event saw participation from various stakeholders in the GraphQL community including Apollo, the organizer of the GraphQL Summit.

![graphql-summit-team-2023.webp](/uploads/graphql_summit_team_2023_9491aea2b6.webp)

Our CEO, Shahar Binyamin, delivered an engaging talk on GraphQL adoption, attracting a nearly packed room and sparking numerous follow-up conversations. We spoke with over a hundred attendees during booth sessions, breakfasts, lunches, and the evening event, which provided insights and valuable perspectives on real-world GraphQL challenges.

![graphql-summit-shahar-2023.webp](/uploads/graphql_summit_shahar_2023_112c862410.webp)

## Challenges Encountered by GraphQL Users

Here are the key challenges we discovered at GraphQL Summit from those currently implementing GraphQL in production or endeavoring to do so:

1. **Desire for GraphOS Alternatives/Abstraction Layer:** Attendees expressed the need for alternatives to GraphOS and its various features, including gateway/router, federation, schema composition/registry, observability, and security. As many are in the evaluation phase of expanding their GraphQL usage, considering other platforms has become essential to the decision-making process.

2. **Challenges with Federation:** Apollo Federation adoption presented difficulties, with specific concerns surrounding schema refactoring, subgraph composition, the move to the router and the transition to Federation v2.

3. **Needing Flexible Deployments:** Many sought more flexible deployment options, particularly regarding the gateway/router running in private clouds and an isolated GraphQL management platform.

4. **Enhanced Security Requirements:** Security was a top priority, with attendees looking for features like rate limiting and role-based access control (RBAC) in the next phase of GraphQL adoption. 

5. **Compliance and Observability Concerns:** Some attendees sought better compliance tools, including auditing and certification controls. They expressed a need for granular observability, similar to Inigo Analytics.

## Notable Talks

The summit featured numerous insightful talks, and Apollo is currently releasing [videos of these sessions](https://www.youtube.com/playlist?list=PLpi1lPB6opQzUOqG3QroLLN06FF-Q_uhX). Stay tuned as all of them will be posted in the near future!

Some of the talks that resonated most with the Inigo team included:

* 200 NOT OK: High-Resolution Observability by Joey Nenni (PayPal)
* How Intuit Handled The Busiest Time Of Year by Rama Palaniappan (Intuit)
* Locally Debugging Supergraphs at Dow Jones by Ethan Ruoff (Dow Jones)
* Monoliths, Migrations and Mergers Jameson Athanasiou (Liberty Mutual), Hunter Houston (EVgo), Shweta Sharma (Intuit), Conor Dempsey (Poppulo)
* Caching Strategy for High Volume Personalized Content Requests by Emily Voytek (MLB) and Jamie Finucane (MLB)
* From 50 Shades Of Apis to The Least Shady by Arsalan Ellahi (KiwiBank)

## Conclusion

The GraphQL Summit showcased a growing interest in exploring a variety of GraphQL technologies and vendors to address diverse needs. This enthusiasm underscores the desire for a healthy array of options in the GraphQL space, which is crucial for the continued growth of GraphQL in the software industry.

Inigo came out of the GraphQL Summit with many new friends and potential customers. We look forward to continuing the conversations and staying connected with those we met. If you missed us at the GraphQL Summit or are facing similar challenges to those who attended, please reach out and schedule a [meeting](https://inigo.io/demo/) to discuss.

Lastly, for those using the Apollo Gateway or Router and interested in exploring additional functionalities, Inigo offers features like schema composition, schema checking, and schema registry, all compatible with your existing deployment. We're here to demonstrate the possibilities and welcome a discussion to better understand your needs. To learn more, please set up a [demo](https://inigo.io/demo/), and we will show you what’s possible!


GraphQL Summit Recap: Exploring Diverse GraphQL Solutions

large_graphqlconf_2023_recap.webp

medium_graphqlconf_2023_recap.webp

small_graphqlconf_2023_recap.webp

thumbnail_graphqlconf_2023_recap.webp

graphqlconf_2023_recap.webp

## Overview

The GraphQL community came together in the Silicon Valley from September 19 to 21 for an exciting and memorable conference. This year's [GraphQLConf](https://graphql.org/conf/) was a testament to the growth and strength of the GraphQL ecosystem. As we recap this event, we extend our heartfelt congratulations to the GraphQL Foundation for their continued dedication to advancing GraphQL, and we can't help but feel proud of our conference committee members who worked tirelessly to make this event a reality. 

![GraphQLConf_2023_1.webp](/uploads/Graph_QL_Conf_2023_1_d9927e53e7.webp)
Photo Credit: GraphQLConf

![GraphQLConf_2023_2.webp](/uploads/Graph_QL_Conf_2023_2_4ea42451ff.webp)
Photo Credit: GraphQLConf

Inigo was thrilled to be part of the GraphQLConf 2023 event as a Gold Sponsor. We were able to network and build relationships in the GraphQL community in a way not otherwise possible.

![GraphQLConf_2023_3.webp](/uploads/Graph_QL_Conf_2023_3_e3f51dff6f.webp)

## A Short Notice Success
One remarkable aspect of GraphQLConf 2023 was that it came together on relatively short notice. Despite the challenges, the conference delivered a spectacular experience for attendees. Special shout-outs go to Keith Babo and Doc Jones for their outstanding contributions. The conference offered a wide variety of workshops and talks, ensuring that there was something for everyone.

![GraphQLConf_2023_4.webp](/uploads/Graph_QL_Conf_2023_4_cb5f5cf3f6.webp)
Photo Credit: GraphQLConf

## Stellar Speakers
The lineup of speakers at GraphQLConf 2023 was truly amazing. Their knowledge and expertise shone through in every talk, and attendees were treated with valuable insights. The talks were thoughtfully curated to cater to all experience levels, from newcomers to seasoned GraphQL practitioners.

![GraphQLConf_2023_5.webp](/uploads/Graph_QL_Conf_2023_5_cb4830aef1.webp)
Photo Credit: GraphQLConf

## Unconference Excellence
The unconference sessions provided a valuable platform for community members to share their knowledge and engage in discussions on various GraphQL topics. It was a great opportunity for attendees to connect and learn from each other in an unstructured way.

![GraphQLConf_2023_6.webp](/uploads/Graph_QL_Conf_2023_6_0e108bba6f.webp)
Photo Credit: GraphQLConf

## Inigo's Barista: An Afternoon Caffeine Boost
We offered an Inigo expresso bar that gave everyone an option to the standard conference coffee. All attendees greatly appreciated our commitment to a caffeine boost with a supply of lattes, mochas, cappuccinos, and americanos.

![GraphQLConf_2023_7.webp](/uploads/Graph_QL_Conf_2023_7_9693869f31.webp)
![GraphQLConf_2023_8.webp](/uploads/Graph_QL_Conf_2023_8_5cd7a2a7a9.webp)

## Maturity of Adoption
GraphQL has come a long way since its inception, and its maturity of adoption was evident at the conference. With dozens of Fortune 500 companies in attendance, it's clear that GraphQL has become a crucial part of many tech stacks.

## What We Learned
At the heart of any conference are the lessons learned, and GraphQLConf 2023 was no exception. Here are some key takeaways:

### Fusion: New and Cool
[Fusion](https://graphql.org/conf/schedule/4a4e842d1cd0c06083f484d31225abd1/?name=GraphQL%20Fusion:%20Rethinking%20Distributed%20GraphQL) was a standout topic at the conference. The talk introduced attendees to the latest developments in open-source GraphQL federation, promising exciting opportunities for GraphQL developers down the road with a new approach that makes building distributed GraphQL APIs easier.

### Grafast: Unveiling the Potential
[Grafast](https://graphql.org/conf/schedule/275443caa2eda5df06699b724efa533c/?name=The%20Future%20of%20Efficiency%20Is%20Here:%20Add%20Planning%20to%20Your%20Schema!) was another fascinating topic with a new approach to GraphQL execution that enables engineers to build next-level efficiency into new or existing GraphQL APIs – improving application performance, reducing operational costs, and delivering delightful user experiences.

### Null Bubbling: Fixing a $1M Mistake
The talk on [Null Bubbling](https://graphql.org/conf/schedule/50005edb4a441b0335d1b80b4ad62b1a/?name=Fixing%20the%20Billion%20Dollar%20Mistake:%20Client%20Controlled%20Nullability) highlighted that Null has been famously called “the billion dollar mistake”. The Client Controlled Nullability proposal aims to empower client developers to tame nullability in the graph. Attendees left with a newfound understanding of how to avoid costly mistakes in GraphQL development.

### Data Loader: Optimizing GraphQL Queries
The [Dataloader talk](https://graphql.org/conf/schedule/09bc04c42310bfe14024455bce46d781/?name=Dataloader%203.0%20-%20An%20Alternative%20Algorithm%20to%20Solve%20N+1%20Problems) talk dives deep into the topic of efficiently resolving deeply nested data. The talk presented an alternative algorithm that uses breadth-first resolving compared to depth-first, which Dataloader builds on top of.

### Meet the TSC Team Members
The chance to meet the Technical Steering Committee (TSC) team members allowed attendees to connect with the individuals driving GraphQL's development.

### The Future of Federation Spec
The future of the federation specification was a hot topic, and attendees gained valuable insights into the direction GraphQL Federation is heading.

### React Server Components and GraphQL Synergy
A [keynote talk](https://graphql.org/conf/schedule/e3320ba552ee773065a1a132304a36e0/?name=Is%20a%20GraphQL%20BFF%20Necessary%20in%20a%20Server%20Side%20React%20World%20(RSC,%20SAs)?) on how React Server Components and GraphQL work together gave attendees a clear understanding of how these technologies can complement each other in modern web development.

### Standardizing Schemas with Lints
The importance of standardizing schemas was underscored in Unconference discussions on how linting can help maintain consistency in GraphQL schemas.

## What Inigo Presented

Inigo also gave two insightful talks that had great feedback and are worth checking out:

1. **[Unlocking Insights: Navigating the World of GraphQL Observability](https://graphql.org/conf/schedule/f8a4d2b939980ffadf787715033e2b4f/?name=Unlocking%20Insights:%20Navigating%20the%20World%20of%20GraphQL%20Observability)**
2. **[Why Your GraphQL APIs Are (Increasingly) Under Attack](https://graphql.org/conf/schedule/3d167cf84012c4ff2dcca8fca736b0dd/?name=Why%20Your%20GraphQL%20APIs%20Are%20(Increasingly)%20Under%20Attack)**

If you have any questions about what you heard in our talks, feel free to reach out on our [Slack channel](https://slack.inigo.io)!

## Conclusion
In conclusion, GraphQLConf 2023 was an exceptional event that brought the GraphQL community together to celebrate their shared passion and knowledge. With a focus on innovation, learning, and community building, it left attendees inspired and eager to continue pushing the boundaries of GraphQL. We look forward to seeing the lasting impact of this conference on the GraphQL ecosystem in the coming years. Thank you to all who made it possible, and we can't wait to see you at the next GraphQLConf!

[For all conference's videos click here.](https://www.youtube.com/watch?v=3zLmU-W2wYA&list=PLP1igyLx8foE9SlDLI1Vtlshcon5r1jMJ)


GraphQLConf 2023 Recap: A Celebration of Knowledge and Community

Introducing the inigo starter edition unleash graphql superpowers  for free .webp

large_Introducing the inigo starter edition unleash graphql superpowers  for free .webp

medium_Introducing the inigo starter edition unleash graphql superpowers  for free .webp

small_Introducing the inigo starter edition unleash graphql superpowers  for free .webp

thumbnail_Introducing the inigo starter edition unleash graphql superpowers  for free .webp

Inigo empowers your GraphQL experience with cutting-edge analytics, top-notch security, and a managed schema, all at the core of our brand-new Inigo Starter Edition. And here's the best part—it's totally FREE! No credit card is required, and it will remain free forever. Learn how to get started!

## Overview

Inigo empowers your GraphQL experience with cutting-edge analytics, top-notch security, and a managed schema, all at the core of our brand-new Inigo Starter Edition. And here's the best part—it's totally FREE! No credit card is required, and it will remain free forever.

#### *So, what can you achieve with the Starter Edition?* 

Here's a glimpse of the GraphQL superpowers at your disposal:

1. **Advanced GraphQL Analytics:** Dive deep with granular filtering and query-level insights.

2. **Role-Based Access Control (RBAC) Security:** Fortify your GraphQL API with user profiles, user roles, schema subsets, directives, and allowed operations.

3. **Query Protection:** Shield your system from malicious GraphQL queries.

4. **Rate Limiting:** Limit the number of GraphQL queries to your server.

5. **Granular Rate Limits:** Fine-tune rate limits based on your GraphQL schema, queries, and user profiles.

6. **Simplified RBAC:** No need to write code for Role-Based Access Control; Inigo handles it seamlessly.

7. **JWT Token Validation:** Wave goodbye to code for JWT token validation, including JWT signature authentication against a JWKS endpoint.

8. **GraphQL Schema Publishing:** Easily publish your GraphQL schema to a schema repository.

9. **Schema Checks:** Prevent disruptions by checking for breaking changes in your GraphQL API based on live traffic history.

10. **CI/CD Integration:** Incorporate schema checks into your CI/CD pipeline.

11. **Configuration-as-Code:** Configure all Inigo features directly from your Git repository.

Start your Inigo journey with the basics, like implementing query protection, and progressively unlock advanced features like RBAC and the schema registry as your needs evolve.

#### *What's packed in the Starter Edition?*

* **3 User Seats:** Get three team members on board.

* **2 Inigo Services:** Manage two distinct Inigo services.

* **5 Running Inigo Agents:** Keep your operations running smoothly.

* **7 Days of Analytics Retention:** Analyze your data with a week's worth of historical insights.

* **5 Million Monthly API Operations:** Handle millions of API operations each month.

* **Advanced Analytics:** Dive into in-depth GraphQL data analysis.

* **Query Protection:** Fortify your system with query protection.

* **RBAC:** Implement Role-Based Access Control.

* **Object-Based Rate Limiting:** Implement a default rate limit or fine-tune your rate limits.

* **Managed GraphQL Schema Repository:** Easily manage your GraphQL schema.

* **Support for Various GraphQL Servers:** It works seamlessly with many GraphQL server types.

And once again, all of this comes at no cost. If you happen to exceed the limits of the Starter Edition, don't hesitate to get in touch with us about upgrading your account.

#### *Ready to embark on your GraphQL journey with the Inigo Starter Edition?*

You don't need to switch technology stacks or migrate to a cloud-hosted GraphQL server or gateway. Just follow our [Getting Started Guide](https://docs.inigo.io/), and you can [deploy Inigo](https://docs.inigo.io/product/agent_installation/) with a wide range of common GraphQL servers. And if your GraphQL server isn't directly supported, you can still utilize a sidecar or standalone deployment of the Inigo agent without losing any functionality.

If you have any questions about harnessing your new GraphQL superpowers, please reach out to us on our [Slack channel](https://slack.inigo.io/) or drop us an email at [support@inigo.io](mailto:support@inigo.io). We're here to assist you every step of the way!

Introducing the Inigo Starter Edition: Unleash GraphQL Superpowers for Free!

large_hasura_inigo.webp

medium_hasura_inigo.webp

small_hasura_inigo.webp

thumbnail_hasura_inigo.webp

hasura_inigo.webp

Inigo now offers an integration with Hasura, allowing you to observe and secure your GraphQL API running on Hasura. Put Inigo into action and learn how to secure Hasura from denial of services attacks using Inigo's rate limiting and query protection!

## Overview
Hasura is a great way to turn your database into a GraphQL API, and the community version of Hasura can be freely hosted on your infrastructure. Inigo now offers an [integration](https://docs.inigo.io/product/agent_installation/hasura) of Inigo built directly into the Hasura community version, allowing you to observe and secure your GraphQL API running on Hasura.

In this article, you will learn how to install Inigo with Hasura and implement controls against a denial-of-service (DoS) attack against your Hasura instance. As you will see, Hasura, running on its own is vulnerable to various attack vectors that could make Hasura or your database unavailable during a DoS attack.

## Getting Started with Hasura + Inigo

We have an [installation guide](https://docs.inigo.io/product/agent_installation/hasura) available for Hasura + Inigo, and the simplest approach is to use Inigo’s rebuilt container image for Hasura and run it in Docker or Kubernetes. Please follow the instructions in the installation guide so you can implement the DoS attack scenario laid out in this article.

### Demo Scenario Setup

To demonstrate a DoS attack scenario against Hasura, a demo scenario needs to be set up. For the demo, four tables are created in a PostgreSQL database, for which Hasura will generate a GraphQL API. The [database schema setup SQL](https://github.com/inigolabs/workshops/blob/main/hasura-demo/setup.sql) can be easily executed directly in Hasura to create the actual database tables as shown in Figure 1.

![Figure 1](/uploads/hasura_figure_1_433808dd41.webp)

**Figure 1: [Database Schema Setup](https://github.com/inigolabs/workshops/blob/main/hasura-demo/setup.sql) in Hasura Console**

### Setup Table/GraphQL Relationships

Now that the database tables are created, it’s possible to define the **Relationships** that establish the mapping of the tables for generating the GraphQL schema. These mappings make it possible to nest the **author** in the **article**, for example.

In Figures 2-4, you can see how the **Relationships** are set up for **article**, **author**, and **article_tag** for the purposes of this demo. Please note that there is a bidirectional **Relationship** between the **article** and **author**, as this will be important for creating a vulnerability as demonstrated in this article.

![Figure 2](/uploads/hasura_figure_2_ac678b7565.webp)

**Figure 2: article relationships setup (tags, author) in Hasura Console**

![Figure 3](/uploads/hasura_figure_3_aad5a2b7a0.webp)

**Figure 3: author relationship setup (articles) in Hasura Console**

![Figure 4](/uploads/hasura_figure_4_9ec5410d38.webp)

**Figure 4: article_tag relationship setup (tag) in Hasura Console**

### Insert Sample Data with a GraphQL Mutation

Now that the tables and the **Relationships** are set up, it’s easy to populate the tables with a [single GraphQL **mutation**](https://github.com/inigolabs/workshops/blob/main/hasura-demo/graphql/insert_article.graphql) that contains an **article**, **author**, and a set of **tags** associated with the **article**. The **mutation** can be run directly from the Hasura console in GraphiQL as shown in Figure 5.

![Figure 5](/uploads/hasura_figure_5_65e55fa629.webp)

**Figure 5: [Insert Sample Data](https://github.com/inigolabs/workshops/blob/main/hasura-demo/graphql/insert_article.graphql) in GraphiQL in Hasura Console
Run Sample GraphQL Queries**

In Figures 6 and 7, you can see the bidirectional nature of **article** and **author** where you can query from either direction with these sample queries. This means that [for every **article**, you can query the **author**](https://github.com/inigolabs/workshops/blob/main/hasura-demo/graphql/get_article_details.graphql), and [for every **author** you can query the associated **articles**](https://github.com/inigolabs/workshops/blob/main/hasura-demo/graphql/get_author_articles.graphql).

![Figure 6](/uploads/hasura_figure_6_a3e69326c8.webp)

**Figure 6: [Sample Query for article](https://github.com/inigolabs/workshops/blob/main/hasura-demo/graphql/get_article_details.graphql) with the author and tags in GraphiQL in Hasura Console**

![Figure 7](/uploads/hasura_figure_7_6304c6af97.webp)

**Figure 7: [Sample Query for author](https://github.com/inigolabs/workshops/blob/main/hasura-demo/graphql/get_author_articles.graphql) with the articles and tags in GraphiQL in Hasura Console**

In Inigo, you can see the GraphQL query execution times under the **Latency** column for these two queries in Figure 8. Each query has a latency of about 200ms, respectively, on the first query run (no data is cached). Additional execution times will be lower as PostgreSQL will cache data.

![Figure 8](/uploads/hasura_figure_8_98da4ad8a4.webp)

**Figure 8: Latencies for the two sample queries in Inigo Analytics**

Now, the setup of the demo scenario is complete, and we can look at how to launch a denial of service (DoS) attack against Hasura!

## DoS Attack Scenario #1: Flood with GraphQL Queries

The Hasura community version does not have rate-limiting features built into it. This means your Hasura instance will be vulnerable to bad actors flooding it with GraphQL queries, bringing Hasura and the database to a grinding halt.

To simulate this scenario, we will use the [**k6** load testing tool](https://k6.io/) with the [JavaScript code with a GraphQL query](https://github.com/inigolabs/workshops/blob/main/hasura-demo/k6/basic-query.js) as shown in Figure 9.

![Figure 9](/uploads/hasura_figure_9_52d2f97429.webp)

**Figure 9: Simple [Load Test Script](https://github.com/inigolabs/workshops/blob/main/hasura-demo/k6/basic-query.js) for k6**

Using this **k6** load test script, it can be run with the following command that will run with 2000 virtual users (vus):

**k6 run --vus 2000 --duration 30s basic-query.js**

After running this load test (ignore any connection errors from **k6**), you can then go to Inigo Analytics (app.inigo.io) to observe that these queries are taking over 5 seconds to execute, as shown in Figure 10. If you try to run queries from GraphiQL while the load test is running, you will see that Hasura has become nearly unresponsive as it’s flooded with GraphQL queries.

![Figure 10](/uploads/hasura_figure_10_ffc6b35f82.webp)

**Figure 10: High latencies when Hasura is flooded with queries in Inigo Analytics**

## DoS Attack Scenario #2: Deeply Nested Query

While Scenario #1 slowed down Hasura to be nearly unusable, Scenario #2 made it completely unresponsive. The key is to have an [extremely nested query](https://github.com/inigolabs/workshops/blob/main/hasura-demo/graphql/get_author_articles_dos.graphql) by abusing the bidirectional relationship between **article** and **author**. This relationship allows an infinite depth to a nefarious query with a snippet shown in Figure 11.

![Figure 11](/uploads/hasura_figure_11_e3a3b5402d.webp)

**Figure 11: Snippet of the [deeply nested nefarious query](https://github.com/inigolabs/workshops/blob/main/hasura-demo/graphql/get_author_articles_dos.graphql)**

In this scenario, a nefarious query has a depth of 37 and a height of 118. A single query execution can take well over 1 second, as shown in Figure 12.

![Figure 12](/uploads/hasura_figure_12_e109a9ba7d.webp)

**Figure 12: Single execution of the deeply nested nefarious query in Inigo Analytics**

For this Scenario #2, we are going to leverage **k6** again with the [deeply nested query in a script](https://github.com/inigolabs/workshops/blob/main/hasura-demo/k6/nested-query.js), but this time with only 10 vus:

**k6 run --vus 10 --duration 30s nested-query.js**

When running this load test, **you will observe Hasura becoming completely unresponsive**, as no queries will execute from GraphiQL. Additionally, no query metrics are being sent to Inigo as Hasura cannot execute any queries, period. Once the load test ends, Hasura will eventually become operational again.

As you can see, while Scenario #1 was crippling to Hasura, Scenario #2 is even worse. Additionally, when Scenario #2 happens, it may trigger service health checks to fail and Hasura to be restarted, only to succumb to an ongoing DoS attack again.

## DoS Attack Scenario #1 Mitigation: Inigo Rate Limiting

To mitigate Scenario #1, Rate Limiting can be implemented with Inigo where the Inigo middleware running inside of Hasura will apply rate-limiting controls to all incoming GraphQL query requests.

The first step is implementing an [**anonymous_profile** with your Inigo **Service**](https://github.com/inigolabs/workshops/blob/main/hasura-demo/inigo/service.yml) as shown in Figure 13. This will be used to apply RateLimit to all unauthenticated incoming requests as shown in Figure 14.

![Figure 13](/uploads/hasura_figure_13_dc14e6e087.webp)

**Figure 13: [Inigo Service with anonymous_profile](https://github.com/inigolabs/workshops/blob/main/hasura-demo/inigo/service.yml)**

![Figure 14](/uploads/hasura_figure_14_477e8df713.webp)

**Figure 14: [Inigo RateLimit for the anonymous profile](https://github.com/inigolabs/workshops/blob/main/hasura-demo/inigo/rate-limit.yml)**

You can use the inigo CLI to apply these configurations:

**inigo apply -f service.yml**

**inigo apply -f rate-limit.yml**

As shown in Figure 14, a single anonymous client (tracked by IP Address) will only be able to issue 10 queries every 10 seconds. If you are using GraphiQL, it will be easy to prove the rate-limiting works by issuing 11 GraphQL **query** requests within 10 seconds, as shown in Figure 15.

![Figure 15](/uploads/hasura_figure_15_6076a954ba.webp)
**Figure 15: Inigo RateLimit exceeded as shown in GraphiQL in Hasura Console**

## DoS Attack Scenario #2 Mitigation: Inigo Max Height and Depth Limits

By using Inigo’s **Security** configuration, you can apply **max_depth** and **max_height** restrictions to any incoming queries. This effectively prevents any nefarious attacks with deeply nested queries as demonstrated in Scenario #2. A [sample Security configuration](https://github.com/inigolabs/workshops/blob/main/hasura-demo/inigo/security.yml) is shown in Figure 16.

![Figure 16](/uploads/hasura_figure_16_9d0ab9010e.webp)

**Figure 16: Inigo [Security configuration with max_depth and max_height](https://github.com/inigolabs/workshops/blob/main/hasura-demo/inigo/security.yml)**

The configuration as shown in Figure 16 can be applied as such:

**inigo apply -f security.yml**

Using GraphiQL in Hasura, you can attempt to run a deeply nested query, which will fail as shown in Figure 17.

![Figure 17](/uploads/hasura_figure_17_d32cf67cc9.webp)

**Figure 17: Inigo max_depth and max_height exceeded as shown in GraphiQL in Hasura Console**

If we rerun the [**k6** load test for Scenario #2](https://github.com/inigolabs/workshops/blob/main/hasura-demo/k6/nested-query.js) again, you will see that there are over 2000 blocked queries that result from the load test, as shown in Figure 18. To run the load test, here is the command once again:

**k6 run --vus 10 --duration 30s nested-query.js**

![Figure 18](/uploads/hasura_figure_18_2242794938.webp)

**Figure 18: Inigo Analytics showing the Blocked queries after running the k6 load test**

## Conclusion

The community version of Hasura is very powerful and feature rich, but is also vulnerable to DoS attacks as it does not incorporate rate limiting or query protection. While nefarious attacks are possible, even inside of your internal network, unintentional internal DoS scenarios are also possible that can make your Hasura deployment and database unavailable. In other words, you should think twice about deploying Hasura to production without rate limiting and query protection under any circumstances.

Inigo offers a drop-in replacement container image for the community version of Hasura that you can deploy with Docker or Kubernetes. All you need to do is sign up for Inigo, create a basic Inigo service, and deploy Hasura with the Inigo token. You will immediately start receiving query analytics from Inigo, and can then further explore implementing controls for query protection and rate limiting as documented in this article.

For further information, please read our Hasura [documentation](https://docs.inigo.io/product/agent_installation/hasura) and [examples](https://github.com/inigolabs/workshops/tree/main/hasura-demo) for implementing query protection and rate limiting with Hasura.

Hasura + Inigo: How to Prevent a Denial of Service Attack

control_your_graphql_destiny_with_inigo (1).webp

large_control_your_graphql_destiny_with_inigo (1).webp

medium_control_your_graphql_destiny_with_inigo (1).webp

small_control_your_graphql_destiny_with_inigo (1).webp

thumbnail_control_your_graphql_destiny_with_inigo (1).webp

Changes in the GraphQL ecosystem might get you vendor-locked. Controlling your destiny with GraphQL is challenging for various reasons, such as the lack of visibility and security in GraphQL itself. Learn how to manage your GraphQL destiny.

## Overview
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](https://www.apollographql.com/blog/announcement/backend/announcing-the-end-of-life-schedule-for-apollo-gateway-v0-x/), 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.

## Knowledge is Power: Key Measures to Understanding Your Graph
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:

### 1. Overall Utilization of Your Graph, Including Subgraphs
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.

**Actionable Intelligence:**

- What parts of your graph and subgraphs are heavily utilized by your most important API users
- What parts of your graph and subgraphs are underutilized or unutilized
- Where errors are most likely to pop up and why they are occurring
- Where are the major performance bottlenecks, especially when your graph is under a heavy load

### 2. What GraphQL Operations and Sections of Your Graph Are Heavily Used
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.

**Actionable Intelligence:**

- The most executed operations in your graph and how often are they executed
- Sections of your graph, including objects and fields that are the most heavily consumed
- What subgraphs support the most used parts of your supergraph
- What sections of your graph need the most focus and careful planning during a potential GraphQL server or gateway change

### 3. What Areas of Your Graph Are Underutilized or Initialized
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.

**Actionable Intelligence:**

- The operations in your graph that have not been used over the last X number of days
- The least executed operations in your graph
- The least used objects and fields in your graph
- The least used subgraphs
- What underutilized areas of the graph could be deprecated, replaced, or eliminated immediately

### 4. Who is Using the GraphQL API and How They Are Using It
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.

**Actionable Intelligence:**

- Who are the most common users of the most heavily used parts of your graph
- What GraphQL operations your high-priority users are calling daily
- What objects and fields your high-priority users are consuming

### 5. Performance Bottlenecks in Your Graph
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.

**Actionable Intelligence:**

- The average and p95 latencies of the most commonly called operations in your graph
- The heights and depths of the worst-performing queries in your graph
- What users are most impacted by the bottlenecks in your graph
- How many times per day are bottlenecked operations are called
- What subgraphs are causing bottlenecks
- What additional latency the supergraph query planning is adding

### 6. Errors and Hotspots in Your Graph
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.

**Actionable Intelligence:**

- Where, when, and why do errors occur, and how often do they occur
- What users are most impacted by these errors
- Where are hotspots in the graph, such as high p95 latencies that may trigger additional errors, such as timeouts

## Take Action to Control Your GraphQL Destiny
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.:

1. Kick the can by delaying a decision while performing more research and groundwork in the interim. You may be able to negotiate extended commercial support from the GraphQL vendor to buy time.
2. Stay the course with the current open-source GraphQL server or gateway technology and continue forward self-supported for the foreseeable future. Eliminate the proprietary parts of your GraphQL deployment, and consider alternatives to a complete switch out.
3. Switch to a comprehensive SaaS offering like GraphOS to maintain commercial support. Prepare for this to be a multi-year arrangement with vendor lock-in. Try to have an exit plan and avoid proprietary features of the SaaS when possible.
4. Migrate to a different GraphQL vendor that fits your business and technology needs while pricing in the cost of performing the migration. The GraphQL vendor ecosystem is growing and maturing, and new options will be available in the coming months and years. Try to remain agile moving forward.

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.

## Inigo Makes the Journey Possible
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](https://app.inigo.io).

Control Your GraphQL Destiny with Inigo (Don’t Get Vendor Locked)

large_inigo_with_apollo_gateway.webp

medium_inigo_with_apollo_gateway.webp

small_inigo_with_apollo_gateway.webp

thumbnail_inigo_with_apollo_gateway.webp

inigo_with_apollo_gateway.webp

This blog post will go a level deeper on how to implement subgraph visibility with Apollo Gateway. We will walk through the setup of Inigo and what changes need to be made to your Apollo Gateway implementation.

## Overview
In [Subgraph Visibility in GraphQL](https://inigo.io/blog/subgraph_visibility_in_graphql/), we examined Inigo’s subgraph visibility features at a high level. This blog post will go a level deeper on how to implement subgraph visibility with Apollo Gateway. We will walk through the setup of Inigo and what changes need to be made to your Apollo Gateway implementation.

## Why Inigo to Understand Your Apollo Gateway or Router Subgraph?
As we covered in [Subgraph Visibility in GraphQL](https://inigo.io/blog/subgraph_visibility_in_graphql/), there are four basic needs for visualizing and understanding your subgraphs, which are:

1. **Performance monitoring:** It's important to monitor metrics like response times, error rates, and throughput for each subgraph. This allows teams to identify performance bottlenecks and optimize the subgraphs accordingly.
2. **Usage analytics:** Understanding how each subgraph is being used—which fields and types are queried most frequently—helps teams make better decisions about schema design and resource allocation.
3. **Error tracking:** Having visibility into errors at the subgraph level simplifies debugging and troubleshooting. Teams can trace errors back to the source subgraph and subgraph owners have the necessary context to resolve issues.
4. **Security monitoring:** Monitoring security-related metrics for each subgraph, like authentication failures or abnormal usage spikes, helps identify potential vulnerabilities or attacks early on.
Error tracking: Having visibility into errors at the subgraph level simplifies debugging and troubleshooting. Teams can trace errors back to the source subgraph and subgraph owners have the necessary context to resolve issues.
Once you complete the steps to set up Apollo Gateway with Inigo, you can independently apply these capabilities to not only the supergraph but the subgraphs as well.

## GraphQL Gateway Demo Application
There is a [comprehensive guide](https://github.com/inigolabs/workshops/blob/main/apollo-gateway-demo/Readme.md) available on GitHub to walk you through installing and running Inigo with Apollo Gateway, and this blog will summarize the steps.

On your local machine, you should clone the [https://github.com/inigolabs/workshops](https://github.com/inigolabs/workshops) repository. We will be working with the [apollo-gateway-demo](https://github.com/inigolabs/workshops/tree/main/apollo-gateway-demo) subdirectory in this repository. This demo application in this subdirectory contains four microservices, each owning its own part of a federated GraphQL schema. There is an Apollo Gateway implementation that joins the subgraphs into a supergraph that can be easily queried using the Apollo sandbox.

You will likely want to open the [apollo-gateway-demo](https://github.com/inigolabs/workshops/tree/main/apollo-gateway-demo) subdirectory in VS Code. Once there, in the terminal, you should run **npm install** to build the current version of the project before continuing. The microservices can be started with **npm run start-services**, and, in a separate terminal, the gateway can be started with **npm run start-gateway**. The gateway will then be available at **http://localhost:4000**, where you can access the Apollo sandbox. To make sure everything is running correctly, try to execute the following **my_reviewed_products_to_buy_again** query:

```
query my_reviewed_products_to_buy_again {
  me {
    name
    reviews {
      product {
        name
        price
        shippingEstimate
        inStock
      }
      review: body
    }
  }
}
```
You should get a query response as shown in Figure 1:

![use_inigo_with_apollo_gateway_1.png](/uploads/use_inigo_with_apollo_gateway_1_3b4bb17dfd.png)
Figure 1. Results of the **my_reviewed_products_to_buy_again** query in Apollo sandbox

This sample query will exercise all four microservices for this supergraph, which are **accounts**, **products**, **inventory**, and **reviews**. If you would like to know more about the implementation of this demo application, including the subgraph schemas, details are available in the [README](https://github.com/inigolabs/workshops/blob/main/apollo-gateway-demo/Readme.md). 

## Installing Inigo into the Apollo Gateway Demo Application
The [README](https://github.com/inigolabs/workshops/blob/main/apollo-gateway-demo/Readme.md) provides a detailed walkthrough, but here are the basic steps to install Inigo in Apollo Gateway:

1. [Install the inigo CLI](https://docs.inigo.io/reference/cli/)
2. Create a **Gateway** configuration and apply it with the Inigo CLI
3. **npm install inigo-js** and **npm install** the Inigo middleware library
4. Add the **require** imports for Inigo (in JavaScript)
5. Add **InigoPlugin** and **InigoFetchGatewayInfo** to your code

## Apply the Gateway Configuration with Inigo CLI
For Inigo, a **Gateway** configuration is needed to set up the Inigo **Service** for the various subgraphs that your application has. The demo application has a [gateway.yml](https://github.com/inigolabs/workshops/blob/main/apollo-gateway-demo/inigo/gateway.yml) file that contains the following configuration:

```
kind: Gateway
name: apollo-gateway-demo
spec:
  services:
    - name: accounts
      url: "http://localhost:4001/graphql"
    - name: reviews
      url: "http://localhost:4002/graphql"
    - name: products
      url: "http://localhost:4003/graphql"
    - name: inventory
      url: "http://localhost:4004/graphql"
```

This configuration can be applied using **inigo apply inigo/gateway.yml**. For all of the details, once again, please see the [README](https://github.com/inigolabs/workshops/blob/main/apollo-gateway-demo/Readme.md). After this has been applied, you will be able to see the service and its subgraph services in the Inigo UI as shown in Figure 2:

![use_inigo_with_apollo_gateway_2.png](/uploads/use_inigo_with_apollo_gateway_2_ece1d02e15.png)
Figure 2. Supergraph and subgraph services in the Inigo UI

## NPM Module Installations for Inigo
To support the required code changes in the next section, two NPM dependencies must be installed, and it depends on your operating system and CPU. For a Mac with an M1/M2, you would run:

```
npm install inigo.js
npm install inigo-darwin-arm64
```

There are more specific details available in the [README](https://github.com/inigolabs/workshops/blob/main/apollo-gateway-demo/Readme.md).

## Apollo Gateway Code Changes for Inigo
The Apollo Gateway Demo Application [gateway.js](https://github.com/inigolabs/workshops/blob/main/apollo-gateway-demo/gateway.js) has commented code blocks you can uncomment underneath the **//INIGO**: comments within. The main sections that need to be added to support running the Inigo middleware in Apollo Gateway are:

### Includes (gateway.js)
```
// INIGO: Uncomment below:
const { InigoPlugin, InigoRemoteDataSource, InigoFetchGatewayInfo } = require("inigo.js");
```

### CustomRemoteDataSource (gateway.js)
```
// INIGO: use InigoRemoteDataSource instead of RemoteGraphQLDataSource.
class CustomRemoteDataSource extends InigoRemoteDataSource {
  async onBeforeSendRequest({ request, context }) {
    if (context.req && context.req.headers) {
      // pass all headers to subgraphs
      Object.keys(context.headers || []).forEach((key) => {
        if (context.headers[key]) {
          request.http.headers.set(key, context.headers[key]);
        }
      });
    }
  }
  async onAfterReceiveResponse({ request, response, context }) {
    return response;
  }
}
```

### InigoPlugin and InigoFetchGateway Setup (gateway.js)
```
  // INIGO: InigoPlugin must be instantiated before ApolloGateway is started
  const inigoPlugin = InigoPlugin();

  // INIGO: execute InigoFetchGatewayInfo() and use the result as a param for your custom data source
  const info = await InigoFetchGatewayInfo();
```

### Changes for the Apollo Gateway and Server (gateway.js)
```
 const gateway = new ApolloGateway({
    supergraphSdl,
    __exposeQueryPlanExperimental: true,
    // INIGO:
    buildService(service) {
      return new CustomRemoteDataSource(service, info, true);
    },
  });

  const server = new ApolloServer({
    gateway,
    engine: false,
    subscriptions: false,
    // INIGO:
    plugins: [
      inigoPlugin,
    ],
  });
```

## Running Apollo Gateway with Inigo
Using the Inigo token that you obtained while [setting up Inigo](https://docs.inigo.io/), using either the Inigo UI or **inigo create token**, you can now start up Apollo Gateway with the Inigo middleware installed.
```
export INIGO_SERVICE_TOKEN="ey..."
npm run start-gateway
```
Once started, you can return to the Apollo Sandbox again at **http://localhost:4000** and run the **my_reviewed_products_to_buy_again** query (see above) again. Please run this query several times to generate data to view on the Inigo Analytics UI.

## Viewing Supergraph and Subgraph Data in Inigo Analytics
Now that you have Inigo running with Apollo Gateway, and have executed the **my_reviewed_products_to_buy_again** sample query several times, you should be able to see query metrics available on [https://app.inigo.io](https://app.inigo.io) under the apollo-gateway-demo service in the dropdown menu (see the screenshot above).

As shown in Figures 3 to 7, you can navigate to the supergraph and subgraph Analytics from this menu, as highlighted in the red boxes. On each of these screens, you will have an independent view of the analytics that were run against the federated query execution. 

In Figures 3 to 7, you can see how the federated **my_reviewed_products_to_buy_again** GraphQL query is decomposed into separate queries for each of the four microservices, each of which provides its own subgraph as described in the [README](https://github.com/inigolabs/workshops/blob/main/apollo-gateway-demo/Readme.md).

![use_inigo_with_apollo_gateway_3.png](/uploads/use_inigo_with_apollo_gateway_3_f64931f6f1.png)
Figure 3: The supergraph **my_reviewed_products_to_buy_again** query as shown in Inigo Analytics

![use_inigo_with_apollo_gateway_4.png](/uploads/use_inigo_with_apollo_gateway_4_26be6bda09.png)
Figure 4: The **accounts** subgraph query as shown in Inigo Analytics

![use_inigo_with_apollo_gateway_5.png](/uploads/use_inigo_with_apollo_gateway_5_11ec54ddfc.png)
Figure 5: The **product** subgraph query as shown in Inigo Analytics

![use_inigo_with_apollo_gateway_6.png](/uploads/use_inigo_with_apollo_gateway_6_a51bf8d92d.png)
Figure 6: The **inventory** subgraph query as shown in Inigo Analytics

![use_inigo_with_apollo_gateway_7.png](/uploads/use_inigo_with_apollo_gateway_7_b2769551e2.png)
Figure 7: The **reviews** subgraph query as shown in Inigo Analytics

## Next Steps and Conclusion
Now that you have set up and run Inigo with Apollo Gateway, you can further explore the capabilities of Inigo with the supergraph and each independent subgraph. You will gain a deeper understanding of how your subgraphs are being utilized within the context of your supergraph and your Apollo Gateway implementation.

If you’d like to learn more and see a live demonstration of using Inigo with Apollo Gateway, we invite you to attend the upcoming webinars:

July 13th, 9:30 AM PDT, 6:30 PM CET - DONE
July 18th, 5:00 PM PDT, 10:00 AM AEST - DONE

Or [book a session here](https://inigo.io/demo).


How to Use Inigo with Apollo Gateway and Better Understand Your Subgraphs

Subgraph Visibility in GraphQL Header.webp

large_Subgraph Visibility in GraphQL Header.webp

medium_Subgraph Visibility in GraphQL Header.webp

small_Subgraph Visibility in GraphQL Header.webp

thumbnail_Subgraph Visibility in GraphQL Header.webp

While a federated GraphQL schema offers many benefits, including improved developer productivity and the ability to create a more coherent API across multiple teams, it also introduces a few challenges.

## Introduction

The appeal of creating a GraphQL API often lies in its ability to expose a single data graph, which can sit atop multiple data sources, such as REST APIs and SQL databases. This structure allows data to be queried in a way that truly reflects the relationships between the nodes in the graph.

However, as more objects and their relationships are exposed through various types and fields, the graph can quickly become unwieldy. A moderately complex application can rapidly require a vast array of type definitions, making it challenging for multiple people or teams to collaborate on building the API. Additionally, the GraphQL API can become a single vulnerable point of failure in the system.

The solution? A distributed GraphQL architecture. By breaking up the schema into smaller services for development purposes and then recombining each independently managed portion into a Gateway API, client applications can remain oblivious to these divisions when querying data. This approach is particularly valuable for larger, complex applications that necessitate a single, comprehensive API.

Today, a distributed GraphQL architecture is typically referred to as federated GraphQL and implemented via a tool called Apollo Federation. Federated GraphQL has helped companies like [Netflix](https://netflixtechblog.com/how-netflix-scales-its-api-with-graphql-federation-part-1-ae3557c187e2?gi=8bf40bb94882) and [PayPal](https://medium.com/paypal-tech/graphql-at-paypal-an-adoption-story-b7e01175f2b7) scale their GraphQL APIs. 

## Challenges of federated GraphQL

![Subgraph Visibility in GraphQL Gaps.webp](/uploads/Subgraph_Visibility_in_Graph_QL_Gaps_98b30a4822.webp)

While a federated GraphQL schema offers many benefits, including improved developer productivity and the ability to create a more coherent API across multiple teams, it also introduces a few challenges, including:

1. **Schema Coordination**: In a federated architecture, different teams can make updates to their part of the schema independently. This requires careful coordination to ensure that changes made by one team don't break another team's queries. Tools like schema registries and schema validation tools can help with this.

2. **Performance**: The process of splitting a GraphQL schema across multiple services and aggregating the results can add additional latency to the request. The gateway must sometimes make multiple round-trip requests to different services to resolve a single query, which can impact performance.

3. **Error Handling**: Errors can be more challenging to trace in a federated environment. Errors from different subgraphs can become entangled, complicating the debugging process. For instance, a single query could trigger errors in multiple subgraphs, making it hard to isolate and resolve each one. This issue becomes even more severe as the number of subgraphs increases.

4. **Security and Authorization**: Each service in a federated architecture represents a potential point of attack. Ensuring consistent security practices across all services, including data privacy and access controls, is critical.

5. **Testing and Debugging**: Testing in a federated environment can be more complex than in a monolithic one. Testing a change might require setting up a more complicated testing environment that includes the gateway and all the necessary services.

6. **Consistency**: Ensuring a consistent approach across multiple services can be challenging. For instance, different teams might have different naming conventions or different ways of designing their part of the schema.

7. **Resource Allocation**: Conversations about resource allocation - how much memory, CPU, and bandwidth should each subgraph receive - can be difficult without the right tools and data.

Despite these challenges, many organizations find that the benefits of a federated GraphQL architecture outweigh the drawbacks. The key to a successful implementation lies in careful planning, good communication among teams, and the use of appropriate tooling.

## The need for subgraph visibility

![Subgraph Visibility in GraphQL Solution.webp](/uploads/Subgraph_Visibility_in_Graph_QL_Solution_5720b55c70.webp)

Subgraph visibility in the context of a federated GraphQL architecture refers to the ability to observe and understand the individual GraphQL services that make up the federated data graph. This includes things like:

1. **Performance monitoring**: It's important to monitor metrics like response times, error rates, and throughput for each subgraph. This allows teams to identify performance bottlenecks and optimize the subgraphs accordingly.

2. **Usage analytics**: Understanding how each subgraph is being used—which fields and types are queried most frequently—helps teams make better decisions about schema design and resource allocation.

3. **Error tracking**: Having visibility into errors at the subgraph level simplifies debugging and troubleshooting. Teams can trace errors back to the source subgraph and subgraph owners have the necessary context to resolve issues.

4. **Security monitoring**: Monitoring security-related metrics for each subgraph, like authentication failures or abnormal usage spikes, helps identify potential vulnerabilities or attacks early on.  

Subgraph visibility is important because it allows for more effective monitoring, troubleshooting, and optimization of a federated GraphQL API. By improving subgraph visibility, teams can ensure that their federated GraphQL architecture is performant, reliable, and secure.  

## Inigo: A Solution to Enhance Subgraph Visibility

![Subgraph Visibility in GraphQL Inigo.webp](/uploads/Subgraph_Visibility_in_Graph_QL_Inigo_239592c820.webp)

Inigo is a GraphQL monitoring and analytics platform that provides in-depth visibility into subgraphs in a federated GraphQL architecture. Some of the features that improve subgraph visibility include:

- Performance dashboards for each subgraph display metrics like response time, error rate, and throughput. This helps teams quickly identify issues and areas for optimization.
- Usage analytics showing the most frequently queried types, fields, and connections within each subgraph. This data aids in improving schema design and determining how to allocate resources. 
- Advanced error tracking that groups errors by subgraph, making them easier to debug. Subgraph owners have the context to resolve issues efficiently.  
- Automated security monitoring that detects anomalies like spikes in authentication failures or unusual traffic volumes at the subgraph level. Teams get alerts about potential vulnerabilities early.
- Resource allocation recommendations based on usage data. Inigo can suggest ways to optimize how resources like CPU, memory, and bandwidth should be distributed across subgraphs according to demand.  

By providing targeted visibility and insights into each subgraph, Inigo enables federated GraphQL teams to build, monitor, and optimize their API more effectively. Issues that would otherwise be difficult to troubleshoot or anticipate become much more manageable. 

## Conclusion
Subgraph visibility is essential for successfully operating a federated GraphQL API at scale. Without insight into how each subgraph is functioning, issues are nearly impossible to trace and resolve. Inigo is a purpose-built tool for enhancing visibility across federated graphs and overcoming the challenges associated with distributed architectures. 

Try Inigo today to gain transparency into your federated graph. Learn more and get started with a free trial at [app.inigo.io](https://app.inigo.io).



Subgraph Visibility in GraphQL

large_blog_intellyx_platform_innovation.webp

medium_blog_intellyx_platform_innovation.webp

small_blog_intellyx_platform_innovation.webp

thumbnail_blog_intellyx_platform_innovation.webp

blog_intellyx_platform_innovation.webp

We’re proud to announce that the Inigo platform has earned the 2023 Intellyx Digital Innovator Award.

We’re proud to announce that the Inigo platform has [earned the 2023 Intellyx Digital Innovator Award](https://intellyx.com/2023/05/22/inigo-wins-the-2023-digital-innovator-award-from-intellyx/) from enterprise analyst firm Intellyx. The award adds to Inigo’s recent recognition from DevOps.com, in the Best New DevOps Tools Provider category.

As our customers know, Inigo’s solution for end-to-end GraphQL API management and security quickly becomes a must-have toolset. From query production and rate limiting to schema checks and lifecycle management, Inigo is built to accelerate our customers’ GraphQL deployments as efficiency, securely, and cost-effectively as possible.

We’re excited to roll out even more features and capabilities this year, providing a complete one-stop shop for enterprise GraphQL security and management at scale.


Inigo Earns New Analyst Recognition for Platform Innovation

large_1_inigo_aws_appsync_header.webp

medium_1_inigo_aws_appsync_header.webp

small_1_inigo_aws_appsync_header.webp

thumbnail_1_inigo_aws_appsync_header.webp

1_inigo_aws_appsync_header.webp

We are excited to announce Inigo’s integration with AWS AppSync. This integration allows you to add in-depth GraphQL analytics to your AppSync instance in just a few straightforward steps.

We are excited to announce Inigo’s integration with AWS AppSync. This integration allows you to add in-depth GraphQL analytics to your AppSync instance in just a few straightforward steps. 

## The Challenge: Unveiling AppSync to the World

AWS AppSync is a fully managed “GraphQL-as-a-service” platform that abstracts away much of the grunt work involved in building GraphQL APIs. For example, AppSync handles the parsing and resolution of requests as well as the connections to other services, data stores, and APIs.

Developers predominantly use AppSync to quickly and robustly build internal GraphQL APIs, that are then consumed by internal clients within the same network or cloud environment. But sometimes organizations want to turn their internal AppSync APIs into public-facing external APIs. This means making the AppSync GraphQL API endpoint accessible over the internet.

Exposing your API endpoint to the world, so that other applications and users can interact with it, can be nerve-wracking. To do so in a safe, secure, performant way requires that you have more visibility into who is hitting your API, how often, and which parts of your schema can be optimized. 

This is exactly what Inigo provides in our comprehensive GraphQL management platform.

## The Solution: Add Inigo to your AppSync instance

Inigo provides enhanced security and detailed analytics for your AppSync service. With Inigo, you get out-of-the-box features like:

### Query-level inspection and analytics

Inigo’s platform lets you dive deep into individual queries. From the analytics dashboard, you can easily check for high-latency queries and track down specific user bugs.

![2_inigo_aws_appsync_query.webp](/uploads/2_inigo_aws_appsync_query_df4365c643.webp)

### Error breakdowns

On the Inigo dashboard, you’re able to see a breakdown of common errors. You are also able to filter queries based on whether they responded with an error.

![3_inigo_aws_appsync_errros.webp](/uploads/3_inigo_aws_appsync_errros_0d0644571a.webp)

### Performance metrics
Inigo makes it easy to identify resource-heavy or unused objects in your schema.

![4_inigo_aws_appsync_analytics.webp](/uploads/4_inigo_aws_appsync_analytics_d74aeed835.webp)

### Actionable alerts

Inigo automatically surfaces errors in mission-critical objects and mutations and routes them to the appropriate team.

### Access control 
Inigo makes it easy for you to add role-based access control to your AppSync server, by writing declarative config.

![5_inigo_aws_appsync_invalid_access.webp](/uploads/5_inigo_aws_appsync_invalid_access_e70087df62.webp)

### Rate-limiting

Inigo uses object-based rate limiting - counting each query’s requested objects and returned objects against a time frame limit (e.g. 1000 objects per minute). This protects your AppSync server against potential performance degradation while still maintaining flexibility.

Altogether, this information helps ensure that your AppSync API is secure against potential abusers and optimized for production. Finally, Inigo can scale to support the highest volume of GraphQL messages for large enterprises.


## How to connect Inigo and AWS AppSync

### 1. Create an Inigo Service

To create a new Inigo service, head to [app.inigo.io](https://app.inigo.io) and open the service configuration menu under the Settings icon on the top navigation.

![6_inigo_aws_appsync_service_create.webp](/uploads/6_inigo_aws_appsync_service_create_b6aeb85e75.webp)

On the next page, choose the “Docker Standalone” option, decide on a service name and label, and proceed to save the INIGO_SERVICE_TOKEN value for later use.

![7_inigo_aws_appsync_service_type.webp](/uploads/7_inigo_aws_appsync_service_type_2f827746dc.webp)

![8_inigo_aws_appsync_service_name.webp](/uploads/8_inigo_aws_appsync_service_name_84e43838d3.webp)

## AWS Marketplace

### 2. Subscribe to the AWS Inigo Agent

Navigate to the Inigo GraphQL Analytics product page in [AWS Marketplace](https://aws.amazon.com/marketplace/pp/prodview-lmo76xfvzarck). Hit the "Continue to Subscribe" button and accept the terms and conditions. 

On the configuration page, select “Cloudformation stack for AppSync”, and the latest version, from the dropdown menus, then hit the “Continue to Launch” button.

![9_inigo_aws_appsync_marketplace.webp](/uploads/9_inigo_aws_appsync_marketplace_cfdbc4d771.webp)

### 3. Deploy the AWS Agent Stack

Here, you'll only need:

1. The previously stored INIGO_SERVICE_TOKEN
2. Your AppSync GraphQL endpoint and its API Key

Follow the instructions [here](https://docs.inigo.io/product/agent_installation/aws_appsync#aws-agent-stack-deployment) to deploy an AWS agent stack.

At the end of this step, you will have deployed an Inigo agent. You may use the built-in playground or any preferred client to start sending queries.

![10_inigo_aws_appsync_playground.webp](/uploads/10_inigo_aws_appsync_playground_66de0efa20.webp)

After making a few requests, you should be able to see your analytic data with [Inigo’s dashboards](https://app.inigo.io).

![11_inigo_aws_appsync_aws_data_home.webp](/uploads/11_inigo_aws_appsync_aws_data_home_6efd9876d7.webp)

![12_inigo_aws_appsync_aws_data_analytics.webp](/uploads/12_inigo_aws_appsync_aws_data_analytics_65309d0fcf.webp)

## Get started with Inigo and AppSync

Visit [Inigo's documentation](https://docs.inigo.io/product/agent_installation/aws_appsync#aws-agent-stack-deployment) for more information on how to get started adding Inigo to your AppSync instance for powerful GraphQL analytics.

You can [sign up for Inigo](https://app.inigo.io/signup) directly or [schedule a demo](https://inigo.io/demo). The initial setup is free, so you can start gaining in-depth query analytics and performance metrics for your AppSync service without any charge.







NEW: Inigo's integration with AWS AppSync

large_graphql_in_development.webp

medium_graphql_in_development.webp

small_graphql_in_development.webp

thumbnail_graphql_in_development.webp

graphql_in_development.webp

As applications evolve over time, it's essential for their GraphQL APIs to keep pace with these changes.

## Overview

As applications evolve over time, it's essential for their GraphQL APIs to keep pace with these changes. In this blog post, we provide best practices for different aspects of the GraphQL development pipeline, including schema planning, schema checks, and performance optimization.

## Managing schemas

GraphQL was built on the principle that each client should only retrieve the data it requires, effectively addressing the over-fetching issue. This approach anticipates that your API will be consumed by a wide range of clients, so that existing client queries should continue to function properly even as you expand and update your graph.
It’s therefore important to determine which changes are permissible and which might break your schema.

### Handling schema-breaking changes
A schema-breaking in a GraphQL schema is an update that causes the API contract to change in a way that is not backward-compatible. To better understand this concept, let's consider an example.
Imagine you have a simple schema with a single query to fetch a user by ID, which returns a user type containing two fields: id and name. Your business then decides that they want to split the name field into two separate fields: firstName and lastName. You might be tempted to remove the name field and replace it with firstName and lastName, but doing so would break any existing clients relying on the name field.
```
# Original schema
type User {
  id: ID!
  name: String!
}

# Breaking change schema
type User {
  id: ID!
  firstName: String!
  lastName: String!
}
```
Instead, you can make this change in a backward-compatible manner by using the @deprecated directive. This allows you to indicate that the name field is deprecated in favor of the new firstName and lastName fields.
```
# Backward-compatible schema
type User {
  id: ID!
  name: String! @deprecated(reason: "Use firstName and lastName instead")
  firstName: String!
  lastName: String!
}
```
When you need to introduce schema-breaking changes, follow these four steps to minimize their impact: add, deprecate, migrate, and remove. 

![development_flow.webp](/uploads/development_flow_6e6ed8fef3.webp)

In our example, we already added the new fields and deprecated the old one. Now, let's go through the remaining steps:

- **Migrate:** At this stage, it's crucial to update all the clients consuming this API to stop using the deprecated fields and start using the newly added fields. Once this migration is complete, deploy the updated versions of your website and applications.
- **Remove:** Once you're confident that there are no more clients that are using the deprecated fields anymore, you can safely remove them from the schema. In our example, you would remove the name field from the User type and deploy the new version of the API.

How can you be confident that no clients are using the deprecated fields anymore? This is where Inigo’s GraphQL Gateway can help. Inigo highlights the usage of each GraphQL object and tags them by client so you get visibility to your APIs usage in depth.
By providing insights into usage patterns and real traffic data, developers using Inigo are empowered to plan their schema roadmaps effectively. 

### Schema checks

While the example shown above assumes that the developer already knows that adding firstName and lastName can potentially break the schema, in other cases, it’s not so clear. This is where GraphQL schema checks can be helpful. GraphQL schema checks help developers identify and prevent breaking changes in the schema, such as field removals or type modifications.

Schema checks for GraphQL are typically implemented by using tools and libraries designed for this purpose, and then integrating them into your development workflow and CI/CD pipeline. Here's an overview of the process:
1. **Choose a tool or library for schema checking:** there are several popular tools for GraphQL schema checks, such as GraphQL Inspector, Apollo Engine, or Inigo. These tools can compare the current schema with the proposed changes and report any breaking changes or potential issues.
2. **Implement schema checks in development:** during development, use the tool you chose to validate schema changes locally, ensuring that breaking changes are detected early in the development process. Developers can also use these tools to validate queries and mutations against the schema to guarantee their correctness.
3. **Integrate schema checks into your CI/CD pipeline:** add schema checks to your continuous integration (CI) and continuous deployment (CD) pipelines. This can be done using plugins, scripts, or pre-built integrations with popular CI/CD platforms like GitHub Actions, GitLab CI, Jenkins, or CircleCI. Whenever code changes are pushed or pull requests are created, the CI system will automatically perform schema checks and report any issues before the code is merged and deployed.
4. **Monitor and review schema changes:** configure the schema check tool to generate reports, logs, or notifications when breaking changes are detected. This enables your team to review the changes and decide on the best course of action, such as fixing the issue, updating client applications to handle the change, or reverting the change entirely.

Let's consider a scenario where you have an existing GraphQL schema for an e-commerce application, and a developer wants to make changes to the User type. 
Here's the initial schema:
```
type User {
  id: ID!
  name: String
  age: String
  email: String
}
```
The developer decides to change the age field from a String to an Int. They update the schema as follows:
```
type User {
  id: ID!
  name: String
  age: Int # type used to be String
  email: String
}
```
Inigo will alert you to any clients that are still using age as a String.

![illustration_graphql.webp](/uploads/illustration_graphql_e68c9fd0b7.webp)

## Subgraph visibility for different teams 

In GraphQL, subgraph visibility refers to the ability to control access to specific parts of a schema, such as types or fields, based on the client or user's permissions. Managing subgraph visibility is crucial for maintaining data security and privacy in a GraphQL API, as it helps prevent unauthorized access to sensitive data or internal implementation details. To implement subgraph visibility, developers can use a combination of schema directives and custom middleware, such as GraphQL Shield or custom resolvers, to conditionally expose or hide certain parts of the schema based on the client's authorization levels (typically controlled by a security orchestration product).
With Inigo, subgraph visibility is built in.

![dropdown_56.webp](/uploads/dropdown_56_f064d186c4.webp)

## Finding performance issues

### Identifying resource-heavy and/or unused objects in schemas

In GraphQL, identifying resource-heavy queries and types is crucial for optimizing performance and minimizing unnecessary data retrieval. 
Similarly, identifying unused objects is also important, as it can result in unnecessary costs for data sources in terms of lookup and computation.
Identifying these “long-tail” objects typically involves:
1. **Query logging:** Set up logging for your GraphQL server to capture information about incoming queries, including execution time, response size, and any errors. This data will help you identify slow-performing or resource-intensive queries.
2. **Query complexity analysis:** Calculate the complexity of each query. A high complexity score may indicate that a query is resource-intensive and may need optimization.
3. **Monitoring server metrics:** Keep an eye on server metrics like CPU usage, memory consumption, and response time. Spikes in these metrics could signal that certain queries or types are putting excessive strain on your server.
4. **Field usage tracking:** Identify which fields are frequently requested and which are rarely used.

![analytics (1).webp](/uploads/analytics_1_881accdabb.webp)

## Conclusion

The growing adoption of GraphQL in production environments highlights the importance of integrating it seamlessly into the development pipeline. As organizations face new challenges, such as schema planning, schema optimization, query monitoring, and [error handling](https://inigo.io/blog/graphql_error_handling), Inigo provides a valuable solution to what would otherwise be unscalable and costly development cycles. 
Rather than functioning as a GraphQL server, Inigo offers a comprehensive suite of tools designed to contextualize GraphQL traffic, deliver granular query-level analytics, and ensure that dev teams have all the information they need to maintain a clean and efficient schema.





GraphQL in development

large_Expedite Your GraphQL Roadmap.webp

medium_Expedite Your GraphQL Roadmap.webp

small_Expedite Your GraphQL Roadmap.webp

thumbnail_Expedite Your GraphQL Roadmap.webp

Expedite Your GraphQL Roadmap.webp

The enterprise path to full-fledged GraphQL adoption in production —and API modernization at scale—often begins with a single developer or a single API in the journey of digital transformation.

## Overview

The enterprise path to full-fledged GraphQL adoption in production —and API modernization at scale—often begins with a single developer or a single API in the journey of digital transformation.

That developer recognizes the advantages of the GraphQL open source API query language for workflow efficiency, and begins championing it within the organization. If you’re reading this, you may be that champion.

You understand GraphQL’s vast potential to accelerate application development and expedite roadmaps. You’re the one telling every colleague you can how GraphQL allows applications to collect all required data within a singular API request, and how GraphQl can do that with speed and control that REST APIs can’t match.

If you find yourself in this champion role, however, you may have also already encountered a few all-too-common roadblocks to your ideal GraphQL adoption roadmap. For those newer to GraphQL, here are some obstacles you might come across—and how to navigate them.

## Obstacle #1 for GraphQL champions: the myth that “GraphQL is not mature enough for enterprises”

First of all, starting out with GraphQL isn’t the hard part. Developers can deploy a GraphQL server and get going pretty darn easily. The harder challenge is winning organizational buy-in and standing up a stable, secure, and enduring enterprise-grade implementation.

An early obstacle to enterprise GraphQL adoption—which its champions must address head-on—is the perception that it isn’t ready for primetime. Skeptical stakeholders within your organization may claim that GraphQL isn’t mature enough for enterprise use cases. If you deploy GraphQL in a haphazard and unsustainable manner that also makes it an easy target for hackers, you’re all but doomed to failure. It’s dangerous to the future of GraphQL at your organization if you end up making the skeptics look like they’re right. That’s why it’s crucial it deploy GraphQL with a strong and secure foundation from day one. And that’s completely doable.

The truth is that GraphQL is mature enough for production in large enterprises and is already deployed in large production environments across the biggest and most data-intensive companies in the world (Meta, Rakuten, PayPal, Lyft, KLM, Starbucks, Shopify, the list goes on). Champions can answer skeptics by demonstrating that enterprise-grade, purpose-built GraphQL tooling and expert support are available to guide a seamless deployment and allow the development team to hit the ground running toward their GraphQL goals. This is why we built Inigo; our one-stop-shop GraphQL management gateway eliminates the learning curve to managing a secure enterprise GraphQL deployment.

## Obstacle #2 for GraphQL champions: the myth that it’s “too early to add enterprise support”

It’s a frustrating catch-22 for champions: while some skeptics accuse GraphQL of not being enterprise-ready, other stakeholders will say it’s too early to invest in GraphQL management, security, and support because the organization has yet to use it much. 

Champions need to deliver this message: it’s never too early to apply GraphQL best practices and doing so from the beginning pays dividends in the long term. Implementing best practices in a greenfield environment means fully benefitting from efficient operations, secure access control and visibility, granular analytics and BI insights, schema planning, API lifecycle tools, and an improved developer experience from the start. In contrast, aligning brownfield deployments with GraphQL best practices often means fixing thorny legacy issues—such as access controls hard-coded into servers and resolvers—which can be harder to deal with. You would never hear that it’s too early to use Jira in the development process. it’s given that you want everything there from day one. Similarly, the sooner an enterprise starts with GraphQL best practices for workflow management and security, the easier it is to operate and scale, and the more inisghts you have to optimize your schema and design things right from the start. 

## Explore Inigo

GraphQL champions know that their enterprises are ready to harness GraphQL, and that they should highlight the right complementary tooling to help make their case and convince stakeholders. With Inigo, enterprises gain the visibility to operate GraphQL seamlessly, and the security to operate it safely and with confidence. The Inigo platform also removes obstacles to GraphQL adoption, eliminating unknowns to make migration quicker and easier while expediting GraphQL’s (many) benefits.

## Developers Use Inigo for: GraphQL Visibility
 
![Developers Use Inigo for GraphQL Visibility.webp](/uploads/Developers_Use_Inigo_for_Graph_QL_Visibility_c048c5d015.webp)

Seeing is believing, and visibility into GraphQL data is critical to ensure success and find any issues before they become…big issues. For both at-a-glance visibility into GraphQL deployments and granular deep dives, the Inigo platform delivers. A health dashboard details any server error breakdowns, with a complete view of service and subgraph states. The dashboard is built to enable developers to take quick action when needed.
 
While standard monitoring tools overlook GraphQL query insights—and the valuable business intelligence those insights hold—the Inigo platform is built for query-level analytics. Developers get a uniquely in-depth understanding of their GraphQL usage (at scale) through detailed insights into the field level, query paths, and server health, among other metrics.

## Developers Use Inigo for: GraphQL Planning
 
![Developers Use Inigo for GraphQL Planning.webp](/uploads/Developers_Use_Inigo_for_Graph_QL_Planning_a96a246340.webp)

Inigo takes the guesswork (and time) out of GraphQL planning. Straightforward schema navigation enables developers to quickly identify, review, and share schema version differences, and also flag any deprecated and tagged fields. The platform’s heatmap of GraphQL usage—with real traffic data—is critical for gathering unique BI that drives more effective and efficient planning.
 
As the API lifecycle progresses, Inigo gives developers the tools they need to be well-prepared for schema changes and field deprecation with absolute minimal (and often zero) impact to the customer experience. Inigo’s gateway inspects changes and compares them against real traffic, instantly alerting developers to any API outages.

## Developers Use Inigo for: GraphQL Security
 
 
![Developers Use Inigo for GraphQL Security.webp](/uploads/Developers_Use_Inigo_for_Graph_QL_Security_9f121c3a21.webp)

All of GraphQL’s productivity, developer experience, and availability gains fall apart if security can’t keep up. Inigo protects GraphQL environments from spec abuse with query-level protections that thwart DoS attacks and provide real-time protection against data tampering, malicious traffic, and slow (or unresponsive) API responses.
 
Object-level rate limiting is critical for GraphQL security, and Inigo achieves this by counting each query’s requested objects and returned objects against a time frame limit (such as 1000 objects per minute). Developers using object-based rate limiting know that their servers will be protected against potential performance degradation while still allowing for flexible and efficient API use.
 
Lastly, one of the biggest developer misconceptions around GraphQL security is that you need to disable introspection. [You don’t](https://inigo.io/blog/you-dont-need-to-disable-introspection). Inigo’s schema-based access control is built with introspection separation, so access control can be completely enforced at the edge. Users only get schema visibility to pre-allowed operations, types, and fields.
 
## Is Inigo right for me?
 
Because Inigo uses a traffic-based pricing model and costs nothing to install, champions can explore Inigo and demonstrate its benefits on dev environments practically for free. Champions should also showcase how Inigo delivers a huge ROI by eliminating the need to hire top-tier GraphQL talent. With Inigo, there’s no need for enterprises to wait to deploy GraphQL, no huge budget expenditures, and no need to hire in-house experts to take advantage of an expertly managed and secured GraphQL deployment.


Expedite your GraphQL roadmap by making it enterprise-ready from day one

Harnessing Materialized Views and ClickHouse for High-Performance Analytics

large_Harnessing Materialized Views and ClickHouse for High-Performance Analytics.webp

medium_Harnessing Materialized Views and ClickHouse for High-Performance Analytics.webp

small_Harnessing Materialized Views and ClickHouse for High-Performance Analytics.webp

thumbnail_Harnessing Materialized Views and ClickHouse for High-Performance Analytics.webp

Harnessing Materialized Views and ClickHouse for High-Performance Analytics.webp

In this post, we share our findings after loading billions of rows of data and conducting measurements.

## Overview
At Inigo, we were seeking a database solution that could handle a high volume of raw data for analytics. After exploring various alternatives, including SQLite, Snowflake, PostgreSQL, we decided to experiment with Materialized Views using ClickHouse on a relatively slow machine. In this post, we share our findings after loading billions of rows of data and conducting measurements.

## Database Alternatives Considered
Before arriving at ClickHouse, we tried several other databases:
1. Snowflake - too slow and costly for our needs. While it performs well for processing in-house data, it becomes quite expensive when handling real-time customer data within a product, which negatively impacts the product's unit economics. The lack of a local Snowflake emulator further complicates development, as it prevents running continuous unit tests against the database. Additionally, the user interface did not align with our preferred database usage. Since each service had its own separate table, we had to obtain and hardcode table names in the UI. This made it impossible to retrieve data from all tables using a single query in the user interface.
2. PostgreSQL - An excellent database, but its transactional nature made it unsuitable for large analytic workloads. We were able to get it to work with around 100K rows, but past that, the indexes were growing out of control and the cost of running a Postgres cluster didn’t make sense.

## What is ClickHouse?
Clickhouse is a columnar database specifically designed to handle high volumes of data while providing fast query execution. Materialized views in Clickhouse serve as pre-aggregated datasets that can significantly improve the performance of analytical queries. Furthermore, Clickhouse's ability to automatically manage and update materialized views as new data is ingested simplifies the maintenance process, making it an attractive choice for those seeking an efficient and powerful analytical database solution.

## Why Clickhouse
We ended up choosing Clickhouse for its general high performance, ability to handle large scale, and ability to run it locally for testing purposes.

## Inigo’s ClickHouse Setup
Our current ClickHouse setup is a single database where nearly every Inigo service has its own table, with some tables containing billions of rows of data. It runs on 4 vCPUs, 32GB RAM for the development environment and 16 vCPUs, 128GB RAM for the production environment. 
Setting up ClickHouse was challenging, as understanding the nuances of each index, sharding, and materialized views required considerable effort. However, the end result has been a system capable of loading and querying vast amounts of analytics data in a scalable manner, both in terms of hardware cost and engineering development time.

## Materialized Views in ClickHouse
Given that we have billions of rows in some of our raw tables, we strive to minimize joins whenever possible. Instead, we have consolidated the data into several materialized views, each grouping the data into distinct time window buckets. As a result, most of the time, we are querying thousands of aggregated rows instead of millions of raw data rows, resulting in faster real-time filtering.

### Creating materialized views
Our raw tables all contain a timestamp column observed_at.
We then aggregate the data rows into specified intervals for the materialized tables. For example, if the interval is 1 minute, we use the toStartOfInterval(observed_at, INTERVAL 1 minute) function to aggregate data into one minute intervals. Each row in the materialized views contains several raw data values, all corresponding to a particular minute based on the observed_at column.
By creating materialized views with different intervals, such as 6 minutes, 40 minutes, and 3 hours, we can further enhance query performance and enable more efficient data analysis across various timeframes.

We exclude all columns containing unique data, such as trace_id, from materialized views. When we need to filter by trace_id, we query the raw data. It is worth noting that raw data queries are reasonably quick in Clickhouse, as Clickhouse can efficiently sift through a large number of rows in real-time using the appropriate index for each column.

### Grouping data
In our analytics, we primarily use grouped queries to obtain data. Standard queries and materialized view queries use the same SQL files, but there is a slight modification in the way they handle counting. Instead of using count(1) to count the rows, materialized view queries use sum(calls) with a derived column named calls. The column calls is created by using count(1) as calls in the materialized view definition. This change allows us to aggregate the count of rows from the materialized view, resulting in more efficient querying and better performance.

### Merge and State Suffix
In Clickhouse, the State and Merge suffixes are used with aggregation functions to handle intermediate aggregation states and merge them efficiently. These suffixes are particularly useful when working with distributed databases or when we need to combine aggregated results from multiple sources.

- The State suffix: The aggregation functions with the State suffix return an intermediate aggregation state rather than the final result. These intermediate states are stored in a compact binary format that represents the aggregation in progress.

For example, if we want to calculate the 95th (0.95) and 99th (0.99) percentiles of a column called server_process_time, we can use the quantilesState(value) function. This function returns the intermediate state of the quantiles calculation, which we can store in a separate table or combine with other intermediate states.

- The Merge suffix: The aggregation functions with the Merge suffix take the intermediate aggregation states produced by their corresponding State functions and merge them to produce the final aggregation result. This is useful when we have multiple intermediate states that we need to combine into a single aggregated result.

For instance, to obtain the 99th percentile of the aggregated server_process_time, we would use quantileMerge(0.99)(quantiles_server_process_time), where quantiles_server_process_time is the intermediate state resulting from the quantilesState function.

## Results
By leveraging Materialized Views and ClickHouse, we achieved the following:

1. The database is now faster than our Golang code, allowing us to use pooling and improving our UI responsiveness.
2. Confidence in query speed, enabling us to identify issues outside the database, such as in tracing extensions.

The scalability of this solution depends on various factors, including the scaling setup. ClickHouse officially offers a cloud service with 720 GiB RAM, 180 vCPU, and 10 TB of data, indicating its potential for handling significant workloads. However, we have been able to easily scale to 1B rows and still growing.

## Conclusion
While ClickHouse does have limitations, such as the absence of transactions and potential inaccuracies in Materialized Views, these drawbacks are minor for our analytics use case. Overall, ClickHouse, when paired with Materialized Views, has proven to be an excellent solution for handling large-scale analytics data with impressive performance and scalability.


Are Your Developers Using GraphQL Without Your Knowledge.webp

large_Are Your Developers Using GraphQL Without Your Knowledge.webp

medium_Are Your Developers Using GraphQL Without Your Knowledge.webp

small_Are Your Developers Using GraphQL Without Your Knowledge.webp

thumbnail_Are Your Developers Using GraphQL Without Your Knowledge.webp

Your organization could be running GraphQL right now…and you might not even know it.

## Overview
Your organization could be running GraphQL right now…and you might not even know it. As a platform lead responsible for optimized operations, or a security operations person responsible for security of the environment, that’s not exactly a sleep-well-at-night scenario. It’s relatively simple for a lone developer to deploy GraphQL and, while you have no idea it’s happening, they almost certainly have no idea how to manage and secure GraphQL APIs.

Developers tend to prioritize efficiency and speed over security. These priorities have been the main drivers of GraphQL adoption (see, for example, [PayPal’s GraphQL adoption story](https://medium.com/paypal-tech/graphql-at-paypal-an-adoption-story-b7e01175f2b7)). The reasons are clear: GraphQL enables faster release of new versions to clients, easier API integration, easier testing, and an overall better developer experience. But while GraphQL increases developer productivity and improves end-user experiences, it is also a paradigm shift for platform teams who must ensure security and availability. 

Developers’ priorities frequently conflict with those of platform teams. That’s not unique to GraphQL, but the difference is that when that happens with GraphQL, your existing web application gateway or other gateways won’t raise a red flag. A GraphQL server offering paths for attackers to expose data, or loading extremely resource-heavy burdens on your platform, could already be running and you would not know it because you will only see “200 OK” response codes (see why in our blog on [GraphQL error handling](https://inigo.io/blog/graphql_error_handling)). 

Should you be worried about using GraphQL? Not at all, if you have the right tools and safeguards in place: deep analytics, tight access controls, and granular visibility into how GraphQL APIs use your resources. Without these, you cannot guarantee your SLAs and you certainly cannot meet compliance requirements because your GraphQL APIs would be exposed to [injection attacks](https://inigo.io/blog/graphql_injection_attacks), [vulnerabilities](https://inigo.io/blog/analysis_of_public_graphql_vulnerability_reports), and other kinds of attacks we discuss in other [blogs](https://inigo.io/blog). 

GraphQL rewards organizations that implement best practices and place controls as early as possible. Getting GraphQL management and security right within a greenfield environment is far simpler than undoing hardcoded mistakes in legacy deployments later. It’s why we’ve built out all the GraphQL-specific capabilities required for platform teams and developers to benefit from a secure, resource-efficient, easily scalable GraphQL deployment from the start (and the visibility to know if your developers have, well, started without you).

Platform teams managing GraphQL should have these capabilities in place from Day One, or as soon as possible:

## Access control

GraphQL access control is an essential Day One feature, but requires strategy and forethought. Going down the wrong path can lead to hairy situations, such as introducing overly-specific code inside resolvers and servers that becomes a challenge to remove. Deploying Inigo’s solution to get access control right from the start means avoiding major headaches in the future. 

Many platform teams are also led astray by the [false advice to disable introspection](https://inigo.io/blog/you-dont-need-to-disable-introspection). Inigo’s schema-based access control features RBAC introspection separation to enforce access control at the edge and limits users’ visibility to the correct operations, types, and fields. GraphQL resolvers stay clean and tight, with complex code logic replaced by easily managed role-based declarative configurations. Query-level audit trails, data leak protection with PII detection, and remediation alerts ensure proper governance that aligns with compliance mandates.

## Schema planning

GraphQL schema planning must be part of the development and API lifecycle from the onset in order to identify errors and protect against production failures that would cause degradation in service levels (and put SLA commitments at risk). Optimized schema planning is key not only to guaranteeing SLAs and reducing costs, but to the broader goals of API modernization. Using GraphQL without proper schema planning could results in poor results, causing your management to assume that GraphQL isn’t mature enough, rather than supporting your team in the process. Inigo’s enterprise-grade tools solve this issue by equipping platform teams and developers with access to real traffic usage data and unique business intelligence—enabling strong foundational and future schema planning. Teams see all their APIs and all the queries in depth, for ongoing control and schema optimization. 

## Federated subgraph visibility

If GraphQL does take root in your organization—but grows into a brownfield deployment with a federated graph before the platform team implements the right visibility tooling—you’ll need some extra help. A federated graph combines multiple subgraphs to expose a singular data graph via an API. Unfortunately for unprepared organizations, reaching this point means that the platform team has no visibility into what traffic goes to which subgraph within this federated architecture. When an issue occurs, such as slow performance or resource-gobbling server behavior, the team can’t see the cause or have the right information for resource allocation discussions. Tapping Inigo provides a clear breakdown of the resources, data, and load among federated subgraphs, making it simple to sort out otherwise painful issues.

## Help your developers help themselves

For platform teams, developers that lack the tools to solve their own issues can be the biggest nightmare of all. Providing each developer with well-configured access control to address their own needs keeps issues off of the platform team’s plate. At the same time, powerful visibility allows platform teams to quickly solve any issues they do need to address. With Inigo, platform teams can eliminate friction with dev teams and ease the organizational learning curve toward secure and optimized GraphQL adoption, applying expertise from day one without needing to become GraphQL experts.


Are Your Developers Using GraphQL Without Your Knowledge?

large_API Gateway are blind to GraphQL.webp

medium_API Gateway are blind to GraphQL.webp

small_API Gateway are blind to GraphQL.webp

thumbnail_API Gateway are blind to GraphQL.webp

API Gateway are blind to GraphQL.webp

Rediscover your GraphQL API Experience: Learn how GraphQL breaks free from traditional API Gateways.

## Overview
For those coming from the world of REST/HTTPs APIs, GraphQL’s error handling paradigm can feel undisciplined and inconsistent. **Unlike in REST/HTTP APIs, where error handling is based on status codes returned by the API, GraphQL request are always made using the same `/graphql` url and always return a 200 OK response**. Instead of being signalled via status codes, errors reside inside the response payload, alongside any data returned.

This makes GraphQL error handling a blind spot for most engineers and security teams. Standard WAFs will generally only look at HTTP headers; thus with GraphQL they are unable to contextualize and differentiate between:

- Successful calls 
- Server errors
- Rate limiting
- Operation errors
- Authorization errors
- Subgraph owner

Additionally, there is little visibility when mission-critical objects and mutations, like purchase orders, fail. In this blog post, we cover some of the top problems with GraphQL’s default error handling, some best practice solutions, and how Inigo can help elevate GraphQL errors so they are quickly handled by the proper team.

## Error Handling in GraphQL
GraphQL is transport agnostic, which means that it does not rely on the underlying transport mechanism used to transmit data between the client and the server. GraphQL APIs can use Web Sockets instead of HTTP for client-server communication if it suits the use case. As a result, GraphQL APIs do not rely on HTTP methods like GET, PUT, and POST, nor are HTTP status codes relevant. 

In GraphQL, errors are returned as part of the server responses from the server. When an error occurs, the server returns a response with an `errors` field that contains information about the error. Clients can determine whether the request was successful or not by looking at this errors field. 


### Example 1:
Here is an example of a GraphQL response with an error:
```
{
  "data": {
    "createUser": null
  },
  "errors": [
    {
      "message": "Email already in use",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ],
      "path": [
        "createUser"
      ]
    }
  ]
}
```

In the above example, the errors field in the response is an array of errors. Each error contains  three fields:

- **Message:** Provides a description of the error
- **Location:** Indicates where in the query the error occurred
- **Path:** Indicates which field in the query caused the error

In this case, the error message "Email already in use" indicates that the email address specified in the `createUser` mutation is already in use by another user.

In addition to the above three fields, there is an `extensions` field that can be used to add extra information about the error.

### Example 2:
The following mutation should result in the creation of a user:
```
mutation {
  createUser(name: "XYZ", email: "xyz@abc.com") {
	  name, 
	  email,
	  password
  }
}
```

The mutation results in the following response:
```
{ "errors": [ {
  "message": "Cannot query field \"password\" on type \"User\".", 
  "locations": [ { "line": 5, "column": 6 } ], 
  "extensions": { 
    "code": "GRAPHQL_VALIDATION_FAILED", 
    "stacktrace": [ 
      "GraphQLError: Cannot query field \"password\" on type    \"User\".", " at Object.Field (/my_project/node_modules/graphql/validation/rules/FieldsOnCorrectTypeRule.js:48:31)", " ...additional lines..." 
      ] 
  } 
} ] }
```

Note that the path element is missing from the error object because, unlike the error in Example 1, this error is raised before execution. These are commonly referred to as request errors, and they include parsing and validation failures. Since this mutation was run on an Apollo server, the error extensions are specific to Apollo’s implementation. These may be different when using other GraphQL implementations. 

## Problems with GraphQL's Error Handling
As you can see, GraphQL's error-handling mechanismis substantially different from how we are accustomed to dealing with errors. As a result, GraphQL error handling presents several challenges:

### Difficult to parse
A GraphQL response may contain both data and errors. The presence of errors does not imply the absence of data. In the absence of errors, the errors key is absent from the response.

In the following snippet, for example, if you merely parse the errors key and assume the entire response is erroneous, you will miss out on the partial data returned.
```
{
  "data": {
	  "user": {
	      "name": "Inspector Spacetime",
	      "userFriends": [{
		      "id": 1,
		      "name": "Constable Reggie"
	      }, {
		      "id": 2,
		      "name": null
	      }]
	  }    
  },
  "errors": [{
	  "message": "Could not fetch name of friend "
	  "locations": [{
		  "line": 2,
		  "column": 5
	  }],
	  "path": [
	  "user", "userFriends", 1, "name"
	  ]
  }]
}
```
### No standard format
Different GraphQL implementations might report errors in different formats, or utilize different error-handling conventions, making it difficult for a standard API gateway to parse.

The following is an erroneous response for failed validation in Hasura:
```
{
 "errors": [{
    "extensions": {
    "path": "$.selectionSet.users.selectionSet.name",
    "code": "validation-failed"
   },
   "message": "field \"name\" not found in type: 'users'"
 }]
}
```
The following is an erroneous response for failed validation in Apollo:
```
{ 
 "errors": [{ 
	"message": "Cannot query field \"name\" on type \"User\".",   
	"locations": [{ 
	 "line": 2, 
	 "column": 3
	}], 
	"extensions": {
	 "code": "GRAPHQL_VALIDATION_FAILED", 
	 "exception": { 
	   "stacktrace": [
	      "GraphQLError: Cannot query field \"name\" on type \"User\".", "...additional lines..." 
	    ]} 
	} 
}], 
"data": null 
}
```
It's always a good idea to consult the documentation for the specific implementation you are using for more information on error handling.

### Hard to differentiate

A GraphQL response may be the result of many requests to distinct data sources. Certain fields may fail due to a lack of authorization, while others may fail due to faulty validation, and we may only obtain a partial response for the remainder. The `errors` list might contain a wide range of errors, making it difficult for the client to handle and respond.

Here's an example of multiple errors being returned in response to a query:
```
{
  "errors": [
    {
      "message": "The provided argument value '9999999999' is invalid for the input argument 'id' on field 'node' of type 'ID'.",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ],
      "path": [
        "query",
        "node"
      ],
      "extensions": {
        "code": "GRAPHQL_VALIDATION_FAILED",
        "field": "id"
      }
    },
    {
      "message": "Access Denied",
      "locations": [
        {
          "line": 6,
          "column": 3
        }
      ],
      "path": [
        "query",
        "customerAccessTokenCreate"
      ],
      "extensions": {
        "code": "ACCESS_DENIED"
      }
    }
  ]
}
```
In this example, the HTTP status code is 200 OK, but the response body includes two error objects in the errors key. The first error object indicates that the provided value for the "id" argument on the "node" field is invalid. The second error object indicates that access was denied when attempting to create a customer access token.

### No prioritization of business-critical errors
This last example demonstrates how multiple errors might be returned in a GraphQL response. In addition to being difficult to distinguish, multiple errors are also difficult to prioritize.  

In some cases, a `data not found` error may be for a single item in the list, which may not affect the client and would be safe to disregard. In another scenario, even if partial data is received, it might make sense to regard the full response as erroneous. Prioritizing distinct error types and creating a hierarchy is therefore difficult to accomplish with GraphQL. It is also important to be able to distinguish and prioritize handling of business-critical errors, for instance, those involving payments.

### Disclosure of sensitive information
Field recommendations in the error message may reveal sensitive information or expose unexpected functionality that is not intended to be utilized by clients, such as fields that allow clients to manipulate resources or execute arbitrary code. This information might then be used in “fuzzing” attacks executed on the server.

The following is a query that requests product categories:
```
query {
    searchCategories {
        name
        description
    }
}
```
The server returns the following response:
```
{
	"errors": [
    	{
            "message": "Cannot query field \"searchCategories\" on type \"Query\". Did you mean \"searchUsers\" or \"searchRoles\"?",
            "locations": [{
            		"line": 144,
            		"column": 3
			}]
		}
    ]
}
```
The response reveals functionality and exposes sensitive information to the client, thus putting the application (and data) at risk.

### Hard to debug errors in subgraphs
A federated GraphQL architecture refers to a way of organizing a GraphQL API as a network of independent GraphQL services that work together to provide a single, unified GraphQL API. Each of the independent GraphQL APIs are known as subgraphs. A router API is exposed to the client in such an architecture and requests are routed by the router to the subgraph that can resolve the query or fields of the query.

![API Gateway are blind to GraphQL Federated](/uploads/API_Gateway_are_blind_to_Graph_QL_Federated_3674bebe0a.webp)

In the context of error handling, a federated GraphQL architecture can be confusing. Each service subgraph may return different error messages, making it more difficult to understand the overall context of the errors and their relationships to the original queries.

For example, let's say we have two subgraphs - customer subgraph and a product subgraph, and there is an error while querying a customerInfo field. The following is a snippet of the error received:
```
{
  "errors": [
    {
      "message": "Internal server error",
      "path": ["customerInfo"]
    }
  ]
}
```
This error message provides very little information about what went wrong and why the user is unable to retrieve their customer information. In some cases, tracing an error like this in a subgraph can be very time-consuming and require a deep understanding of the underlying architecture. 

## Best Practices for Error Handling
Error handling and debugging may be difficult for GraphQL APIs, but there are industry-wide practices and approaches that can help us deal with them more effectively. Some of the solutions to the problems we discussed above are as follows:

### Write custom error handling middleware
Since all errors in GraphQL result in a 200 status code, in order to provide “HTTP-readable” errors to the client, a developer might write custom error handling middleware that intercepts all errors before they are returned to the client. This middleware categorizes each error based on its type and then translates it into a readable error message.

The following is an example of custom error handler for a GraphQL server:
```
customErrorHandler = (err, req, res, next) => {
 const error = formatError(err);
  const { message, locations, path, extensions } = error;

  let statusCode = 500;
  let errorType = 'INTERNAL_SERVER_ERROR';
  let errorMessage = 'Internal server error. Please try again later.';

  if (extensions && extensions.exception) {
    const { name } = extensions.exception;

    if (name === 'ValidationError') {
      statusCode = 400;
      errorType = 'VALIDATION_ERROR';
      errorMessage = 'Invalid input. Please provide valid data for the following fields:';
    }
  }

  const response = {
    errorType,
    message: errorMessage,
    locations,
    path,
  };

  res.status(statusCode).json(response);
};

const app = express();
app.use('/graphql', graphqlHTTP({
  schema,
  rootValue,
  customErrorHandler,
  graphiql: true
}));

app.listen(4000, () => {
  console.log('Running a GraphQL API server at localhost:4000/graphql');
});
```
This middleware intercepts GraphQL errors and categorizes them based on their name. In addition to categorization by name, you can also categorize them by:
- **Error location:** You can categorize errors based on where they occurred in the query or mutation. For example, you can categorize errors by the name of the field or argument that caused the error. 
- **Error severity:** You can classify errors based on their severity level, such as critical errors that prevent the server from processing the request, or non-critical errors that don't affect the functionality of the application.
- **Error source:** You can categorize errors based on their source, such as server-side errors or client-side errors. This can help you identify whether the error was caused by your server, your client, or a third-party service.
- **Error type:** You can classify errors based on their type, such as validation errors, authorization errors, or input errors.

You can also write custom error handlers to hide native GraphQL error messages that should not be seen by the client. For example, error messages in GraphQL often contain field suggestions which might be exploited later:
```
{
  "errors": [
    {
      "message": "Cannot query field \"hellooo\" on type \"Query\". Did you mean \"hello\"?",
      "locations": [
        {
          "line": 33,
          "column": 3
        }
      ]
    }
  ]
}
```
These sorts of error messages can be masked via a custom error formatting function as below:
```
const customFormatErrorFn = (error) => {
 if (error.message.startsWith("Cannot query")) {
   return {
     message: "Invalid request"
   };
 }
 return error
};
```

### Treating errors as data

An alternative to the custom middleware approach is to use the “data as errors” approach. In the “data as errors” approach, error handling is baked into the GraphQL schema. You define different response types for when a response is successful and when it’s not. For example, say we are designing a GraphQL API for fetching books for a library catalog:
```
type Book {
   id: Id!
   title: String! 
}


type NotFound
{
   message: String!

}

type Overdue
{
    message: String!
    lateFee: Float
}
```
You can use a **union type** to represent all possibilities of the response:
```
union BookResult = Book | NotFound | Overdue

type Mutation {
  bookResult(id: Id!): BookResult
}
```
A client may then query for books based on the different states returned by the book result:
``` 
{
 bookResult(id: 1) {
   __typename
   ... on Book {
     id
     title
   }
   ... on NotFound {
     message
   }
   ... on Overdue {
     message,
     lateFee
   }
}
```
By modeling the errors in the schema itself, you leave it to the client handle the ones that are important.

### Disable debug mode in production

Dev Mode, supported in some GraphQL implementations but not all, provides a lot of helpful information for developers during the development and testing phase, such as detailed error messages and a comprehensive list of available fields and arguments. However, it is generally recommended to disable dev mode in production since it can expose sensitive information about your GraphQL API, such as the structure of your database, server configuration details, and API keys, to potential attackers. 

### Avoiding leakage of sensitive information through errors
It is recommended to limit the amount of information returned in error messages and include only the minimum amount of information necessary to identify the error and help developers debug it. You’d certainly want to avoid including sensitive information such as database queries, user information, or system configuration details.

### Configuring proper alerts and triggers for mission-critical business errors
Several critical business errors, if not rectified, have the ability to completely derail the system. Purchase orders, for example, are mission-critical objects and mutations that cannot fail, and when they do, unless there is sufficient error escalation and alerting in place, these mistakes might be missed, delaying redressal. In such situations, it is crucial that an event is triggered to alert the team responsible immediately.

### Improve traceability for subgraphs
It is best practice for each subgraph to log errors to a centralized logging system that aggregates logs from all the subgraphs. You can use log aggregation tools that provide error alerts and analysis to help you identify trends and patterns. It is also important to set up monitoring and have alerts configured to notify subgraph teams when an error occurs. It is critical to offer an internal key to the subgraph without disclosing too much information externally.

## How Inigo can help
Companies are increasingly implementing GraphQL in their production environments. With this growth comes a new set of challenges, including how to secure GraphQL, analyze blind spots, and gain visibility into GraphQL traffic and errors. This is where Inigo comes in.

Inigo is not a GraphQL server. Instead, it offers a comprehensive set of tools to contextualize GraphQL traffic, provide granular query-level analytics, and elevate errors to the appropriate team. 

For example, on the Inigo dashboard, you’re able to see all of the queries and errors coming into and going out of your GraphQL setup. These errors are likely returning a 200 status code, which means that if you're using a standard API gateway, you have little visibility into them.

![Top Errors.webp](/uploads/Top_Errors_18fcca0bf1.webp)

You’re also able to filter queries based on whether they responded with an error:

![Explore queries with errors.webp](/uploads/Explore_queries_with_errors_64e01a0040.webp)

These errors are categorized/labeled, and you can dig into them:

![Explore Detailed Query.webp](/uploads/Explore_Detailed_Query_121d4e085c.webp)

Additionally, Inigo makes it easier to implement GraphQL error handling best practices, for example, by blocking errors that contain PII, or by allowing users to automatically configure alerts that will escalate business-critical errors to responsible parties via Slack or email.

Finally, in the case of multiple errors, Inigo provides subgraph visibility. In a federated GraphQL system, when you get an error, you might not know which subgraph that error comes from. With Inigo, you can dive into specific subgraphs to explore the errors:

![Subgraph Analytics.webp](/uploads/Subgraph_Analytics_1b83597c7d.webp)

## Conclusion
Error handling is a key component of API development. For GraphQL APIs in particular, error handling requires careful thinking and design. You can learn more on why defending GraphQL APIs is challenging for security engineers [here](https://inigo.io/blog/what_makes_defending_graphql_apis_is_challenging_to_security_engineers). In conclusion, it is critical to have a contextualized way to surface GraphQL analytics and elevate alerts to improve the overall stability and usefulness of your GraphQL API. 

GraphQL Error Handling

large_Graphql_Injection.webp

medium_Graphql_Injection.webp

small_Graphql_Injection.webp

thumbnail_Graphql_Injection.webp

Graphql_Injection.webp

GraphQL’s complex payload expands attackers' ability to inject malicious payloads and compromise its underlying system.

## Overview
Injection attacks are a very common type of web attack, where an attacker sends malicious input to an API that has an interpreter or parser that processes the input and passes it on to a backend system or database. If the interpreter/parser doesn’t validate or sanitize the input, then the attacker can gain access to or manipulate confidential data.

## Why do injection attacks occur in GraphQL?
GraphQL is uniquely vulnerable to injection attacks for a few reasons:

1. GraphQL introduces new surfaces for injections, through features like operation names and aliases.
2. GraphQL introduces new steps in the processing flow. Each of the parser, the gateway, and the sub-graph resolvers can be targets for an attack.
3. GraphQL turns what would be multiple API calls with a REST API into a single call. This single call can target multiple areas and multiply injection combinations because of GraphQL’s free-form nature.

## How GraphQL injection attacks work
An injection attack can happen at any phase during the execution of a query:

1. Parsing: The GraphQL query string is parsed into an abstract syntax tree (AST), a tree-like representation of the query. This step verifies that the query is syntactically correct and adheres to the GraphQL query language specifications.
2. Validation: The AST is then validated against the GraphQL schema to check that the query is semantically correct and that it is requesting only valid fields and types. This step checks if the query adheres to the GraphQL schema and rules. Since the specification specifies no rules besides uniqueness on operation, argument, alias and directive names, these, if not validated, can be an entry point for an attacker.
3. Execution: The validated query is then executed by the server using resolvers. For each field requested, there is a resolver function that runs in the backend and fetches the data from the database. The resolver can also serve as an entry point for an attacker. For instance, the following is an example of a GraphQL resolver written using GraphQL.js. It executes a query that returns a customer that matches the supplied id. 

```
Query: {
 customer(obj, args, context, info) {
 const stmt = `SELECT * FROM customers where id = ${id};`;
 const customerData = db.query(stmt)
 return customerData
 }
}
```
If a value like id: "1' OR 1=1–" is provided, it will result in a SQL injection and the resolver will return all customers, triggering a data breach.

## Examples of Injection Attacks
GraphQL injection attacks can lead to a few different scenarios:

1. DoS (overloading the parser or resolver to a point they crash)
2. Extract data
4. Manipulate data

Below, we’ll cover some specific tactics that attackers might use in an injection attack, including Aliases, SQL injections, command injections, XSS assaults, LDAP and NoSQL injections.

## SQL injection
A SQL injection involves exploiting systems that use SQL to communicate with their databases. An attacker can inject SQL statements that manipulate a GraphQL query to access, modify or delete data.

For example, an attacker could include the following code in a GraphQL query that retrieves a particular customer's details:
```
query {
 customer(id: "22371' OR 1=1–") {
 name, 
 email, 
 address, 
 contact
 }
} 
```
During the execution phase, the above code would cause the query to return all the customer details instead of just the customer matching the original query.

## NoSQL injection
A NoSQL injection attack is similar to a SQL injection attack. It targets systems or applications that use NoSQL databases.

The following query is an example of a GraphQL query that accepts a JSON input to search for a user via user names or email addresses. 
```
query {
 users(search: "{\"username\": {\"$regex\": \"jan\"}, \"email\": {\"$regex\": \"jan\"}}",
 options: "{\"skip\": 0, \"limit\": 10}") {
 _id
 username
 fullname
 email
 }
}
```

The attacker could modify the JSON data type fields to include MongoDB or other NoSQL database-specific commands, which would then be executed by the database when the GraphQL query is processed.

```
query {
 users(search: "{\"email\": {\"$gte\": \"\"}}",
 options: "{\"fields\": {}}") {
 _id
 username
 fullname
 email
 }
}
```

During the execution phase, the above query will return all fields specified in the GraphQL schema for all users in the system. 

## LDAP injection
LDAP is commonly used for storing, retrieving, modifying and searching for data in a hierarchical directory. A GraphQL query that accepts LDAP input could be used to retrieve data from an LDAP directory. 

LDAP injection attacks typically target the search filter of an LDAP query, which is used to specify the conditions that must be met for a record to be returned. An attacker can modify the search filter to include malicious code, allowing them to retrieve sensitive information or perform other unauthorized actions. For example, an attacker might modify a search filter to include a wildcard character, which would return all records in the directory.

```
query {
 user(username: "*") {
 name
 email
 groups
 }
}
```

During the execution phase, the above query returns details of all users. 

## Command injection
Command injection is an exploit in which an attacker can inject shell commands or code into a GraphQL query. It allows the attacker to execute arbitrary commands on the server, thus potentially giving them wide access. For example, consider the following GraphQL query
```
query {
 getUser(id: "1") {
 name
 email
 }
}
```
An attacker can inject a command into the id field to execute a shell command on the server during the execution phase, such as:
```
query {
 getUser(id: "1; ls -la") {
 name
 email
 }
}
```
If the server is using an API that interprets a string as a shell command (for instance is using child_process.execFile), this would cause the server to execute the command `ls -la`.

## XSS (Cross-Site Scripting)
XSS attacks can occur when an attacker injects malicious code into trusted websites, generally in the form of browser scripts. For example, an attacker might inject malicious code into the comment field, such as:
```
query {
 getComment(id: "1") {
 user
 comment: "<script>alert('XSS Attack')</script>"
 }
}
```
When a user views the results of this query, the malicious script will be executed in their browser.

## Log spoofing
GraphQL actions can take an operation name as part of the query. For example, here is a query that uses CustomName as an operation name:
```
query CustomName {
 getCustomName
 {
 first
 last
 }
 }
```
In the audit log, the application will display all queries and mutations that users are executing on the system. If the query had an operation name, it will be recorded in the audit log under that operation name. This creates an opportunity for attackers to “spoof” the log by putting a query under a misleading operation name.
For example, the mutation below logs the mutation as getUser when actually, it’s creating a user.
```
mutation getUser {
 createUser(name:"<script>alert(1)</script>", content:"zzzz", public:true) {
 userId
 }
}
```
Or, the query below logs arbitrary strings to the audit log:
```
query arbitraryString {
 systemHealth
}
```

## HTML injection
HTML injection allows an attacker to inject malicious code into a vulnerable web page. HTML injections are similar to XSS attacks. The following query demonstrates how an attacker can create an HTML injection:
```
mutation {
 createPaste(title:"<h1>hello!</h1><script>alert('Attack')</script>", content:"zzzz", public:true) {
 paste {
 id
 }
 }
}
```

## Prevention and protection against GraphQL injection attacks
Below, we outline some ways to protect your server from GraphQL injection attacks.
### Input validation and sanitization
Input validation means having checks in place for GraphQL input. These checks validate that the input has an expected format and doesn’t include special characters frequently used in injection attacks.

For example, in the above SQL injection examples, we see that an attacker supplies input ( 1233' OR 1=1-) that includes the single quote special character.

The dynamic SQL statement in the resolvers might be: 
```
"SELECT * from customers where id='" + input + "'"
```

After concatenating it with the provided input, the statement is evaluated as:
```
SELECT * from customers where id='1233' OR 1=1—'
```
The single quote acts as a string delimiter in SQL. By adding it to the input, the statement searches for customers with an id of 1233 or 1=1. Since 1=1 is always true, it returns all customers. The last single quote is commented out, then, since – and any text after it is considered a comment in SQL. 

In this example, input validation would determine that the input contained dangerous special characters (single quote and -); input sanitization would then remove these characters. 

While input validation and sanitization can be performed in the resolvers (execution stage), it is recommended to do it earlier, in the validation stage, when the AST is validated against the GraphQL schema to determine that only valid types and fields are being requested. In addition to the basic Int, Float, String, Booleans, types, you can additionally enforce that inputs match custom scalar types, like email addresses. This helps you identify the data and validate it before even transferring it to the server.

### Prepared statements
Prepared statements bind the actual data values to the placeholders in the template at runtime. 
For example, instead of writing a query like this:
```
SELECT * FROM users WHERE id = '123';
```

You would use a prepared statement in your resolver like this:
```
SELECT * FROM users WHERE id = ?;
```

The ? is a placeholder that temporarily takes the place of the data. The SQL query is pre-compiled with placeholders, and the user’s data is added later. This means that even if a nefarious actor submits a GraphQL query that looks like:
```
query {
 user(id: "22371' OR 1=1 ") {
 name, 
 email, 
 address, 
 contact
 }
} 
```
The initial SQL query logic won’t be changed. Instead, the database will look for a user admin whose password is literally “22371' OR 1=1 ”.

### Secure libraries, secure implementations
Several well-known languages have libraries and implementations of the GraphQL specification. Attackers take advantage of flaws in these servers or implementations. For example, the use of exec and execSync in @graphql-tools/git-loader before 6.2.6. allows arbitrary command injection. Therefore, it's crucial to pick secure libraries and versions while creating GraphQL APIs. You can learn more about public GraphQL implementations [here](https://inigo.io/blog/how_threat_actors_fingerprint_your_graphql_apis).

## Conclusion
GraphQL injection attacks may undermine critical web applications and systems. To prevent GraphQL injection attacks, it is essential to follow best practices around input validation and the use of secure libraries.

Security tooling often focus on REST APIs input validation and sanitization, leaving GraphQL APIs unaddressed. With [Inigo](https://inigo.io/blog/operation_name_security_in_graphql), you can establish rigid guidelines for which operation names (as well as other elements of the document) to accept from clients. This ensures that your policy is rigid regardless of which GraphQL servers you use. The following is an example configuration that validates optional names for a GraphQL API:
```
kind: Security
name: my_server
spec:
 validation:
 alias_name: "^[a-zA-Z]+$"
 directive_name: "^[a-zA-Z]+$"
 operation_name: "^[a-zA-Z]+$"
 arguments:
 String: "^[a-zA-Z]+$"
```

## Additional Resources
There are many resources available to help developers learn about GraphQL security and injection attacks, including
1. "[GraphQL Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html)" by OWASP: This guide from OWASP covers the most common security risks associated with GraphQL and provides best practices for mitigating them.
2. “[Damn Vulnerable GraphQL Application](https://github.com/dolevf/Damn-Vulnerable-GraphQL-Application)” - Damn Vulnerable GraphQL Application is an intentionally vulnerable implementation of GraphQL to learn and practice GraphQL Security. 
3. “[The complete GraphQL Security Guide](https://wundergraph.com/blog/the_complete_graphql_security_guide_fixing_the_13_most_common_graphql_vulnerabilities_to_make_your_api_production_ready)” - This blog post discusses fixes to the 13 most common GraphQL vulnerabilities to make your API production ready.

Protecting your GraphQL APIs is critical, and this process may be aided with GraphQL security platforms like as Inigo, which operate with any GraphQL server. Inigo has schema-based access control, detailed analytics, dynamic rate-limiting, an easy UI, and much more to help you accelerate API adoption.

GraphQL Injection Attacks

large_Post_8_Illustration_1.webp

medium_Post_8_Illustration_1.webp

small_Post_8_Illustration_1.webp

thumbnail_Post_8_Illustration_1.webp

Post_8_Illustration_1.webp

GraphQL is becoming increasingly popular among technology leaders as a modernized replacement for legacy REST APIs. But with this shift comes new security risks. Unmanaged APIs can pose a threat to the enterprise in terms of unauthorized data access and breaches.

## Overview
CIOs and technology leaders are now likely aware of the growing popularity of GraphQL, the open source API query language. Like how Kubernetes adoption unfolded within organizations over the past few years, developers are largely leading the internal charge—championing GraphQL as a modernized replacement for legacy REST APIs.

According to Gartner, more than half of enterprises will be using GraphQL in production by 2025; in 2021, fewer than 10% were. This rapid shift is driven in part by the need to expose API data and functionality to third-party developers, which has become increasingly popular. GraphQL is a far more flexible, scalable, and easier-to-use option than REST. It’s become the cornerstone of widespread API modernization initiatives, and it is vastly more efficient and effective to use for developers.

However, with over 50% of APIs being “unmanaged”—and with enterprises producing and consuming an exponentially growing number of APIs—come new security risks.

What is an “unmanaged” API? Unmanaged APIs are APIs that have been created by a developer but are not discovered by the people who manage the GraphQL schema (i.e., the engineers/architects/CIO teams who are responsible for making sure that API development is efficient and secure, and that the schema itself is always optimized).

These unmanaged APIs are commonly referred to as “shadow APIs.” Going undiscovered and/or invisible, shadow APIs also prevent enterprise architects from optimizing schema planning and business logic across the organization. They then cannot enforce standards across subgraphs and manage resource consumption, resulting in Service Level degradation (latency) as well as inefficient and costly development. 
 
Furthermore, both shadow APIs and unsecured APIs pose an ongoing threat to the enterprise. The compliance and security teams lack the ability to enforce access control, detect anomalies, and secure the code, opening the organization to threats of unauthorized data access and breaches, as well as heavy financial and reputation losses. 

This raises the question: why are existing application gateways not sufficient to help with the transition to GraphQL? Most API and web application gateways that enterprises have in place cannot discover GraphQL traffic and cannot provide the depth and context necessary to deliver visibility, discoverability, or real-time protection. Because GraphQL operations are sent as a single request, it’s difficult to understand how that request is being handled and what services are being called; all GraphQL traffic is seen at a high level, without details or granularity.
Inigo was created to specifically address these gaps in API management, governance, and security for GraphQL APIs. Our solution goes into depth for each query, and with our innovative intellectual property, it not only makes GraphQL APIs visible and manageable but also provides real-time protection, Importantly, it delivers these capabilities regardless of the measures put in place by the developer, enabling CIOs and platform teams to move into API modernization with GraphQL with confidence. 

Inigo’s GraphQL gateway provides schema-based access control, so your team can define and enforce access policies based on the schema of your GraphQL APIs, rather than the underlying code. Doing so ensures that only authorized users and applications can access the data and functionality exposed by the APIs.

Second, Inigo delivers compliance with a full audit trail and PII detection. This allows your enterprise to track and monitor all of the interactions related to your GraphQL APIs, and to detect and prevent the leakage of sensitive personal information.

Third, Inigo provides protection from spec abuse, injections, and object-level rate limiting. This helps organizations prevent and mitigate different types of attacks, such as query overloads, data breaches, and service disruptions.

In addition to security, Inigo’s platform enhances the developer experience and adds key workflow efficiencies, including:

- Operations and performance optimization, which allows developers to monitor and improve the performance of their GraphQL APIs in real time.
- API lifecycle management with CI tools, which helps developers automate the deployment and testing of their GraphQL APIs.
- Schema planning, which enables developers to design and implement GraphQL APIs in a modular and extensible way.
- Granular query sub-graph analytics, which gives developers insights into the usage and behavior of their GraphQL APIs, and helps them to optimize and evolve them over time.

Inigo offers a more affordable solution compared to other data and analytics tools. It delivers GraphQL-specific capabilities that other tools are too expensive to apply to GraphQL deployments. Additionally, [Inigo is SOC-2 compliant](https://www.globenewswire.com/news-release/2023/01/11/2587241/0/en/Inigo-Achieves-SOC-2-Type-II-Compliance-Certification-for-GraphQL-Security-and-Management-Platform.html)—which means that it meets the strict security and compliance standards required by many organizations.

If you want to experience our solution, or see a demo, reach out to us at [sales@inigo.io](mailto:sales@inigo.io)


GraphQL in Enterprise - Are you Ready?

large_Post_8_Illustration.webp

medium_Post_8_Illustration.webp

small_Post_8_Illustration.webp

thumbnail_Post_8_Illustration.webp

Post_8_Illustration.webp

Significant increase in the adoption of GraphQL throughout 2023. Companies are increasingly seeking a path to modernize the way they build and manage APIs; GraphQL is increasingly the answer.

### What should you expect from GraphQL this year?

In short, a lot. We’re expecting a significant increase in the adoption of GraphQL throughout 2023. Companies are increasingly seeking a path to modernize the way they build and manage APIs; GraphQL is increasingly the answer. 

Simply put, the benefits that GraphQL provides for developers (and users) have become too consequential to ignore. With GraphQL, developers can create APIs tailored to a client's specific needs, rather than being limited to a fixed set of endpoints. That GraphQL benefit has always been there, but as the technology has grown up, so has the development of GraphQL frameworks and tools supporting teams in their API modernization initiatives. These tools are making it far easier for organizations to work with GraphQL and, just as significantly, increasingly sophisticated solutions are being developed to support GraphQL at greater scale. 

In addition to the continuous development of GraphQL frameworks and tools, we expect to see further refinement of the GraphQL specification and its ecosystem in the coming year. The GraphQL community is growing rapidly—accelerated by the work of the [GraphQL Foundation](https://graphql.org/foundation)—and this will lead to an increased focus on the specification (as well as the tools that support it).

As GraphQL becomes more widely adopted, there will also be an increased focus on security. Like other developer-driven movements, GraphQL posed new and urgent security and management challenges as enterprises use it at scale. Among these hurdles are protecting against GraphQL injection attacks, rate limiting, and developing best practices to prevent these attacks.

In 2023, we expect to see a significant increase in the use of dedicated and sophisticated security solutions that can handle GraphQL and the sensitive data that it often handles—such as financial and medical information, along with other types of personally identifiable information. (This isn’t just good practice—getting it right is mandatory to achieve regulatory compliance mandates.) These purpose-built GraphQL solutions and tools will be increasingly necessary as mainstream firewalls and intrusion detection systems struggle to keep up with the rapid evolution of GraphQL.

GraphQL is maturing, the technologies supporting it are maturing, and 2023 will be a particularly significant year for the API query language. It’s an exciting time, but teams and their organizations need to have their plan for GraphQL-at-scale—and the right tools—ready to go.


GraphQL 2023 Predictions

large_Blog_5_Illustration.webp

medium_Blog_5_Illustration.webp

small_Blog_5_Illustration.webp

thumbnail_Blog_5_Illustration.webp

Blog_5_Illustration.webp

We’re excited to announce that Inigo has achieved SOC 2 Type II compliance. With this certification, we stand alone as the only SOC-2 Type-II-certified company focused on GraphQL API security and governance.

## Overview
We’re excited to announce that Inigo has achieved SOC 2 Type II compliance. With this certification, we stand alone as the only SOC-2 Type-II-certified company focused on GraphQL API security and governance.

SOC 2 Type II requires organizations to meet the rigorous security, availability, processing integrity, confidentiality, and privacy standards set by the American Institute of Certified Public Accountants (AIPCA). In our comprehensive SOC 2 audit—performed by a third-party, Sensiba San Filippo, LLP (SSF)—our GraphQL API security and management platform fully demonstrated the robust controls required to achieve this certification and safeguard our customers’ crucial systems and sensitive data.

Earning SOC 2 compliance is a testament to the strength of our end-to-end security capabilities and processes. The designation also underscores our commitment to ensuring our customers can restrict data access to only authorized users and protect their modernized GraphQL APIs with the highest level of data security and privacy available.

We’re proud to share this major milestone for our company as part of our ongoing investment into Inigo’s security infrastructure. Our customers can take confidence that their data is under the continuous protection of the trustworthy and SOC-2-compliant Inigo platform.

- [Press Release Link](https://www.globenewswire.com/news-release/2023/01/11/2587241/0/en/Inigo-Achieves-SOC-2-Type-II-Compliance-Certification-for-GraphQL-Security-and-Management-Platform.html)

Your security peace-of-mind: We’re SOC 2 Type II Compliant

large_Best_New_Dev_Ops_Tool_400x400.webp

medium_Best_New_Dev_Ops_Tool_400x400.webp

small_Best_New_Dev_Ops_Tool_400x400.webp

thumbnail_Best_New_Dev_Ops_Tool_400x400.webp

Best_New_Dev_Ops_Tool_400x400.webp

We’re proud to announce that Inigo has been named one of the very few DevOps Dozen finalists in the Best New DevOps Tools category.

We’re proud to announce that Inigo has been named one of the very few [DevOps Dozen finalists](https://devopsdozen.com/) in the _Best New DevOps Tools_ category. The awards hone in on the “best, brightest, and most impactful” DevOps and developer tools from the past year across several categories.

As always, the DevOps Dozen are put together by the Techstrong Group, the company behind some of the best developer-centric cloud native and security publications—including DevOps.com, Container Journal, and Security Boulevard.

Here’s what DevOps Dozen had to say about our platform:

>“Inigo is a new GraphQL API management platform for DevOps/DevSecOps teams that offers a unique one-stop-shop for GraphQL API security, analytics, and developer productivity at scale. Inigo enables developers to avoid resource-heavy in-house tools that are costly to maintain and prone to errors. Inigo offers the absolute best developer experience around GraphQL APIs, so developer teams can scale with confidence and efficiency.”

We’re excited to be named a finalist in this newcomer category alongside some great new tools. If you’d like to throw your vote to Inigo as the category winner, [you can do that right here](https://www.surveymonkey.com/r/DevOpsDozenAwards2022)!



Inigo named one of the Best New DevOps Tools by the Techstrong Group

large_Operation_Name_Security.webp

medium_Operation_Name_Security.webp

small_Operation_Name_Security.webp

thumbnail_Operation_Name_Security.webp

Operation_Name_Security.webp

Experimenting with Operation Name characters. Despite the specification describing what characters should and should not be interpreted, there are deviations from the norm. This is why it is important to know your implementation well.

Operation Names in GraphQL are an optional string a client can specify to describe the operation, also called Named Operation ([Section 5.2.1](https://spec.graphql.org/October2021/#sec-Named-Operation-Definitions)) of the GraphQL specification.

The specification outlines the following rules as they relate to Operation Names:

- For each operation definition operation in the document.
- Let operationName be the name of operation.
- If operationName exists
-- Let operations be all operation definitions in the document named operationName.
-- operations must be a set of one.

This means that a document with more than one query or mutation must include operation names for each, and they must be uniquely named.

For example, the following document is valid:
```
query First {
 pastes {
 content 
 }
}

query Second {
 pastes {
 content 
 }
}
```
And this document is invalid because two queries use the same operation name, violating the uniqueness requirement:
```
query First {
 pastes {
 content 
 }
}

query First {
 pastes {
 content 
 }
}
```
This document is also invalid because only one query has a defined operation name in the document:
```
query First {
 pastes {
 content 
 }
}

query {
 pastes {
 content 
 }
}
```
When a request is sent to a GraphQL API with more than one operation, a client would need to specify the operationName JSON key with the specific named operation of interest to run it:
```
{
 "query":"query First { pastes { content } } query Second { pastes { content } }", 
 "operationName":"First", 
 "variables":[]
}
```
If the operationName JSON key is not defined but the query document contains two named operations, the GraphQL server may respond with the following:
```
{
 "errors": [
 {
 "message": "Must provide operation name if query contains multiple operations.",
 "extensions": {
 "code": "INTERNAL_SERVER_ERROR"
 }
 }
 ]
}
```
So, operation names are optional if a document contains one operation, but once it contains more than one, operation names are required and must be unique (i.e. not repeated).

Applications may log the operation names used by client queries for analytics and debugging. They are used by analytic tools to determine, for example, performant and non-performant queries and often are used instead of logging the entire query payload.
 
Have you ever asked yourself: what characters can be used in a named operation? Let’s see what is accepted versus not accepted with some Python-fu.

![Operation Name Structure.png](/uploads/Operation_Name_Structure_9345f3fdee.png)

## Experimenting with Operation Name Characters

For the purpose of this test, we used Sangria, Apollo, graphql-ruby, Graphene and HyperGraphQL as the targeted GraphQL servers a mix of seasoned and newer implementations, and used the following script to test various combination of operation name characters, while removing [ignored tokens](https://spec.graphql.org/October2021/#sec-Language.Source-Text.Ignored-Tokens) such as hashes (#) commas (,) and whitespace. 
```
import string
import time
import random
import requests

def randomize(N):
 random_int = random.randint(1, 7)
 strings = {1: string.ascii_lowercase + string.digits,
 2: string.ascii_lowercase + random.choice(string.punctuation),
 3: string.digits + random.choice(string.punctuation),
 4: string.punctuation,
 5: string.ascii_lowercase,
 6: string.digits,
 7: string.printable}

 chosen = strings[random_int]
 chosen = chosen.replace(' ', '')
 chosen = chosen.replace('#', '')
 chosen = chosen.replace(',','')
 chosen = random.sample(chosen, len(chosen))


 return ''.join(random.choice(chosen) for _ in range(N))


while True:
 opName = randomize(5)
 query = """
 query {0} {{
 __typename
 }}""".format(opName)


 r = requests.post('http://test.inigo.local', json={"query":query})

 if r.ok:
 print(f'Accepted: {opName}')
 else:
 print(f'Not accepted: {opName}')
```

Running the code produces the following results:
```
Accepted: k4qcb
Accepted: lzort
Not accepted: ]}VKV
Not accepted: 69071
Not accepted: \|&!~
Accepted: fclue
Not accepted: 2kxq6
Not accepted: $&${}
Accepted: _5157
Not accepted: +_'!)
Accepted: ztb0v
```
## Tests Breakdown

![Experimenting with Operation Names.png](/uploads/Experimenting_with_Operation_Names_bea8ce6a46.png)

Symbols such as greater than (>) or less than (<) typically used in Cross-Site Scripting payloads aren’t allowed, neither single-quotes or double quotes, equal sign, and others in most cases. One anomaly was **HyperGraphQL**, a Java-based GraphQL server, which allowed characters such as: `+><;^%~+ as operation name.

![Operation Name HyperGraphQL.png](/uploads/Operation_Name_Hyper_Graph_QL_7cd392d24d.png)


This was an interesting experiment. Despite the specification describing what characters should and should not be interpreted, there are deviations from the norm. This is why it is important to know your implementation well.

With Inigo, you can define strict rules on what operation names (as well as other components of the document) to accept from clients, so no matter what GraphQL servers you use, your policy is strict across all of them.
```
kind: Security
name: demo
label: starwars
spec:
 validation:
 alias_name: "^[a-zA-Z]+$"
 directive_name: "^[a-zA-Z]+$"
 operation_name: "^[a-zA-Z]+$"
 arguments:
 String: "^[a-zA-Z]+$"
```
Inigo can help you enforce the use of operation names across all your queries, in addition to applying a strict security policy so that operation names are limited to a safer subset of characters. Reach out to us for more information on how we can enforce security policies across all your GraphQL fleet

Operation name security in GraphQL

large_Array_based_Query_Batching.webp

medium_Array_based_Query_Batching.webp

small_Array_based_Query_Batching.webp

thumbnail_Array_based_Query_Batching.webp

Array_based_Query_Batching.webp

Watch out from array batching. It is possible to batch queries together by adding them to an array and sending them to a GraphQL server. This option is not available in all implementations and also isn’t specifically mentioned in the GraphQL specification.

In the [previous post](https://inigo.io/blog/defeating_controls_with_alias-based_query_batching), we discussed the way threat actors can optimize attacks to defeat authentication controls using query batching based on GraphQL aliases.

Aliases are great because they are part of the [GraphQL specification](https://spec.graphql.org/October2021/#sec-Field-Alias) as shown in section 2.5. So, when you run into a GraphQL API, you should expect to have aliases available at your fingertips.

Aliases have one disadvantage - they can only be applied to either queries, or mutations, but not both at the same time in a single HTTP request. Another approach to query batching is by using arrays.

It is possible to batch queries together by adding them to an array and sending them to a GraphQL server. This option is not available in all implementations and also isn’t specifically mentioned in the GraphQL specification. 

It is quite easy to test whether a GraphQL API support arrays, here is how you can do this in Python using the requests library:
```
import requests

queries = [
  {"query":"query { __typename }"},
  {"query":"query { __typename }"}
]

requests.post('http://localhost:5013/graphql', json=queries)
```
If you prefer cURL, you can test whether the GraphQL server supports arrays like so:
```
curl -X POST http://example.inigo.local/graphql -H "Content-Type: application/json" -d '[{"query":"query { __typename }"}, {"query":"query { __typename }"}]' 
```
The response that comes back to queries sent in an array would include multiple data keys, each containing a separate response:
```
[
   {"data":{"__typename":"Query"}},
   {"data":{"__typename":"Query"}}
]
```
When GraphQL servers see an array (and when they support them), they will process each query one after another in sequence, and return a response once all of them are resolved. Here is how the [Graphene-django implementation handles arrays](https://github.com/graphql-python/graphene-django/blob/master/graphene_django/views.py#L168-L179). 

![Array GraphQL.png](/uploads/Array_Graph_QL_ea12888890.png)

The advantage of arrays is that you can mix queries and mutations together, like so:
```
import requests

queries = [
  {"query":"query { __typename }"},
  {"query":"mutation { createUser(user:”user1”) { id } }}"}
]

requests.post('http://example.inigo.local/graphql', json=queries)
```
So, if you have an API flow that requires sending a mix of queries and mutations together to get to some desired state, arrays make it easier.  Aliases on the other hand can only be used to batch queries of the same root type. 

Arrays have one major disadvantage - they aren’t available everywhere. We recommend reading the documentation of the GraphQL implementation in use in your production environment to learn if arrays are supported (or simply try a query against it to figure it out) and whether they can be disabled. 

Whether you are using a popular GraphQL server or you’ve built your own, using Inigo’s GraphQL Security and Management platform works independently and is completely server-agnostic, which protects any GraphQL APIs and helps introduce security controls no matter what GraphQL server you use.


Defeating controls with Array-based Query Batching

large_Alias_based_Query_Batching.webp

medium_Alias_based_Query_Batching.webp

small_Alias_based_Query_Batching.webp

thumbnail_Alias_based_Query_Batching.webp

Alias_based_Query_Batching.webp

GraphQL isn’t immune to vulnerabilities, it may suffer from them just like any other API technologies such as REST, SOAP, gRPC, or others, but there are some unique and interesting possibilities that open up to hackers when GraphQL is present on the target they are interested in compromising.

GraphQL isn’t immune to vulnerabilities, it may suffer from them just like any other API technologies such as REST, SOAP, gRPC, or others, but there are some unique and interesting possibilities that open up to hackers when GraphQL is present on the target they are interested in compromising.

Vulnerability classes such as Injection, Denial of Service, Forgery, Lack of Resource & Rate Limiting as well as others, can all apply to GraphQL APIs. However, what’s interesting in GraphQL is the new ways it allows threat actors to optimize certain attacks, specifically those that fall under the category of denial of service and defeating authentication mechanisms.

![Secured GraphQL.png](/uploads/Secured_Graph_QL_f702a31dbb.png)

Aliases in GraphQL allow clients to rename response keys of fields and use the same query operation more than once. Let’s first see what happens when a client asks for simple information such as the ID of users:
```
query {
  users {
    id
  }
}
```
And the response:
```
{
  "data": {
    "users": [
      {
        "id": "1"
      },
      {
        "id": "2"
      }
    ]
  }
}
```
If a client attempts to fetch the same information more than once this way:
```
query {
  users {
    id
  }
  users {
    id
  }
}
```
Then the response returned by the GraphQL server will only return a single users key in the response:
```
{
  "data": {
    "users": [
      {
        "id": "1"
      },
      {
        "id": "2"
      }
    ]
  }
}
```
The JSON structure we get back from the GraphQL server returns a single key, so the response of two operations is consolidated to a single response key.

Aliases in GraphQL allow you to rename the operation name (and hence the JSON key in the response). Aliases can be configured by prefixing the field of interest with some named alias:
```
query {
  nameOne: users {
    id
  }
  nametwo: users {
    id
  }
}
```
Which results in the GraphQL server returning the following response:
```
{
  "data": {
    "nameOne": [
      {
        "id": "1"
      },
      {
        "id": "2"
      }
    ],
    "nametwo": [
      {
        "id": "1"
      },
      {
        "id": "2"
      }
    ]
  }
}
```
This allows you to run multiple queries and rename their response key, which allows you to get separate responses. 

GraphQL APIs just like any other API can perform sensitive actions such as:
1. User login
2. User password resets
3. User signup
4. Token verification
5. Code verification

This list is just the tip of the iceberg, there could be more options, but you get the point. 

Back to aliases - aliases allow you to “stuff” multiple operations in a single HTTP request. Does that ring any of your security bells? It should, because traditional security controls could struggle identifying malicious behavior if they rely on certain characteristics that are more relevant to non-GraphQL based APIs. For example:

- HTTP Method (POST/GET)
- API Route (e,g, /v1/login)
- Number of clients requests made (e.g. 100 per minute)
- The returned HTTP code

Looking at all of these as indicators of potential compromise attempt makes sense in the context of security: If a client makes a POST request to the /v1/login endpoint 100 times in 5 seconds and the response code is 401 Unauthorized, maybe this client is attempting to brute force accounts on your application. These heuristics make sense in non-GraphQL APIs. In GraphQL, the heuristics are a little different.

In GraphQL, the client intention is not expressed by the HTTP verb, route, or the returned code (in many cases) but by the query payload. Determining how the GraphQL server handled the query is expressed in the response versus any HTTP headers.

So, if you have a login GraphQL query that takes in an email and password, it would look like the following:
```
query {
  login(email:"user123@example.com", password:"abc") {
    token
  }
}
```
With aliases, we can now perform multiple login attempts and send those over a single HTTP request:
```
query {
 attemptOne: login(email:"user123@example.com", password:"abc") {
    token
 }
 attemptTwo: login(email:"user123@example.com", password:"def") {
    token
 }
 attemptThree: login(email:"user123@example.com", password:"geh") {
    token
 }
}
```
This query structure could circumvent security controls that perform rate limiting that bases its heuristics on the volume of client requests combined with the HTTP method and API route being used. As GraphQL adopters, it’s important to find a solution that can protect your APIs and identify malicious behavior more tailored to GraphQL APIs.

Aliases can be used to batch any query (or mutation) but not both at the same time. In the next post, we will cover another method of query batching that allows mixing these two types together.


Defeating controls with Alias-based Query Batching

Public_Graph_QL_Vulnerability_Header.webp

large_Public_Graph_QL_Vulnerability_Header.webp

medium_Public_Graph_QL_Vulnerability_Header.webp

small_Public_Graph_QL_Vulnerability_Header.webp

thumbnail_Public_Graph_QL_Vulnerability_Header.webp

We spent a few days examining data from two main sources: The CVE database by MITRE and the HackerOne Hacktivity portal to see what we can learn from analyzing GraphQL vulnerability data.

## Overview
One way to learn about GraphQL security is by analyzing public information related to vulnerabilities impacting GraphQL components such as GraphQL clients (like Relay) or GraphQL servers (like Apollo, Graphene, Ariadne, and even products like GitLab Enterprise, Magento, etc). We spent a few days examining data from two main sources: The CVE database by MITRE and the HackerOne Hacktivity portal to see what we can learn from analyzing vulnerability data.

![Public GraphQL Vulnerability .png](/uploads/Public_Graph_QL_Vulnerability_78fe425985.png)

## GraphQL Vulnerability Data Analysis - MITRE CVE Database
The [MITRE CVE](https://cve.mitre.org/) database is the source of truth for CVEs. Before diving into the dataset, it’s important to highlight a few important things about the database:

1. Not all vulnerabilities are reported.
2. Not all vulnerabilities receive a CVE identifier.
3. Some vulnerabilities are reported but never get a CVE identifier assigned.

The reason this is important to highlight is, while the CVE database is a good data sample, it is not a comprehensive list of vulnerabilities. 

Generally speaking, vulnerabilities get a CVE identifier when either the vendor of the software impacted by the vulnerability or the researcher who found the flaw engages MITRE and files a CVE request. Some software vendors are authorized to issue their own software a CVE identifier, these vendors are acting as a CNA (CVE Numbering Authority) and you can find the list of CNA partners [here](https://www.cve.org/PartnerInformation/ListofPartners), on this list you can find vendors such as GitLab, Adobe, GitHub, and more.

To get an idea of the GraphQL vulnerability dataset, we used the MITRE CVE database search option, where you can perform a free-text search. Here is what the search-term “GraphQL” brings up:

![Public GraphQL Vulnerability CVE list.png](/uploads/Public_Graph_QL_Vulnerability_CVE_list_a4d1d63633.png)

Having access to this dataset, a few questions came up:

1. How many vulnerabilities are there with CVEs?
2. What are the most common vulnerability classes?
3. When was the first vulnerability tracked?
4. Which GraphQL component has the most CVEs?

### How many vulnerabilities are there with CVEs?
The search yielded a [few dozen](https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=graphql) (45) CVEs related to GraphQL components, such as GraphQL servers, GraphQL client libraries, and so on. 

### What are the most common GraphQL vulnerability classes?
Authorization (54%) and DoS-based (16%) vulnerabilities were the most popular vulnerability classes, as shown in the pie chart below.

![Public GraphQL Vulnerability CVE.png](/uploads/Public_Graph_QL_Vulnerability_CVE_4fb711cdb8.png)

### When was the first vulnerability tracked?
Purely based on the CVE identifier strings, the oldest entry is from 2019 (CVE-2019-1000011) this is likely not the first ever vulnerability found in software with GraphQL, but it’s the oldest found in MITRE’s database.

### Which GraphQL software has the most CVEs?
This data is likely skewed by the popularity of the component itself, and is not indicative of how hardened a component is or is not, but nevertheless it is interesting data to analyze:

![Public GraphQL Vulnerability CVE By Component.png](/uploads/Public_Graph_QL_Vulnerability_CVE_By_Component_6820b932c8.png)

## GraphQL Vulnerability Data Analysis -  HackerOne
The [HackerOne](https://hackerone.com/) vulnerability database is a great resource to learn about the types of vulnerabilities researchers report on and get credited for. We performed a search against the public reports on HackerOne to see what types of vulnerabilities have been reported so far.

Since 2018, 74 vulnerabilities have been reported to various companies and bounties ranging anywhere from $250 to north of $20,000 were granted. Most vulnerabilities were in the category of Authorization flaws (87%), followed by DoS (7%) and others (5%)

![Public GraphQL Vulnerability Hacker One.png](/uploads/Public_Graph_QL_Vulnerability_Hacker_One_b985cdcb99.png)

Security researchers participating in bug bounty programs are often motivated by money, and authorization-related vulnerabilities very often result in data leakages and impact to personal identifiable information (PII) - these vulnerabilities are considered to be the most critical to companies and the reward for finding such vulnerabilities is, as such, very incentivizing - so it comes as no surprise that most ethical hackers will test for authorization flaws before anything else.

One important fact about Bug Bounty programs is that testing for Denial of Service-based vulnerabilities is more often than not disallowed (and many times their bounties are also comparatively low where it is allowed), this is reflected in the chart by the limited number of reported DoS vulnerabilities.

GraphQL continues to be interesting both from an offensive as well as a defensive standpoint. Inigo’s GraphQL Security and Management solution helps address Authorization, Denial of Service, as well as other classes of vulnerabilities in GraphQL APIs. 

## Conclusion
GraphQL, with its free-form nature, introduces a new paradigm of attack surfaces. Inigo can help to put the proper guardrails in place, whether you are just starting or already have GraphQL in production. Learn more [here](https://inigo.io/demo).




Analysis of public GraphQL vulnerability reports

Defending_Graph_QL_AP_Is_Challenging_to_Security_Engineers.webp

large_Defending_Graph_QL_AP_Is_Challenging_to_Security_Engineers.webp

It’s not enough to know how GraphQL works and how it can be attacked, what also matters a lot is whether security professionals have the necessary tools to identify suspicious queries, exploitation attempts, and solutions to protect against GraphQL-tailored attacks.

While GraphQL has been around for at least seven years since the first reference implementation [graphql-js](https://github.com/graphql/graphql-js) was released to the public in July 2015, many security professionals are not yet caught up with it. It’s not enough to know how GraphQL works and how it can be attacked, what also matters a lot is whether security professionals have the necessary tools to identify suspicious queries, exploitation attempts, and solutions to protect against GraphQL-tailored attacks.

Whether you have a Web Application Firewall (Cloudflare, Modsecurity, or other) monitoring your application for security events, or you’ve built an in-house monitoring solution based on standard access logs to detect suspicious behavior in web applications, you have probably developed some dependency on key indicators such as:

- HTTP methods (verbs)
- HTTP response status codes
- Sensitive API Routes
- API parameters

These indicators are helpful when you want to monitor for specific events, such as:

1. Clients hammering your registration endpoint
2. Clients attempting to login unsuccessfully multiple times
3. Clients attempting to perform account enumeration
4. Clients tampering with parameters of interest

Monitoring for such events in REST APIs is pretty trivial and requires a few things to be in place: it requires the protected application to follow [RFC2616](https://www.rfc-editor.org/rfc/rfc2616.html) when it comes to the returned HTTP status codes so the signals make sense to clients as well as the security engineering team, and it requires the security team to have a pretty good idea (and an inventory) of their APIs.

Traditional monitoring systems use HTTP components for monitoring. Here is an example of a pseudo-monitoring rule that could be beneficial to the security team in particular:

```
alert if (http.method=GET and response.status_code=403 and http.uri=”/v1/user/<id>/profile”) 
```

This example rule relies on the HTTP method (GET), a response code (403 Forbidden) and a specific route (/v1/user/id/profile), which will mostly be available in the case of REST APIs, but what about GraphQL?

![Inigo Observeability.png](/uploads/Inigo_Observeability_4a6f09d1de.png)

GraphQL uses a single GraphQL route (/graphql is pretty common). The reason routes don’t matter in GraphQL APIs is because client intentions are all based on the query payload. While it’s true GET and POST are in use in GraphQL APIs, it does not reflect what the client is ultimately trying to do, this is all derived from the query.

Going back to the case of monitoring APIs for security events, this design of GraphQL renders traditional security monitoring approaches pretty useless. Monitoring rules as shown above will no longer work, and different tools will be required to achieve the objective.

Not only is there an issue with the single route, GraphQL APIs don’t depend on normal HTTP status codes. It’s often the case that a GraphQL API will return a 200 OK to any query, while any errors will be reflected by the response payload coming back from the server using a dedicated **errors** JSON key with the error message relevant to what went wrong.

For instance, take a look at the example query below that allows a user to fetch their own user details by passing a numerical user ID:
```
query {
 user(id: 1000) {
 email
 name
 address
 }
}
```

If the calling client has authorization to view user ID 1000 and that ID exists, then such query would result in a response such as:
```
{
 "data": {
 "user": [
 {
 "email": "test@example.com",
 "name": "test user",
 "address": "123 Hollywood Blvd",
 }
 ]
 }
}
```

If the calling client does not have the right authorization level, a GraphQL response might look like the following:
```
{
 "errors": [
 "message": “You are not authorized to view this user.”
 ]
}
```

If the user ID does not exist on the system, a GraphQL response might look like the following:
```
{
 "errors": [
 "message": “User with ID 1000 does not exist”
 ]
}
```

The HTTP code to all three conditions could be a consistent 200 OK from the GraphQL server, which is why GraphQL is more challenging to monitor than traditional REST APIs. If your monitoring solutions are based on standard HTTP access logs, be prepared to see a lot of log lines that look like the following:

```
1.2.3.4 - - [02/Aug/2022:18:27:46 +0000] "POST /graphql HTTP/1.1" 200 - "-"
"curl/7.43.0" - 539
1.2.3.4 - - [02/Aug/2022:18:27:46 +0000] "POST /graphql HTTP/1.1" 200 - "-"
"curl/7.43.0" - 539
1.2.3.4 - - [02/Aug/2022:18:27:46 +0000] "POST /graphql HTTP/1.1" 200 - "-"
"curl/7.43.0" - 539
```

You can’t do a whole lot with this. For monitoring security events, you will need a view into the query payload, as well as the response payload, and a solution that can contextualize these events for you. To make matters worse, GraphQL allows batching multiple queries into a single HTTP request, therefore allowing threat actors to hide multiple actions in a single HTTP packet:

```
query {
 alias1000: user(id: 1000) {
 email
 name
 address
 }
 alias1001: user(id: 1001) {
 email
 name
 address
 }
 alias1002: user(id: 1002) {
 email
 name
 address
 }
}
```

When such a query is made, you will only see a single incoming HTTP request, despite the fact that 3 queries were made. 

If you thought it stops here, we’ve got some news for you: it is also possible to batch queries using an array against some GraphQL servers that support it, like so:

```
import requests

queries = [
 {
 "query":"query { user(id: 1000) { email name address }}",
 "query":"query { user(id: 1001) { email name address }}",
 "query":"query { user(id: 1002) { email name address }}"
 }
]

r = requests.post('http://test.inigo.local/graphql', json=queries)

print(r.json())
```

Inigo can help provide you with an observability layer tailored to GraphQL that handles these cases too.

Product

Documentation

Pricing

Blog

Company

Inigo Blog