Is GraphQL the future?
Let’s see. Generally speaking, it’s the reason you have so many pieces of entertainment instantly at your disposal. Photos. Movies. Songs. All that stuff. And there’s only going to be more as time goes on.
It’s the ‘instant’ part that we’re emphasizing here. It has trouble happening without GraphQL. REST – the world’s query forerunner – can’t handle those requests the same way.
But is GraphQL better than REST? Good question. Here’s a quick rundown on why it could be.
With GraphQL, applications can be structured more efficiently.
What does that mean. Most times, REST has a service that’s built for each type of client used. So if it’s viewable on a TV, mobile phone, and computer – that’s 3 different services. They each have different requirements, expectations and interaction patterns. It takes a lot of processing power for REST to handle those.
GraphQL, however, can consolidate these into a single interface, exposing data in a flexible and scalable way. Regardless of the client. So whether it’s a phone, tablet, or whatever, it doesn’t matter.
Instead of multiple endpoints that return fixed data structures – a common side effect of scaling REST services – a GraphQL server only exposes a single endpoint, and responds with the precise data a client requests:
Just by looking at the images, you can see the complexity issue that GraphQL starts to resolve.
With REST, multiple endpoints mean that the front-end and back-end development teams have to continuously touch base. And when information gets more complex – or anytime they need to add a new endpoint – those teams not only need a ton of communication, they need follow-up with QA to make sure nothing gets lost in translation. Everything gets exponentially longer to ensure the application runs smoothly.
With GraphQL, modern applications are built so that complex back-end applications can supply enough data to run multiple clients through a single, consolidated interface. Web applications, mobile apps, smart screens, watches – they can now function efficiently on a single back-end application.
Precise info in one query
With classic REST, you need to make specific calls. Say you want to get 3 pieces of information. We’ll make the three things 1) a list of restaurants in town, 2) each of the owners, and 3) the top five reviews for the restaurant that gets selected. To get that info, you need to make three separate requests, or calls. Think of it like this:
The issue here is that each piece of data requires its own call to three individual resources.
With separate requests, this may take a while for a computer on Wi-Fi, and take even longer on a mobile device.
With GQL, you can get all that information in one.
With one call we get precisely what we want. From a front-end or client perspective, what we do with this information is now up to us. And if we wanted to include the top review, we already have that data available to show in the browser.
Another thing about GraphQL is that it makes the conversation between server and client less noisy. It takes advantage of exact-data fetching and grabs multiple resources in one roundtrip.
Additional roundtrips call for extra data, which requires more resources to perform.
Why would less roundtrips matter?
From a corporate standpoint, money. As more organizations migrate their applications to the cloud – where scale has a real relationship to cost – anything to consolidate chatty conversation between the client and server has a significant impact on the bottom line.
From a human standpoint, it has a massive effect on your experience. Think about how much data you have access to within seconds. On Facebook alone, you can access photos, friends, comments, friend’s friends, and more. Without GraphQL, you can’t instantly access, say, your friend Mike’s picture album from Halloween 2016. Or think about Spotify. You couldn’t effortlessly flip back and forth between your Zapstep playlist, 70’s Legends playlist, and Suggestions-Based-On-Your-Music-Listening-In-June playlist. You’re able to pull songs or images up so fast you don’t even have to think about it.
And speaking of roundtrips, with REST, one of the problems is the over-fetching of information. Say you put in a query for restaurants, like we did earlier. What you get back is not only restaurants, you get their address, cuisine, location, URL, health grade, ID, and review.
It’s convenient in and of itself. But that return, multiplied by hundreds or thousands, weighs on a machine’s resources. If you now add “owner” as another query to the query above, then suddenly the computer needs to sort through twice as much information because it’s returning not only the original query info, and returning all the info that’s now related to the “owners” query.
Hence the significance of GraphQL. You’re now able to query something like this:
And that’s the exact information you get back. No more, no less.
This GraphQL exact-data-fetching feature is one of the founding benefits of GraphQL. Compare this feature with the conventional nature of REST. As a casual learner you can understand how that makes data return much less complicated. This minimized amount of data lets a mobile client fetch less information, resulting in less endpoints that need to be specified, and faster processes.
From a building-block level, this is why you would need GraphQL. It adds a major improvement to the way apps are built.