📣 GraphQLConf 2024 • Sept 10-12 • San Francisco • Check out the Schedule & Get Your Ticket • Read more
FAQ
Best Practices

Best Practices

Is GraphQL scalable?

Yes, GraphQL is designed to be scalable and is used by many companies in production under a very high load.

GraphQL comes with some built-in performance boosts that can help. But once you push it to production, you’re responsible for scaling it across instances and monitoring performance.

Does GraphQL support offline usage?

No, or at least not natively. But there are GraphQL clients that enable you to build offline-first. They use features designed to perform data operations while offline, such as caching and service workers.

You can find a list of GraphQL clients in various languages on our Code page.

What are the security concerns with GraphQL?

Most of the security concerns associated with GraphQL are typical for any API or service. A few examples: SQL injections, Denial of Service (DoS) attacks, or someone abusing flawed authentication. But there are also some attacks specific to GraphQL. For instance, batching attacks. These attacks can happen as a result of GraphQL allowing you to batch multiple queries (or requests for multiple object instances) in a single network call.

No matter the concern, it’s important to be proactive. There are many ways to securing your GraphQL server. Using a timeout, setting a maximum depth for queries, and throttling queries based on the server time it needs to complete are all potential approaches.

For an overview of common security concerns and how to address them, check out the Security tutorial on How to GraphQL and OWASP’s GraphQL Cheat Sheet.

How can I set up authorization with GraphQL?

We recommend enforcing authorization behavior in the business logic layer. That way, you have a single source of truth for authorization.

For a more detailed explanation, go to our Authorization documentation.

How does authentication work with GraphQL?

You can implement authentication with common patterns, such as OAuth or JWT. There’s nothing special about authentication within the GraphQL specification.

Some GraphQL libraries include a specific protocol for authentication as well. Although if you’re working with a pipeline model, we recommend that GraphQL be placed after all authentication middleware.

If you’re using GraphQL.js to build your API server, we have documentation on handling authentication with Express middleware.

Is GraphQL the right fit for designing a microservice architecture?

Yes, it can be. If you’re integrating GraphQL into your microservice architecture, we’d recommend having one GraphQL schema as an API gateway rather than having your client talk to multiple GraphQL services. This way, you can split your backend into microservices, but then still aggregate all your data to the frontend from a single API.

There are many ways to create an API gateway. The benefit of using GraphQL is that you can take advantage of features like caching, request budgeting, and planning out query schedules.

How does versioning work in GraphQL?

There’s nothing that will prevent a GraphQL service from being versioned like any other REST API. That said, GraphQL avoids versioning by design.

Instead, GraphQL provides the tools to continually build and evolve your schema. For example, GraphQL only returns the data that’s explicitly requested. This means that you can add new features (and all the associated types and fields) without creating a breaking change or bloating results for existing queries.

You can read more about how versioning works in GraphQL in our Best Practices section.

How can I document my GraphQL API?

One of the benefits of GraphQL is that it’s inherently self-documenting. This means that when you use an interactive tool like GraphiQL, you’re able to explore what data is exposed by your GraphQL API. This includes the fields, types, and more. You can also add a description field to provide supplementary notes about your endpoint. This description field supports strings and Markdown.

For many, this provides enough API reference documentation. But it doesn’t reduce the need for other forms of documentation. You’ll likely still need to create guides that explain how the general concepts tie into your specific use case.