I think Apollo (and GraphQL) is overrated

Disclaimer: If you haven’t tried it, don’t let this article dissuade you, this is just my personal feelings.

It is wayyyy (*1) too opinionated. And for what, a mediocre overhyped client interface with an brand new smell? I often find myself spending hours trying to figure out ways to remove or modify it’s opinions. Also, let me preface (*2) this with, I’ve only been using it for about a month, so this is purely an initial (and probably a bit hasty) reaction. I’m not saying it’s bad, it DEFINITELY has some good use cases, but it’s not an end all REST replacer like some people claim it to be. (Facebook’s marketing is incredible)

When it comes to its heavy opinions, take for example Apollo’s automatic cache, sure it’s nice, but when dealing with mutations and subscriptions, it can become a quickly nightmare. And you basically have two ways, from what I’ve found, to incorporate graphql querying into your components, and both are basically Higher Order Components. And both are kinda messy ways, one where you have a giant render-prop function in your JSX, and the other is a basically a giant configuration file (I like this one way better tho). I’m sure if you really schweefed it, you could incorporate it’s querying into some cool async libraries, but that kinda defeats the purpose a little bit.

Currently I’m using it to build an Event Management App where users need to receive live updates to their phones. The problem comes with the user also being able to send mutations. Every time you have a mutation, you need to manually update the cache, which is frustrating because the cache is implicitly handled, and therefore you have really no visual mapping of what it looks like. And then add on-top subscriptions, which you also need to handle in your internal cache, and it quickly becomes messy. The internal cache makes it very hard to debug as well. Sometimes things are better left explicit, like what your internal state looks like. It may be more code, but it’s 100% more readable.

And this might be my inexperience (this whole opinion might be because of my inexperience), but I’m not sure how valuable it’s client-side caching is, because it can quickly become stale data. And if it’s data that can be stale, ie. static website data, it’s probably cached (or should be cached) on the server/your browsers anyway.

I will say the web-sockets and subscriptions are really cool, but again, are so funky to handle sometimes. Implementing web-sockets now-a-days is not that bad either (firebase thank u).

All that said, there could be some potentially awesome use cases, and my App is just not the correct one. I know for a fact that it is a great idea to use if you are building only an API for your clients to interface with, as it gives them an additional layer of flexibility to interact with. However, if you are building both the API and the client, then it becomes a hassle to deal with. It becomes unnecessary, because you know the exact data to serve. When you can control the API, you have all the flexibility you need to send the correct data, and therefore don’t really need it on the frontend.

All I’m saying is that I think that is overrated. It provides all these opinionated ways to do things, for the chance at flexible single hit API querying and a implicit cache? Ehh, I just am not convinced. Now, I’m still going to finish my App with Apollo/GraphQL, and hopefully I’ll have come back and write an article ‘Why I Was So Damn Wrong’.

(*1) 4 y’s means I like you ;)

(*2) Might be too late for a pre-face, maybe just a face