 |
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
Post a Comment