GraphQL: From Excitement to Deception

Are you wondering if you should use GraphQL in your project? Do your developers fight over arguments like “GraphQL is the future” and “REST is just simpler”? I had endless discussions with my team that I will summarize here. Disclaimer: GraphQL is trendy, and you will find countless articles about how it’s amazing, but after three years of using it, I am a bit bitter and disappointed by the technology, so don’t take my words for granted. <h1>1. Start With Why?</h1> The first question I ask myself before considering new technology is, “Why should I use it?” For GraphQL, the best way to answer is to come back to the initial problem Facebook faced. The <a href="https://engineering.fb.com/2015/09/14/core-data/graphql-a-data-query-language/" rel="noopener ugc nofollow" target="_blank">original post in September 2015</a> perfectly explains the issue. “Back in 2012, we began an effort to rebuild Facebook’s native mobile applications. At the time, our iOS and Android apps were thin wrappers around views of our mobile website. While this brought us close to a platonic ideal of the “write once, run anywhere” mobile application, in practice, it pushed our mobile-webview apps beyond their limits. As Facebook’s mobile apps became more complex, they suffered poor performance and frequently crashed. As we transitioned to natively implemented models and views, we found ourselves for the first time needing an API data version of News Feed — which up until that point had only been delivered as HTML. We evaluated our options for delivering News Feed data to our mobile apps, including RESTful server resources and FQL tables (Facebook’s SQL-like API). We were frustrated with the differences between the data we wanted to use in our apps and the server queries they required. We don’t think of data in terms of resource URLs, secondary keys, or join tables; we think about it in terms of a graph of objects. Facebook faced a specific problem and built a custom solution: GraphQL. To expose graph-shaped data, they designed a hierarchical query language. In other words, GraphQL naturally follows relationships between objects. You can have nested objects and return all of them in one network call. They built a protocol, not a database. Facebook already had the storage. Each GraphQL field on the server is backed by an arbitrary function that isolates the business logic from the storage. Finally, with users all around the globe, where cellular data plans are not always cheap, GraphQL protocol was optimized for mobile customers allowing them to “only transfer for what they need.” It’s really easy to understand how GraphQL solves Facebook problems. The remaining question is, “Does it solve yours?” <h1>2. GraphQL Perks</h1> Despite solving a really niche problem, GraphQL convinced a large part of the developer's community to adopt it thanks to the following perks: <ul> <li>One request, many resources: Compared to REST where you need to make multiple network calls to each endpoint, with GraphQL you can query all your resources with one call.</li> <li>Exact data fetching: GraphQL minimizes the amount of data transferred across the wire by being selective about the data depending on the client application’s needs. Thus, a mobile client with a small screen can fetch less information.</li> <li>Strongly typed: Every query, input, and response objects have a type. On web browsers, JavaScript's lack of type became a weakness that many tools tried to compensate (Dart from Google, TypeScript from Microsoft). GraphQL allows you to share types between the backend and frontend.</li> <li>Better tooling and developer experience: Introspective server can be queried for the types it supports, allowing API explorer, auto-completion, and editor warnings. You don’t have to rely on backend developers to document their APIs anymore. You can just explore endpoints and get the data you want.</li> <li>Version free: The shape of the data returned is determined entirely by the client’s query, so servers became simpler. When you’re adding new product features, additional fields can be added to the server side, leaving existing clients unaffected.</li> </ul> <a href="https://betterprogramming.pub/graphql-from-excitement-to-deception-f81f7c95b7cf">Visit Now</a>