Studying by writting

I am preparing to land a job in the next months, so I want to review the basic, and not so basic, concepts of all the stack I've used along my working experience since Vanilla Javascript, Node JS, GraphQL to MongoDB and AWS.

A very helpful way to study and learn for me is to write down what I read, as well as to build examples so I tought that if I am doing that anyway, it is a good idea to share it. Let' see how it works.

At the moment, the topics that I know I have to review are:

Table of contents

• GraphQL and RESTful API's difference
• Tracking MongoDB document changes with NodeJS
• GraphQL pagination
• Defining AWS Architecture

GraphQL and RESTful API's difference

First, from my point of view, a definition of a RESTful API is the way a server expose its data and it makes stateless transfer. There are 5 fundamentals of the REST architecture: 1

1. Everything is a Resource:

   • Is important to think in terms of resources instead of physical files. Client has access to the resources over some URI.

2. Unique identifier:

   • In REST, every resource should be represented by a unique URI.

3. Simple and uniform Interfaces

   • To send and request data to those resources, HTTP methods are used to replace a list of English-based methods like GetCustomer. In this case, we need the URI that represents the resource (www.mysite.com/Customers/1234), and the GET method.

4. Representations:

   • In the requests/responses from/to the API, what actually we are sending are represantations of the resource data, which could be XML, JSON, etc.

5. Stateless:

   • Each request is independent to the others.

Let's imagine a page where the name of a blogger, the titles of her blog posts and the last three followers has to be displayed.

In order to accomplish the task, three different GET fetches have to be done:

/users/<id> //To get the user name
/users/<id>/post // To get her posts
/users/<id>/followers

With GraphQL, you should think in graphs, not in endpoins, as Lee Byron, co-inventor of GraphQL, says in his Lessosns From 4 Years of GraphQL. [2]

A query with GraphQL to accomplish our hypothetical task would look like the following:

Query {
  User(id: "exampleId123") {
    name
    posts {
      title
    }
    followers (last: 3) {
      name
    }
  }
}

And the response for that query looks like the following:

{
  "data": {
    "User": {
      "name": "Mary",
      "posts": [
        { title: "Learn GraphQL today" }
      ],
      "followers": [
        {"name":"John"},
        {"name":"Alice"},
        {"name":"Sarah"}
      ]
    }
  }
}

As we see, one simple query with the POST method can retrieve the information with the exact data, which could be very difficult to implement with a RESTful API.

Some problems that we are solving with GraphQL will be the following:

• Overfetching: When a query is made to get just specific data but the response is complex and with an specifica data structure.

• Underfetching: In order to complete the information, a second query has to be done. This issue is known as the n+1-request problem.

• Rapid Product iterations on the Frontend: A common pattern with RESTful APIs is to structure the endpoints according to the views, so if the front end changes, backend has to change also.

• Insightful Analytics: Queries and resolvers performance can be monitored.

  • Schema and type system: GraphQL use the Schema Definition Language to define the schema of an API based on types.

I am just watching the GraphQL documentary and they give a great explanation: [3]

Think APIs as a vending machine.

To get information, you put a quarter, push a button and get a product, so if you want many products, you have to push so many buttons. Then, REST come to the scene and try to figure out which products belong together, so the machine vending is programmed in order tu push a button and get any ammount of product that the vending machine owner decides, and maybe it returns some spare change in order to get more products.

Now GraphQL comes to the vending machines and bring the hability to the client to decide which buttons to press in order to get multiple products at one time.

I am gonna stop here this post and for sure I will continue with practice and snippets.

Hope you like it!! And if so, keep the conversation on Twitter