The joys and pains of working with GraphQL

This quickly becomes burdensome when you add new resources to the application; however, this same burden is also a feature. The application is self-documenting and it's easy to understand the entrypoints into an application that's being exposed via HTTP/HTTPS. In a large, complex GraphQL applicaton tracking down how clients query the API requires more energy than you would like. There's a lot of engineering discipline required to keep your GraphQL API from turning itself into a REST-like API as a product changes. In the first GraphQL query above, … There are many cases where you might already have a piece of data available from a database query and you would like to "return early," as we've done here but GraphQL makes your pay a tax of sorts for the flexibility it offers. This tax, in large code bases, can grow and become cumbersome. The non-linear nature of dealing with graphs has left me wanting some sort of GUI representation of the graph that lights up as a request moves through each resolver. Was REST so bad that we need to make understanding how our requests are routed more difficult?