Architecture : What will happen when we misuse GraphQL – VincenTalk – Medium
Now GraphQL shows us its own way to build API. The developers do not need to care about how the clients will use their API, the only thing they need to do is describing the structure of resource, and implementing the resolve function of each field. And in order to solve 1-N problems caused by the query of nested resources, Dataloader uses a trick of async to combine all fetching to one resource to a batch query.
Now, the API developers focus on the design of the structure and the implementation of each field and use cache and DataLoader for better performance. But one day, we receive a user feedback that they open their website with a timeout. It’s not difficult for us to track the request and query, but how can our backend developer to solve it? With the consisted log system, we find Front End developer use a kind of query beyond our expectations. But, we even never think about the way others will use our APIs when we developing with GraphQL. Front End developers took over the decisions of the performance, and since we are not building our API for each use case, it is truly difficult for us to optimize our project for a user operation. We refuse to use a hard code for this special condition in our fields oriented system. And take cache hit ratio into consideration, we can not keep using cache everywhere.
