TLDR;
LinkedIn sells APIs to large companies that use them. The problem is that every company has a different use case.
LinkedIn spammed building a separate API for each use case! It wasn’t sustainable so they used GraphQL to make it sustainable.
⚡ What’s The Issue?
LinkedIn was building separate APIs for each company that onboarding onto their service.
Straight for the official article: Here’s how they were doing it
Define different APIs only when necessary: For use cases with different input scenarios (e.g., search by email, search by schoolId) that lacked reusability, we defined new APIs.
Support projections: For use cases that required different fields to be projected in the response, even if they had the same input, we added projection supports.
Issue with #1: Building only when necessary happened A LOT. Exceptions became the norm
Issue with #2: Monitoring the same API for different responses wasn’t working. There’s just too much to maintain.
🧠 Just GraphQL The Problem Away
LinkedIn had a lot of companies onboarding. They mostly asked for the same thing from their APIs… except the little API changes were too much to handle.
LinkedIn got over this by bringing in GraphQL.
Why GraphQL❓
If someone only wants part of the data, they’re going to get part of the data. Some users care only about LinkedIn skills, others only about the Org and others about members.
LinkedIn gave these business freedom to query whatever they want on their own terms. All it required was writing a GraphQL query and submitting it to LinkedIn to approve.
Was it smooth sailing tho?
❌ Error Handling
From the official article:
GraphQL will always return 200, even with partial errors. With that, it is hard to debug GraphQL services. We have adopted and extended our internal query monitoring tool to further analyze the GraphQL error response, so that we can differentiate whether it’s a server-side error, and are using that for service monitoring. Better monitoring and debuggability will help reduce the future maintenance effort.
My Digestable Summary:
They built error handling on their server to figure out GraphQL issues.
📈 Did it Raise Stonks???
Maybe not stocks but it cut API development time from 2 quarters → 2 DAYS. All that happens now is the new business submits a query for their API use case.
Sometimes just picking the right framework can solve huge scaling problems problems
💰 HELP WANTED
This newsletter has grown to 5000+ AMAZING READERS. It’s grown to a scale that a single person can’t maintain all of it on their own.
If you’re interested in being a byte-sized design writer, reach out directly to hello@alexcancode.io
📝 Official Article
(Links to official article and sources are available to paid subscribers. They help maintain and support this newsletter!)
Keep reading with a 7-day free trial
Subscribe to Byte-Sized Design to keep reading this post and get 7 days of free access to the full post archives.