Benefits of Exposing Data Through GraphQL

GraphQL is rapid­ly grow­ing in pop­u­lar­i­ty with­in our orga­ni­za­tion at Hudl. Although we have only been using GraphQL for a few months, we are already reap­ing the ben­e­fits of it.

Benefits of Exposing Data Through GraphQL

GraphQL is rapid­ly grow­ing in pop­u­lar­i­ty with­in our orga­ni­za­tion at Hudl. Although we have only been using GraphQL for a few months, we are already reap­ing the ben­e­fits of it.

GraphQL is rapid­ly grow­ing and prov­ing itself to be a reli­able replace­ment for REST. Since Facebook has released GraphQL, oth­er com­pa­nies such as Twitter and Intuit have cre­at­ed GraphQL imple­men­ta­tions for their APIs. For those who aren’t famil­iar, GraphQL is a query lan­guage and type sys­tem used to help solve some major pain points of REST: keep­ing updat­ed API doc­u­men­ta­tion, infi­nite end­point man­age­ment, and ever-grow­ing pay­loads. GraphQL is rapid­ly grow­ing in pop­u­lar­i­ty with­in our orga­ni­za­tion at Hudl. Although we have only been using GraphQL for a few months, we are already reap­ing the ben­e­fits of it.

Combining and Querying Data

On my team Hudl, we are tasked with build­ing tools for users (exter­nal and inter­nal) to sign up, invoice cus­tomers, track rev­enue, and man­age cus­tomer accounts. The biggest con­cern for our team is data integri­ty among numer­ous exter­nal sources. Our sup­port team is work­ing inside of an inter­nal admin site, sales team is work­ing with Salesforce, account man­age­ment with Zuora, and busi­ness devel­op­ment team with Netsuite. Several times a day, these sources can be updat­ed and we have to ensure ever-chang­ing data is con­tin­u­al­ly in sync among all of these depen­den­cies. While man­ag­ing all of this out­side data, we also have to be con­sci­en­tious about main­tain­ing rela­tion­ships in our own SQL tables and MongoDB collections.

So we have a lot of data — but why does that mat­ter for GraphQL? Our teams at Hudl are all run­ning their own microser­vices, and we have to ensure this data is con­sum­able by our own client and oth­er back­end ser­vices. By using GraphQL, we only have to man­age one route and one schema for all of our data. As we pop­u­late this advanced schema from dif­fer­ent data sources, GraphiQL (Facebook’s in-brows­er IDE for explor­ing schemas) effec­tive­ly gen­er­ates API doc­u­men­ta­tion for our con­sumers, and pre­vents us from spend­ing pre­cious cod­ing time on documentation.

Combining and Querying Data

A great improve­ment that GraphQL pro­vides us with is the abil­i­ty to use a com­mon query lan­guage amongst sev­er­al dif­fer­ent sources of data. We can access, mod­i­fy, and query all of the tables below (and more!) in a sin­gle GraphQL call, reduc­ing the num­ber of touch­points and laten­cies for the consumer.

Importance of Caching

When you’re able to com­bine all of these sources of data, it’s easy for your queries and muta­tions to give poor per­for­mance. For our exter­nal depen­den­cies, it’s com­mon to see 100 – 200ms laten­cies on every request we send. Some muta­tions and queries may require 10 – 15 requests to var­i­ous end­points. These long delays high­light the need for an effec­tive caching lay­er. This means you have to eval­u­ate the impor­tance of every data source in each query and mutation.

Picking Your Payload

Another ben­e­fit of GraphQL is the con­sumer con­trolled pay­load sizes. The con­sumers of this data can choose which spe­cif­ic val­ues they wish to retrieve. Consider the invoice object below shown in GraphQL below:

It might make sense on a billing page to seri­al­ize and dis­play all of the infor­ma­tion above about a customer’s invoice. Although, if a con­sumer want­ed to check the name of a pack­age, we wouldn’t want to have to return all of the data that’s use­less to them. The con­sumer can choose to receive only the fields they desire, which pre­vents extra seri­al­iza­tion. Consumers get to bask over small per­for­mance gains, and we get to rejoice; real­iz­ing that we don’t need to write anoth­er REST end­point to han­dle sep­a­rate payloads.

Front-end clients see even more ben­e­fit from choos­ing their own pay­loads. With GraphQL, we can sim­pli­fy the work need­ed to stand up a new page that requires a dif­fer­ent sub­set of data from our schema. No new mod­el cre­ation or route con­fig­u­ra­tion is nec­es­sary on the back­end. You just send a request to the same GraphQL end­point with dif­fer­ent query para­me­ters. We use Lokka on our team to do this, which is a sim­ple JavaScript client for inter­act­ing with GraphQL.

Wrap-Up

We’ve seen a lot of ben­e­fit by expos­ing all of our APIs through GraphQL. As devel­op­ers, we spend less time wor­ry­ing about API doc­u­men­ta­tion. Any con­sumers are able pick spe­cif­ic pay­loads from com­pli­cat­ed data objects. Our front-end is able to inter­act with all of our data sources through one com­mon query lan­guage. Even though we have lots of exter­nal depen­den­cies, through effi­cient caching we have seen respectable per­for­mance and have writ­ten much more main­tain­able code. If you haven’t start­ed using GraphQL yet, I’d urge you to at least try it out.