Skip to main content

Why 'Now' is the best time to start GraphQL


You're probably really happy making APIs and Websites the way you do currently. But something is out there which really deserves your attention!

What is GraphQL?

No, I won't repeat the definitions you've read over and over again. I like to explain through examples.
So consider the following analogy for Routes:
Think of the GET & POST Routes in your servers as actual paths (routes). Let's say you are in your workplace, and you want to GET a book from your home. So you follow a particular path to go down to your place, and return with the book. Now let's say you have to keep a bag at home. So you run down to your home through a specific path (route), keep (POST) the bag, and return with/without something back to your workplace. 
Now what you're really doing is, for both the cases, you are choosing 2 different paths. To get something else from your home, you'd choose another totally different path to do it. This is what traditionally happens with APIs. There are different paths (routes) for each information retrieval or transfer. 
So what does logic say? If I always have to get to the same place, why am I choosing different ways to get there?? Why can't I just have 1 defined path, and every time I reach home, I look for the stuff that I want to find, and get back?! 
Yes! That's exactly what GraphQL is! (To be honest, this analogy sometimes makes me sad for not thinking of this on my own). 
Anyway, that's probably the best explanation I could come up with for GraphQL.

Now to seriously answer the what: It's basically just a query language. You have to define all the data and fields which a request can access, and that's it. Unlike REST APIs, you don't serve, from a server. You simply keep the data in the plate, and whatever the front end application wants from it, they take it.

Why GraphQL?

Although you're convinced, here's another reason for you to try this out:

Better Structure

Better Structure of? Your Project, DB Models, and your code.
Here's a real story: Just a few days ago, I was developing an API where I had to store a collection of Teams, and a collection of their Events. On one request, the entire list of Teams would be returned. Then from that list, a team's _id would be sent as a POST request, which should return all the events organized by the team. 
Not much of a problem. I simply created 2 collections, and made sure I added a by field in the Events Schema which would store the organizing team's _id. So the querying part for both the requests was done in about 20-25 lines of code in Node.js. Great, everything still works fine!

Now let's look at what would have happened in the case of GraphQL
1. I could combine those 2 routes in one.
2. I could have created a GraphQL Structure(Schema) where:
teamName:
_id:
events: [{
             ...all-info-about-that-event
             }]
3. When the request would be to display teams list, all the list would arrive. Of course, they would only request for teamName and _id, since that what the user currently needs, and events won't be sent in the response. GraphQL takes care of it. And when the application would need events, it would send in a query with the team's _id, and that's it!

Of course, as you might have guessed, we would have to define 2 different queries too in this case. But the work is relatively much simpler since we would now store the data in our DB Schema too in this way. The entire project is now much simpler to visualize, and easier to code.

Some developers might argue that I could have had the latter DB Schema initially too, and modified the MongoDB's query result object in my server response. But all the lazy ones would understand why I did the way I did it.

A New Adventure 

GraphQL is relatively new, and though it has many Github forums quite active, chances are you won't find your answers to your doubts and errors as easily. If you think that you could fumble on a mysterious error, and google it to find 100 other developers who had the same problem months ago, nope, that won't be the case. Its support is not as huge as Node or MongoDB's but that's the biggest adventure! 
The easier it is for you to find your errors, the more mainstream is your sub-field.
This is assuming that you possess the Developer-Ability-of-Googling.
Anyway, the point is, venturing into something new would just make you a better, more experienced developer.
Kill the boy, Jon. And let the man be born!  
I faced a lot of problems while making a project using GraphQL, but fortunately, I documented all of it so I have an answer to such errors in the future. Here's my coding log.
P.S.: Please don't judge me by my silly mistakes!


I've made some pretty bad mistakes while coding, but also found some things which weren't very clearly available in the documentation, or the web.
GraphQL is not too much in vogue, yet not so under-developed so as to frustrate the developers. The time to jump in is ripe guys!

How to Begin?

If you want to start the way I started, there's no one better in teaching the basics than this guy - Net Ninja, and his quick tutorial on GraphQL. Of course, since it's a short tutorial, you won't get to know everything, but it'll give you an idea of the basics of GraphQL, & you'd be good to further your knowledge by reading the docs itself. Oh, and by the way, how do you know that a good team is behind this?
Because they make pages like these: Learn GraphQL.

You don't need anything to start. Just a bit of Node, some experience in API Dev, and you're all set to shoot!






Comments

Popular posts from this blog

Namaste JavaScript Quick Notes

Note:  Akshay Saini's Namaste JavaScript is probably the best course for JavaScript developers out there. These are my personal notes that I made while watching the course; they serve more of as an online quick reference for my understanding and revision, and I hope it benefits anyone reading it too! Everything in JS happens inside an Execution Context. Before a JS code is run, memory is allocated and variables are set as undefined   , and functions are set as their exact code in the scope within the Execution Context. The global execution context hosts all the global variables and function definitions. An Execution Context has 2 components: Memory, that stores variables and functions; and Code, that reads and executes the code. Call Stack maintains the order of execution contexts. Since JS is single threaded and asynchronous, at one point of time, only one function is executed which is at the top of the call stack. For each function, an execution context is created before executi

An introduction to APIs

API is an acronym for Application Programming Interface. Let's start with first defining some basic terms: Browser: These are browsers. To visit any website on the internet, you need a browser. Server: Hmm, this is tough. In simple words, server is a computer. Yes, just like the laptop, or PC at your home. The only difference is that it does not have a screen. Of course, there are other differences in technical specifications, but at its core, the server is just, simply, a computer. That's it. So why is it called a server? Because it serves . When you go to a website like google.com , your computer connects to the internet and gets you your search result. But your computer's internet connection has to get that result from somewhere, right? If the google search result is giving you some answers, the answers have to come from somewhere. What is that place? The answer to that some place is: a server. When you click on the search button on google, or hit enter after typing, &q

Review: Nestjs - Finally a scalable way to build APIs

I have been thinking about this for a long time. There HAS to be a defined way to build APIs in a scalable way.  If you have used Node, Express, etc in your side projects, you might have felt that after a point in development, debugging truly becomes a pain. Sure, enterprise-level API codes are great. But a lot of times, these configurations are too much, and probably not even needed in other projects. To be honest, I haven't seen a lot of Open-Source API codes either to make a judgement on how experienced developers build their APIs. Anyway, I came across an amazing framework recently, and I think if you are coding a complex API, this should be your way to go. Nest.js Nest.js is a framework for building efficient, reliable and scalable server-side applications.  You essentially break your APIs into controllers, services, and modules, which allow you to modularize the smallest of functionalities in your endpoints or the API as a whole. Why is modularizing important? As I have talk