GraphQL and the amazing Apollo Client
Gerard Sans
2427

I love the idea of GraphQL and Apollo, but there are two things that I am not sure about.

First is that while I completely agree GraphQL makes it easier for front end developers to make changes since they don’t need to touch the back end API, this doesn’t always yield the most performant queries unless you modify your GraphQL implementation to address specific cases (i.e. as opposed to staying totally generic and flexible). I don’t have a ton of experience with GraphQL but it seems to me that to truly get the best bang for your buck, you almost need to have a set of standards for how you organize your data on the back end so that you don’t have to create special one-off queries to deal with certain use cases. For example, if a particular query is no performant is the best practice to modify your GraphQL back end or denormalize data in the actual database? Using traditional REST, I usually end up denormalizing data, but perhaps that is not needed as much with GraphQL?

The second thing is that in general micro-syntaxes within strings are not ideal. This is a discussion that came up during the design of Angular 2 with regard to ngFor. I think ultimately (if I recall correctly), they agreed a microsyntax is generally not good, but having one very small one for ngFor is acceptable since the other options were much worse. In this case, we are talking about using a string-based microsyntax for all our front end queries. As soon as code editors have autocomplete for this then it is not as big of an issue, but I wonder if it is worthwhile in Apollo to create a JSON version of the GraphQL query syntax.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.