Just because you can build a GraphQL architecture doesn’t mean you should. There are plenty of use cases where REST will serve you equally well (if not better!). However, there is also a growing number of GraphQL use cases.
Feeling conflicted? Don’t worry – we’ll run you through some of the basics below and look at when and why GraphQL might suit your environment better than REST.
What is GraphQL?
GraphQL is a query language that opens up the ability to easily query and manipulate application data. With REST, you define the structure of the request on the server, and the request and response are sent as HTTP. With GraphQL, you define all the objects on your server, but you give your consumer full control over what the request response contains because the consumer chooses the data they want to query.
Why use GraphQL?
The key benefit of GraphQL is that you can fetch only the data you’re requesting – nothing more, nothing less. GraphQL provides predictable data responses across multiple microservices and APIs, with the potential to enhance performance by eliminating over and under-fetching. And all via a single /graphql endpoint.
Using GraphQL queries can thus deliver greater efficiency and reduced complexity – two powerful reasons GraphQL might suit you more than REST. In terms of when to use GraphQL, a range of use cases have emerged…
What is GraphQL used for?
Who uses GraphQL and how? The following use cases provide an idea of the range of ways in which GraphQL can be used – and go some way towards explaining why it is winning the REST vs GraphQL popularity contest.
Avoiding over-fetching
GraphQL only returns the data the client asks for – it’s how GraphQL works. As such, if you’re looking for maximum efficiency in data fetching, then using GraphQL makes sense.
Reducing bandwidth requirements
By only fetching the data that’s required, and nothing more, GraphQL can help reduce bandwidth requirements, which can deliver a positive performance impact for mobile apps.
Querying multiple data sources
GraphQL makes it easy to query multiple data sources using a single GraphQL endpoint. This opens up the potential for using GraphQL within complex environments, with multiple APIs and microservices handling requests in parallel before GraphQL aggregates the responses and returns a single response to the client. As such, a GraphQL microservices architecture can tick a lot of boxes when it comes to efficient query handling.
Retrieving nested data
With plenty of scope for customising queries and retrieving nested data, GraphQL provides a whole heap of flexibility when it comes to getting the best out of your data, even if your data architecture resembles a set of matryoshka dolls.
Detangling legacy spaghetti
GraphQL allows you to give old APIs new life by serving as either a façade or a proxy. You can easily simplify and represent legacy APIs while adding any required functionality.
Rapid prototyping
Beating the competition to market means embracing rapid prototyping. By using GraphQL services, you can enable your frontend teams to develop, test and implement prototypes without waiting on your backend teams.
Reduced errors
GraphQL is strongly typed. That means it can ensure that queries are valid within the GraphQL type system and are syntactically correct before executing them, leading to fewer errors.
Drawbacks of GraphQL
So far, so good. But as we mentioned at the start, GraphQL doesn’t fit every use case. It does have its drawbacks.
The GraphQL learning curve
Every new technology comes with a learning curve. Yes, GraphQL use can reap the rewards, but you’ll need to ensure your team has plenty of time to understand GraphQL sufficiently before you can get the best out of it – and them.
The risk of over-engineering
If you have a simple application with standardised use of a few fields, you are likely to be over-engineering the solution if you implement GraphQL. This risks introducing greater complexity than is required, with a resulting decline in performance and efficiency.
Caching challenges
Because the consumer decides what query will be sent and what fields will be requested, you’ll have to think carefully when it comes to caching – particularly where a slick user experience is important. And let’s face it, when isn’t user experience important these days?
The N+1 challenge
One of the more commonly known GraphQL problems is the N+1 challenge. While REST has one resolver per endpoint, GraphQL’s approach of executing a separate resolver for each field in a query results in N+1 round trips to the database. Thankfully GraphQL libraries such as Dataloader provide a neat solution.
Uploading files
You’ll also need to turn to GraphQL library solutions if you want to upload files with GraphQL. This isn’t the easiest of tasks and is another point in REST’s favour if you’re trying to decide which best fits your use case.
GraphQL Implementation
If you’ve already put the whole “Should I use GraphQL” debate to bed and decided to implement it, Tyk can help. Our open source API gateway supports GraphQL natively, meaning you can enjoy the benefits of full lifecycle API management while implementing GraphQL. Thanks to our GraphQL core functionality, you can securely expose GraphQL APIs without needing any external service or process, all with seamless introspection and GraphQL-specific security.
Tyk’s integrated GraphQL engine also enables you to build a Universal Data Graph that combines multiple APIs into one universal interface, allowing you to expose existing services as a single GraphQL API. Universal Data Graph enables you to connect multiple data sources into a single schema within the API gateway itself. It doesn’t matter whether your data source is a GraphQL service, a RESTful API, a database or a Kafka stream – Universal Data Graph stitches it all together and exposes it through a single endpoint you can query like a database.
It only takes a few minutes to produce fully functional, production-ready GraphQL endpoints with Tyk’s Universal Data Graph, all with no coding. And with Tyk’s GraphQL federation, you can easily spread your GraphQL implementation across multiple backend services.
If you’re ready to find out more and explore in depth whether GraphQL suits your particular use case, why not chat with the Tyk team? We can arrange an engineer-led demo or a free trial so that you can discover whether your GraphQL use case is a winner.
