You’ll want to see the docs on “ Registering schemas using schema reporting” to get started. Enable new developers to explore the current schema and its capabilitiesįirst step is to register your schema to the Apollo Studio schema registry.Now that we’ve turned off introspection in production, how do we: Use a schema registry to update, browse, and maintain your production Graph You can read the docs about introspection here. We recommend using environment variables so that you can enable introspection for GraphQL tooling in your development and staging environments but not for your production one. If you use the description feature in GraphQL, it should be known that this is a type of detail that can be queried using introspection queries.įor example, the following field containing helpful (yet sensitive) details can be queried by any party on a GraphQL API in production with introspection enabled. Problems with introspection in production Revealing sensitive informationĪs you invest in building a graph at your company, you’ll want to ensure that details that should only be known inside your org, stay inside.
#Postman graphql schema how to#
Now, considering the private GraphQL API context again - most of the time, you don’t want just anybody to learn how to run queries against your private data. You’d also likely need to authenticate yourself, then accompany all of your requests with a valid auth token, but again - this is a constraint typically communicated better with words - through API documentation. Once we know what we can do with the API, we can write queries and mutations.įor a public GraphQL API, querying and mutating your personally owned data is likely the very reason why the API exists. However, we should consider the risks of leaving an API not intended for use by anyone other than the developers in your org (with auto-generated documentation on how to perform every operation ) out in the open on the internet. At first glance, it may make sense to leave introspection on in production so that developers on your team could merely point their GraphQL IDEs to the URL of the production graph, look at the structure, and see what’s possible. On the other hand, to learn all possible operations in the private context, security is the prime concern. In the context of a public GraphQL API, to learn all possible GraphQL operations, you certainly could leave introspection on in production, but our principled belief is that clear and expressive documentation (API references) is the better discoverability tool for a public GraphQL API.
Use case: Learn all possible GraphQL operations The vast majority of us are building private GraphQL APIs. Whereas a private GraphQL API is one built to serve the client-side experiences for products built by developers within your organization. private APIsĪ public GraphQL API is one made primarily for consumption by developers outside of your organization (like the Shopify or GitHub APIs). Let’s consider the utility of introspection outside of the context of development, in a production environment.įirst, we need to make a distinction between public and private GraphQL APIs. Behind the scenes, GraphQL IDEs use introspection queries to power the clean user experience helpful for testing and diagnosing your graph during development. While we don’t often use introspection directly, it’s important for tooling and GraphQL IDEs like Apollo Studio, GraphiQL, and Postman. We believe that introspection should primarily be used as a discovery and diagnostic tool when we’re in the development phase of building out GraphQL APIs. This includes data like types, fields, queries, mutations, and even the field-level descriptions. GraphQL introspection enables you to query a GraphQL server for information about the underlying schema.
In this post, we’ll discuss why we believe you should disable GraphQL introspection in production, how to do it, and present a way to get the same benefits of introspection in production using a schema registry instead.
Once your graph is up and running in production, like anything else on the internet, it’s a good idea to implement precautions to prevent it from being compromised by bad actors.ĭisabling introspection in production is a widely debated topic, but we believe it’s one of the first things you can do to harden your GraphQL API in production.
0 kommentar(er)
