GraphQL: From Excitement to Deception
<p>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.</p>
<p>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.</p>
<h1>1. Start With Why?</h1>
<p>The first question I ask myself before considering new technology is, “Why should I use it?”</p>
<p>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.</p>
<p><em>“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.</em></p>
<p><a href="https://betterprogramming.pub/graphql-from-excitement-to-deception-f81f7c95b7cf">Website</a></p>