LinkedIn Literally Stops Spamming APIs

They were creating too many

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

1. 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.

2. 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