Road To GraphQL read and response: Chapter 1

This entry and the next is going to be hard for me because the first two chapters of “The Road to GraphQL” (TRtGQL) mostly explain what GraphQL and Apollo are. I don’t want these post to be a review of the first two chapters, but at the same time, I think it will best serve you, the reader, to do your own research and, if you’re on the fence instead of reading it by now, start TRtGQL yourself. Really I think I’m going to keep this post short and write about the questions that I had while reading, so that I can get to the next chapter and write about that instead.

The first chapter starts by explaining what GraphQL is. It was created by Facebook because the company needed a way to make custom queries for each of it’s multitude of apps, while also cutting down on a problem called “overfetching,” where api requests were sending and receiving TOO much data, especially in the case of users accessing facebook from mobile apps, which depend on metered connections where every byte of data counts towards a cellphone bill. When graphql reduced data usage and made app queries faster, Facebook decided to share the spec with the world through open source.

Disclaimer: What follows is all still a little bit murky to me, not gonna lie, but I hope to unpack this all. If there’s anything that you, the reader, believe needs further clarification on my part, feel free to tweet me @bxBytesSteph.

GraphQL is not an actual tool, but instead it’s a specification. Because of the prevailing relevancy of JavaScript at the time of GraphQL’s public introduction in 2015, Facebook introduced a JavaScript implementation initially, but as time progresses, other programming language communities continue introduce implementations as well. Wieruch calls this “horizontal growth”, while he deems libraries such as Apollo and Relay “vertical growth,” which I suspect, from my own dabbling with GraphQL, means that Apollo and Relay designate themselves as standard bearers for the GraphQL spec in the JavaScript community.

Aside for the Audience: So if GraphQL is a specification, and Apollo and Relay are the defacto libraries, does a framework like GatsbyJS implement it’s own version of GraphQL? I haven’t seen Apollo or Relay referenced in the GatsbyJS docs.

Continuing, GraphQL as a spec isn’t too involved in opinionation, meaning that developers implementing it aren’t being advised by the spec on where or how to use GraphQL. It’s a simple standard of querying that anyone can adapt to their own needs, regardless of where they find those needs (i.e., backend, frontend, data types/payload formats being used or network layer its being used within).

A GraphQL query can request one or multiple resources at once, called fields. So a potential TLDR answer for what GraphQL is would be:

a query layer that is preset between the backend and frontend where data is previously prescribed for the sake of more efficient data handling for the sake of memory usage efficiency and performance gains

Now, the books goes off into exploring the advantages and disadvantages of GraphQL. A lot of them involve the reasons why I’m here writing this post, and why you’re potentially here reading it. If you’ve watched a youtube video to get your head around GraphQL (I know from experience), you will surely have heard at least a number of the benefits of GraphQL listed in TRtGQL. If you’ve dabbled a bit with GraphQL and used the Gatsby documentation at some point in the last 2 or 3 years you are probably well aware of the first disadvantage in the book (GraphQL Query Complexity). Of course, I implore you to read the book yourself, especially since it’s free to try, and because I don’t plan on rewriting the book here myself. Also I’ve written more than I thought I would already on just the first chapter.

As always, feel free to contact me on twitter @BxBytesSteph