Rubrik tech lead: the dawn of GraphQL
This is a guest post written for the Computer Weekly Developer Network by Rebecca Fitzhugh in her role as principal technologist at Rubrik.
Fitzhugh writes from here…
One exciting change that has slowly percolated throughout the datacentre is the use of RESTful (Representational State Transfer) APIs to control operations.
This resulted in an easy to use model for datacentre architecture that increased opportunities for automation and orchestration.
First introduced in 2000 as a simpler way for machines to communicate using the ubiquitous HTTP protocol, RESTful architecture has enabled different systems to be loosely coupled to allow the exchange of information.
For example, a provisioning tool could be integrated with multiple platforms, allowing you to create a new workload, configure it, and then protect its data all in one automated workflow.
More recently, however, there’s been a subtle shift from the centrality of REST APIs to GraphQL.
As we prepare for the next wave of emerging technologies to enter organisations, I believe this shift to GraphQL APIs will be mission-critical in managing new technologies, whilst allowing enterprise architects to adopt and stitch together open source, serverless, and containers.
GraphQL vs. REST APIs
The core concept of REST is that everything is a resource, and while it was a great solution when it was first proposed, this architecture now faces several significant issues. REST APIs are limited to single resources. This means that if you’re querying data from two or more resources, users will need to undertake multiple round trips to the server.
For example, if you were to query ‘women aged 35-45 who like tennis’, you’d have to do one query to find people who like tennis, then for the correct age range, gender, etc. However, using GraphQL allows for more granularity and could return this data more efficiently. The basic premise of GraphQL is to expose a comprehensive data schema to the consumer, and let the consumer decide exactly what it needs. Unlike with REST endpoints, all the data for any given resource can be sent in one trip to the client.
This is because GraphQL was designed with a more flexible approach.
API flexibility
Rather than dealing with dedicated resources, GraphQL regards everything as a connected graph which in turn allows you to tailor queries to your exact needs. Suddenly, you’re able to build highly flexible APIs for your applications, meaning a lot less time spent querying.
In addition to this, GraphQL enables users to specify which fields should be included, limiting the response to the data which is needed, and combine connected entities within one GraphQL data query in one request.
When coupled with the inability to limit the request to only retrieve a subset of data fields, you begin to see how using REST APIs is unwieldy when managing large data sets. This is why many SaaS platforms have opted to use GraphQL.
A new dawn
From Air Malta to the New York Times, using APIs has revolutionised how companies provide services because of improved ability and increased productivity.
The API economy isn’t going away any time soon. GraphQL presents a new way for the data consumer to specify the data it needs for each resource in a declarative manner. This means less data transfers, leaner code, and ultimately a faster experience for the consumer.
It makes sense then that software companies, such as GitHub, that manage a tremendous amount of data are quickly adopting GraphQL.
It’s unlikely that GraphQL is the coup de grâce for REST, however, it does contain a rich set of enhancements that stand to be around for a long while.
Fitzhugh: climbs every mountain, then enjoys a REST.