Introduction to Design Systems: Key takeaways from our webinar
We're sharing the key points and insights from the first in our three-part webinar series on Design SystemsRead more
Since then, we’ve shipped several big, successful projects with React at their core. Some of these have been for financial businesses, others have been full-blown cross-platform mobile apps developed using React Native. We’ve also had hundreds of hours of experience fetching and sending data with React, for one purpose or another.
Typically, this kind of back-and-forth app-level communication has relied upon pretty commonplace RESTful API standards. Data is requested from a remote system, and a corresponding data set including the specific data we need is sent back for our React code to chew over and display appropriately.
With the continued rise of mobile – both in terms of browsing from your phone as well as using a dedicated app – this continuous draw of complete data sets is generating millions of requests per second worldwide. But with REST, these requests may not always be working at their most efficient.
The problem is that RESTful APIs, typically, return a fixed set of data only relevant to one particular screen or perhaps one specific use case. But your app may only need one sibling out of the whole group that comes back, or a different mixture of information using data from multiple areas.
Incidentally, this very common “spread” of related information about one item in a database – such as a product for sale, or a user’s complete profile detail – is known as “the graph.” GraphQL actually stands for “Graph Query Language” because it lets you write succinct requests for granular data across the entire graph. This makes it an excellent fit for Agile working practices, allowing engineers and product owners to iterate designs much more quickly than traditional “fixed response” RESTful APIs.
One scenario we encountered most recently with this was when a user first starts by browsing a client’s collection of products, then requests full details of a specific item associated with that collection. Using a RESTful API to feed the app, every time the user requested granular information on a specific item, behind the scenes we were receiving noticeably more data than the user actually needed.
In conversational terms, it might look something like this:
“I’d like to know about this specific item from that collection.”
“Okay server, we need Item X from Collection Y.”
“Here is Collection Y, which contains Item X.”
~muttered grumbling as the app code sorts through all the Collection Y data to find everything the user wants about Item X~
~turns out that some of the information the user wants about Item X is spread across multiple Collections, so the app has to request every related Collection sequentially, then sift and combine all the Item X together as necessary~
“Okay user, we found everything about Item X for you and here are the complete details.”
Pretty inefficient, isn't it? And the above assumes everything required to show Model X in detail all came from a single REST endpoint – often this isn’t the case, so sequential requests need to be made and progressively glued together, before the complete data ‘picture’ is ready for the User.
This scenario is a common flaw with RESTful APIs, and it’s one that’s becoming increasingly unpalatable for clients, customers, and network operators alike – especially when bandwidth, speed, or network availability are at a premium. To that end, a number of development groups have been looking at how we could streamline – and therefore greatly accelerate – network data requests in today’s always-on, always-available environment.
One solution that’s rapidly growing in popularity is, appropriately enough, Facebook’s GraphQL data query system. GraphQL fixes our particular scenario by allowing app developers to very specifically request a partial “slice” of data in a single transaction. This takes the form of a custom GraphQL interface layer that needs to sit in front of your client’s data, often powered by Node. GraphQL then takes in a relatively simple expression from our app, finds only the relevant data for you, and returns it to the app in a matching format.
The biggest benefit of GraphQL in this scenario is that, for a developer (or an App), you’re only getting back exactly what you asked for. The benefit for users is that they’re potentially consuming a lot less of their data plan over time, and network operators are less choked by handling bigger requests that could contain lots of redundant data.
Unsurprisingly, GraphQL works especially well with high volume, low data scenarios, like social media. But it’s also potentially very useful for apps that deal with granular customisation or order tracking, where the amount of data is small and incrementally sent.
One potential problem to overcome with GraphQL, however, is security. GraphQL has no concept of what data should be locked behind a login versus that which is publicly accessible. GraphQL is only concerned with servicing requests for data as quickly and efficiently as possible. This means that choosing GraphQL requires some careful architectural design decisions ahead of time. GraphQL doesn’t come with any authentication model out of the box, so your app security and website backend needs to be structured to account for this – it’s not a drop-in replacement for any existing RESTful APIs you may have.
However, when deployed in the right scenarios – and with the appropriate security structure – GraphQL could provide a noticeable jump in performance for your customers, and even reduce costs for clients and service operators in the long term.