Road To GraphQL read and Response Chapter 4: GraphQL Fundamentals

I would like to say that I am developing a rhythm in working through this book, but alas, that hasn’t happened yet. I got caught up in some twists while trying to make it through this first technical chapter of the book, so I’ll cover those here in case someone comes across this series of write-ups so that they don’t make the mistakes I made. I have to say that I learned a good amount and want to keep going because of what more I could possibly learn, though.

In solo endeavors in learning (something you do a lot while learning new technologies), I prefer making it through a resource as soon as possible with the hope of having new concepts stick with an initial barrage of repetition of practicing hands on examples. But because I’m writing a blog series while going through “The Road to GraphQL”, I might try my hand at discussing what I encountered with an (as of now) imaginary reader for the sake of my own learning.

So what terms did I encounter in this chapter?

An object holds data about an entity. It holds the information you want to receive or send out with the hopes of getting a response.

Fields are used to access data from in an object. Fields are what you use to make queries. Yes, you think of fields as input fields normally, right? But there aren’t particular “input fields” in this case. Think of your whole query as an input and the GraphQL “fields” as the input you’re requesting.

Extra exploratory aside: Here’s a question I asked in the “RtGQL” slack, based on my limited use of GraphQL in Gatsby and reading through these few chapters:

Are fields normally prescribed by a given api? For instance, the github graphQL api has a certain fields that it provides access to, right? What if you’re using GraphQL on something  that doesn’t have a GraphQL api?

Yes, they fields are established by a GraphQL api, and in the event that an api doesn’t have it’s own GraphQL api, you can make one by “rolling” your own GraphQL server to handle queries you designated between it and the actual API you want to use.

To make things a bit more complicated as you try to initially grasp GraphQL, an argument is something you can add as a field. I think it might be best to copy the example from the book to illustrate this:


organization(login: "the-road-to-learn-react") {name url}



An alias allows you to make multiple queries using objects that look the same, something you wouldn’t be able to do otherwise because GraphQL wouldn’t know how to resolve two objects that otherwise look the same.

So, now that you can make request data from two identical objects, you’ll probably want to avoid repeating yourself, at least for the sake of saving yourself from the tedium of typing or even copying and pasting the same objects over and over, and also for the sake of readability. Fragments allow you to “extract the a query’s reusable parts” and lets you store those parts in something like a variable.

Fragments have a specific type they should be used on. These aren’t necessarily data-types, but instead differ from GraphQL api to GraphQL api. The book recommends you open the “Docs” of your GraphiQL application, where you’ll see the available types for whichever API you’re using. You’ll see normal “GraphQL types,” like strings and ints and booleans, as well as custom types like “Organization.”

What I just described immediately above is also known as a GraphQL Schema; which is the exposed GraphQL API, or more simply put, the structure of the api.

Variables allows the same thing that variables normally do in programming, which is to store and change a value in a query, whether dynamically or not. In GraphQL, variables are prefixed with the “$” sign.

“Query” isn’t only a term that means something (I’m trying to avoid vocabulary word here), but it’s also a GraphQL keyword, you’re supposed to use it to preface, well, a GraphQL query. You don’t have to in most cases, but when using variables, you must. A shorthand query is what you call a query statement without “query” before it.

So there’s a list of terms from the first technical section of “The Road To GraphQL,” and I hope following sections don’t introduce as many as this one!

Feel free to respond with your thoughts by tweeting me @BxBytesSteph.

Leave a Reply

Your email address will not be published. Required fields are marked *