GraphQL has become the most loved tool for API development in a very short span of time, and developers across the world cannot seem to get enough of it. Today I met with the founder of Windsor.io, Pranay Prakash, who has worked on the team behind GraphQL during his time at Facebook. I chatted with him to find out more about his experience working closely with Lee Byron, the creator of GraphQL, and some of GraphQL’s benefits. According to Pranay, when he first came across GraphQL he was intimidated by its wild ideas, but eventually became a huge advocate for it. “REST APIs were pretty much the norm till a few years ago, and I honestly didn’t think we could do much better. Lee and I weren’t on the same team, and we didn’t even work on the same project for a while. I simply sat across from his desk when at Facebook, and knowing who he was and watching his talks in the past, I was pinching myself in shock every day. Over time I began to read some of his code and began asking him questions and pitching him ideas of my own. It took weeks before I got to work with him more closely, and he taught me a lot along the way.” According to Pranay, there are several reasons he never went back to using REST APIs again: Generated Typings and Documentation Because every GraphQL server has a predefined schema, it’s possible to generate a type-safe client for every programming language - this saves you a ton of headache by catching (type-related) errors before code ever gets shipped to production. IDEs can take advantage of the schema to show developers valuable documentation. Static types have been around for decades across popular programming like C++, Java, and Rust. It brought all the same benefits of catching errors before shipping code to production and empowering autocomplete features in IDEs, but those benefits didn’t exist when different systems had to start talking to each other. With microservices being all the rage in the last decade, GraphQL solved that problem and brought the benefits of a type system to networking. N+1 problem (a.k.a over/under-fetching) The major benefit of GraphQL is that we can retrieve the exact data we need from the API. You no longer have to rely on REST endpoints that return a fixed, predefined data structure. GraphQL solves two problems commonly associated with REST APIs: over fetching and under fetching. Over fetching is the retrieval of data that is actually not needed. It drastically reduces performance as it increases the time it takes to download data from the server. Meanwhile, Underfetching is the opposite of over fetching and means that not enough data is included in an API response and the client needs to make follow up requests to get the necessary data. This results in the infamous N+1-request problem, a situation where an endpoint returns a list of n items, but follow up requests have to be made for each of those items to get any useful data. “Take, for instance, an app that only wants the name for a given user. A traditional REST implementation would include a `/profile` endpoint would fetch and return plenty more data for the user than required. One solution to this problem is where an API can return a small profile object along with links to fetch more data about the user, for example, what groups they belong to, or their friends.  However, this means that when you actually do need that data in a different part of the app, you need to make additional requests/round-trips. You need to fetch the user, and then follow up by making extra fetches to get the name of each of their groups, or the profiles for each of their friends. GraphQL solves all this by letting the app specify precisely what data they want, allowing the server to decide how best to query just that without any additional overheads” said Pranay, who has been using GraphQL to solve problems just like this for more than 3 years. API management and versioning For every new use case/feature on an app, we usually have to create several new REST API endpoints. Some of these can sometimes be so specific to the new feature that they just return the same data as a previous endpoint but in a different format or with a few changes. Over time this becomes a mess to handle, and we tend to create new “versions” of an API, where we can use a single endpoint that returns a uniform data object, useful for more than one feature. The larger the app, there are more endpoints and versions to manage, which just makes the problem worse. “Getting rid of old versions isn’t easy either because people may be running an early version of an app that relies on an old data format, and so the problem of maintenance just gets worse” said the 22-year-old innovator and entrepreneur. According to Pranay, when the data and its relations are represented as a graph, it facilitates numerous applications and features since it’s easy to simply add new fields to an existing data type, or new connections (edges) within the graph which enables new features without breaking any existing code. Older apps can just continue requesting data in the old format, and the latest version of the GraphQL API can support it without any hiccups. A pleasant developer experience that enables rapid prototyping Pranay, who has developed numerous APIs over the years using GraphQL, both at Facebook, and at his startup Windsor.io, stated that GraphQL makes the life of  a frontend developer much easier. “Thanks to GraphQL client libraries (like Apollo, Relay, or Urql), frontend developers are getting features like caching, batching, realtime and optimistic UI updates basically for free — features which have required entire teams dedicated to working on, and maintaining them in the past” “We are product people — and we designed the API that we wanted to use to build products based on lessons from years of experience,” said Pranay, whose own startup Windsor.io uses API to track and collect consumer data for analytics to help businesses, especially early-stage startups, understand their customers’ buying behavior. Such platforms using GraphQL like his can be used by teams to improve their product and provide the highest quality customer service.

The Graph

Facebook

Fetch

Is GraphQL Still a Thing in 2020?

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

AI in Real Estate: Helping Agents Drive Sales

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

10 Threats to an Open API Ecosystem

10 Indications That You Should Invest in Automation Via APIs

10 Best Practices for Securing Your API

AI in Real Estate: Helping Agents Drive Sales

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

10 Threats to an Open API Ecosystem

10 Indications That You Should Invest in Automation Via APIs

10 Best Practices for Securing Your API

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps