With REST in mind and an emerging smartphone market, the age of APIs really took off.
There was but one major problem. REST typically returns fixed data structures from predefined endpoints. Mobile applications on the other hand were obliged to find smart UIs for complex process structures.
Facebook was the first company to tackle this problem when developing their suite of mobile apps. The primary challenge they faced was over-fetching and under-fetching of data, which ultimately lead to inefficiencies in performance.
Around 2012, a team of engineers led by Lee Byron created GraphQL to optimize the process of fetching data.
The protocol shines in three main areas:
Flexibility: GraphQL allows clients to specify exactly what data they need in a single query, preventing over-fetching or under-fetching.
Efficiency: A single request can retrieve all the necessary data (including nested or related data), reducing the number of HTTP requests needed in complex applications.
Client-centric: GraphQL puts the client in control of the data, giving developers the ability to query precisely the data they need without depending on predefined endpoints.
GraphQL was released as open source in 20151 and moved under the GraphQL Foundation, a neutral, open governance organization hosted by the Linux Foundation in 2018. The transition ensured its long-term stewardship by a larger group of stakeholders beyond just Facebook.
Today many big brands beside Facebook are using GraphQL, like Github, X/Twitter, Shopify, Netflix and others.
Microsoft wouldn’t be Microsoft if it had created its own API tool under the given circumstances. Read on tomorrow about oData.
About the author
Michael Gerzabek works with engineering teams on system architecture and developer experience in complex SaaS environments.
He writes about the architectural decisions that keep systems understandable long after the first release.