Skip to content

Latest commit

 

History

History
50 lines (29 loc) · 5.1 KB

1. What is GraphQL.md

File metadata and controls

50 lines (29 loc) · 5.1 KB
Raw

Part 1: What is GraphQL

  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
|                                          |
|   The dirty secret:                      |
|   We’re all just building CRUD apps.     |
|                                          |
|                          @iamdevloper    |
| _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|

While giggling at the funny tweet, you and I both know that it is not that simple. If you are a developer and haven't been in a cave for last few years, you have seen the rise of complex single page and mobile applications in general. While developing both, sometimes I feel that we probably have entered the "client-side heavy" era without much of prior preparation. There have been a lot of confusion, experiments, thrill in how to cope up with the changes, how to structure code and the flow, how to be on the edge of performance, but with all that, we seem to have overlooked some basic things repeatedly. Data fetching is one of those things.

Most of us are using REST APIs for that. While meeting our needs for most of the times, it also made our front-end developers to frequently figure out why some properties are missing in the JSON response they got from the API, what's changed in the last sprint, why some shit is not in the API documentation. Our back-end developers are constantly trying to cope up with the nitty gritty changes in dozens of client side applications and their numerous slightly different version that depend on the API. For years, we took this miserable life for granted.

Don't get me wrong. REST is of course simple, there is almost no learning curve. Here is your resource, ask for it politely with the proper verb, be sure to check your status code and be done with the body. It blends perfectly with HTTP. I was a kid building native desktop applications when the world was cheering to move from SOAP to REST, XML to JSON, Configuration to Convention, so I didn't take much notice on the web. But I can feel the excitement of those times just by looking at GraphQL.

I think the main problem of REST is that it tried to blend too much with HTTP instead of focusing on the nature of our data. Maybe that's because it came from a time where most complex data mingling was done on sever-side and the client was served with properly rendered pages. Things have changed. Restaurants became grocery shops, they now serve raw ingredients and assume their clients are new chefs, they know how to cook and prepare a presentable dish. Imagine a real-life communication between a chef and grocery market, that is much more chaotic than what's going on between a customer and waitress in a restaurant. Same goes for SPA and Mobile Apps. Some tooling became long due to cope up with the change.

If you look close enough, most of our data is connected like graphs. You cannot just get away with an author's data, you need information about the books they have written. You cannot talk about a TV Show without talking at all about its episodes. A good dish has complex taste by requirement. The same goes for a finished product, it is never as simple as individually lived resources.

The first step to solve a problem is to acknowledge that it exists. GraphQL (fortunately) does so for us. And not just that, it also agrees that product designs start with views, so front-end engineers should be able to declare what data they need instead of waiting for the backend guys to make necessary changes in API for them. The world needs to move faster. REST was failing to cope up with that, elegantly.

There are more actually. Read GraphQL Introduction to feed your curious monster. Watch the announcement on React Europe 2015 Conf, and a deep dive to it.

The official site is here: graphql.org

What GraphQL is not:

  • GraphQL is not for any specific language or framework. Although the reference implementation has been released in JavaScript, the GraphQL core is expected to be ported to all major languages.

  • GraphQL does not assume any specific data store (just because it has "QL" in its name, don't assume anything similar to SQL). You can use relational, non-relational or other REST style backends as your data source. The job of the GraphQL server is parsing, validating, providing data and mutating (updating) it based on clients' requests.

What GraphQL is:

  • It is Declarative:

Query responses are decided by the client rather than the server. A GraphQL query returns exactly what a client asks for and no more.

  • Compositional:

A GraphQL query itself is a hierarchical set of fields. The query is shaped just like the data it returns. It is a natural way for product engineers to describe data requirements.

  • Strongly-typed

A GraphQL query can be ensured to be valid within a GraphQL type system at development time allowing the server to make guarantees about the response. This makes it easier to build high-quality client tools.

We'll discuss them as we go through the series.