Ask HN: How has GraphQL panned out for your organization?
I didn&#x27;t choose to adopt GraphQL, but I joined a company where an ex-developer had integrated into what was at that point a core codebase. They didn&#x27;t add it due to any particular merit, they just wanted to play with shiny new technology. The codebase also had REST endpoints, but GraphQL made up the majority of the API, so we decided to just run with it and deprecate REST. At the time the decision we made was arbitrary.<p>This turned out in retrospect to be a good call. The primary consumers of the API were a set of Android and iOS apps, and integrating GraphQL into mobile apps is a pleasant experience. You can generate your data models from the graph schema. Tools like GraphiQL allow developers to explore and play with your API, substantially reducing the amount of documentation needed. The mobile team much preferred working with GraphQL over REST.<p>On the backend, GraphQL has a bit of a learning curve. The resolver pattern is powerful once you understand how to use it properly, but also easy to misuse. The most common source of problems is developers not understanding Graph&#x27;s batch resolution mechanism. Developers accustomed to building REST APIs rely on preloading data, which is the wrong approach when dealing with GraphQL.<p>As a simple example, maybe you initially build a Graph query where you load comments like this:<p><pre><code>  query Comments {
    user {
      posts {
        comments {
          message
        }
      }
    }
  }
</code></pre>
But later on, you decide you want to allow a user to load their comment history directly:<p><pre><code>  query Comments {
    user {
      comments {
        message
      }
    }
  }

</code></pre>
In the first example, an equivalent REST API might load comments via something like <i>posts.preload(:comments)</i>, and when the second query is built you&#x27;d use <i>user.preload(:comments)</i>. But the way to solve this problem in Graph is batch resolution - get a list of comment IDs you want to load, then call <i>Comment.where(id: comments_ids)</i>. Your comment loading is now context agnostic.<p>Another related problem is that it is easy to create N+1 queries. This also stems from a misunderstanding of batch resolution - reusing the above example it would be the equivalent of calling <i>Comment.find(comment_id)</i> for each ID instead of <i>Comment.where(id: comments_ids)</i>. My first few months working with Graph were often spent fixing N+1 queries. As much as I try to explain this problem to new developers, it&#x27;s one of those things that doesn&#x27;t click for them until they cause the problem and end up having to fix it.<p>Once you understand GraphQL it&#x27;s a nice technology to work with. In the early stages it can be fairly easy to shoot yourself in the foot, you just need to build up enough knowledge to avoid the common pitfalls. In general, GraphQL APIs are harder to build than REST APIs (mostly because REST is the default for most frameworks). If I had to start a new project today, my decision on whether to use GraphQL would be be determined by questions such as:<p><pre><code>  1. How much control do I have over the clients
  2. Are the primary consumers native mobile applications 
  3. Is flexibility important
  4. Will API documentation be required</code></pre>