Why use GraphQL, good and bad reasons
This is kind of touched on by other comments here, but after using GraphQL heavily on a bunch of different projects for both native apps and web UI front ends, one of the biggest benefits I&#x27;ve seen is how it enables the individual teams (front end and back end) to work faster, more efficiently, and more independently.<p>Our dev process for using GraphQL:<p>1. Product and design come up with screen designs and workflows.<p>2. Importantly, the <i>front end teams</i> then take a first stab at writing the GraphQL type contracts, fully doc&#x27;ed (we use a Node backend, so it&#x27;s easy for the front end folks, even native app devs, to know enough JS to write these type strings). They then confer with backend folks on the contract to get agreement, and front end folks write mock endpoints for these contracts. This allows the front end teams to get off to the races early with a working (albeit mocked out) backend. Since the GraphQL type contracts are optimized to closely match the front end screens, it makes the front ends <i>much</i> simpler. With native apps it also means there are a lot more things we can fix with just a server change, not requiring an app store release.<p>3. Backend folks then start implementing the GraphQL resolvers, which in our architecture is mainly orchestrating microservices. The great thing about GraphQL here is that it essentially serves as a &quot;decoupling layer&quot;, giving the backend folks a lot more freedom to change and switch up the microservices as long as the GraphQL contract is still respected.<p>4. Once the GraphQL resolvers are done, we switch out the mock resolvers. Usually there are a couple of edge cases or other bugs to fix, but for the most part we&#x27;ve seen very little disconnect.