One of the arguments I hear for why API providers should be employing GraphQL is that they should just get out of developers’ ways, and let them build their own queries so that they can get exactly the data they want. As an application developer, we know what we want from your API. Do not have us make many different calls to multiple endpoints, just give us one API. Let us ask for exactly what we need. It is an eloquent, logical argument when you operate and live within a “known bubble,” and you know exactly what you want. Now, ask yourself, will every API consumer know what they want? Maybe in some scenarios, but in most situations, developers will not have a clue what they want, need, or what an API does.
This is where the GraphQL as a replacement for REST argument begins breaking down. In a narrowly defined bubble where every developer knows the schema, knows GraphQL, and knows what they want, GraphQL can make a lot of sense. In the autodidact alpha developer startup world, this argument makes a lot of sense and gets a lot of traction. However, not everyone lives in this world, and in this real world, API design can become very important. Help people understand what is possible, learn the schema behind an API, and become more familiar with an API until they have a better understanding of what they might want. I’m not saying GraphQL doesn’t have a place when you have a significant portion of your audience knowing what they want, I’m just saying that you shouldn’t leave everyone else behind. https://goo.gl/YJMgpm #DataIntegration #ML