GraphQL & gRPC (Part 1)

GraphQL(Graph Query Language) is a powerful query language that has allowed huge organizations, like Facebook and Github, to expose massive amounts of data; gRPC is an open source remote procedure call (RPC) system initially developed at Google. Although these technologies live in extremely different spaces, they can work together and complement each other perfectly.
Through the years, the workhorse for exposing data to client applications has been Roy Fielding’s REST (Representational State Transfer) APIs. As any older developer would know, if you stuck by those API design practices you would be miles ahead of ad-hoc APIs protocols and the verbose SOAP and CORBA. The key improvements were: uniform interfaces, stateless interactions, clear boundaries between client and server, and a straightforward way to be cached.
However, this type of APIs, at the time of writing this article, are 17 years old and are showing their age; especially since they’re cumbersome to customize, version and maintain.
State of Affairs

These days, when exposing data for a client application, we follow a set of well-defined steps. For creating data and exposing simple relationships between objects, we can even automate the process using the CRUD philosophy.
CRUD (which stands for create, read, update and delete), is a way to atomically interact with databases, and when combined with REST it takes advantage of the HTTP verbs; POST for creating, GET for reading, PATCH for updating and DELETE for deleting.
When your application basically puts a spreadsheet on the web (a very high demand type of application, that will in no way die in the foreseeable future), CRUD is the way to go. You can move at an incredible speed, mainly through the use of automated tools and ‘tried and true’ development techniques.
Despite its strengths, there are some decisive weaknesses that can make or break any application made with this paradigm. Those weaknesses become more pronounced when dealing with data that can be best represented as a graph. Examples of that are social networks, purchase recommendations and IT operations data.
A specific weakness relates to resource-constrained environments, such as applications running on slow mobile networks. In this case, there are some options, the first one is to use the traditional approach, according to which you keep the requests atomic and make one request for every single recursive definition. If you don’t have too many recursive definitions, that is not a big problem, but if you don’t keep it in check, the requests can rack up quickly.

The second option is to develop one custom endpoint for every feature in your application, implementing the level of recursion needed for each one, and trimming the unnecessary data along the way.
A third option would be to migrate to a more appropriate representation of this type of data, namely, graph databases. This effort, even if possible, may not be feasible due to service availability issues or the development team’s skill set.
These approaches may waste resources; either development time or end-user resources.
You need to be a member of Data Science Central to add comments!
Join Data Science Central