DEV Community: Sachin Thakur

Securing GraphQL API from malicious queries

Sachin Thakur — Tue, 05 May 2020 19:55:58 +0000

Building graphql APIs have been easy now with all the libraries and online communities around graphql but there must be some questions in your mind. Like how do we actually secure our server, how do we restrict or whitelist only certain queries to run on our server?

Now, if you have ever used graphql you might be aware of the graphql query loop. Let’s see an example.

{
  author{
    name
    books{
        name
        author{
          books{
            name
            author{
              name
            }
          }
        }
    }
  }
}

Now, do you see any issue with the above query type? We can have an infinite loop here and if some runs this query against our server it can definitely crash our server or create a DOS kind of an attack. This is indeed a potential problem if a malicious user can create a very nested query that will hurt your backend. There are many approaches to solve this problem. Let’s look at a few of them.

Size Limiting

One very naive approach would be to limit the size of the query by raw bytes since in graphql all requests are treated as a post request and all queries are a part of the body as stringified objects. Now, this might not work in all the cases and end up hurting your instead as some of your valid queries with long field name might end up failing.

const QUERY_SIZE_ALLOWED= process.env.QUERY_SIZE_ALLOWED || 2000 
const query = req.body.query || '';
if (query.length > QUERY_SIZE_ALLOWED) {
  // logic for handling error.
}

You can run the above code before each request inside a middleware and it will run for each request that is coming into your graphql server and will validate all the queries and reject any query which is too long.

Depth Limiting

Another approach would be to limit the nesting only to a n'th level. You can define to what level you can allow execution of the query and strip our rest of the fields after the n-th level. One really good package to do so is graphql-depth-limit which limits us to define the depth of the query we want to allow on our server. graphql-depth-limit works really well with both express server and koa, and even if you are using the apollo server it can work really well with that too.

const QUERY_LIMIT= process.env.QUERY_LIMIT || 5;
app.use('/graphql', graphqlHTTP((req, res) => ({
  schema,
  validationRules: [ depthLimit(QUERY_LIMIT) ]
})))

Query Cost Analysis

Now, in depth limit, we are limiting the execution of queries to nth level but it might not be suitable for all the cases and sometimes the depth can be a lot less but the cost to compute that query can be very high. This might happen when we are fetching a lot of data in a single query and it’s putting a lot of load on our backend server or database server. These queries might look something like this.

{
  author(first:40){
    name
    books(first:40){
      similar(first:10){
        name
        author{
          name
        }
      }
      name
      id
    }
  }
}

Now even though this query is only two levels deep but you can understand the complexity of this query and the amount of data it will be requesting from the database server and computation happening on the backend server. This issue would not be resolved by either Depth Limiting or Size Limiting. So we need something robust which can handle this kind of queries. So, often in these cases we often need Query Cost Analysis where our server computes the cost of each query and decides whether to allow this query or reject. Now to this, we need to analyze each query before running them on our server and if they are too complex or too expensive we need to block them. Now there are numerous open-source libraries which have been build by some of the really smart people and one of those libraries is graphql-validation-complexity which is really helpful for doing just that. You can separately define complexity for each field like different complexity for scalar types and different complexity for objects. There is also graphql-query-complexity which calculates the complexity based on each field, unlike graphql-validation-complexity which calculates complexity based on the types. Adding query cost analysis using any one of these two libraries is pretty straight forward.

const apolloServer = new ApolloServer({
  schema,
  validationRules: [createComplexityLimitRule(1000)],
});

Now, before you start implementing query cost analysis on your server just make sure your server really needs it otherwise it will just be an overhead for your server and you will just end up wasting resources and time. If your server does not do any complex relations fetching you might be better of without query cost analysis and just add size limiting and depth limiting.

Query whitelisting

Query whitelisting is a little complicated and can be a double-edged sword sometimes. Let me explain it in simple real-world terms, whenever you go to a restaurant every restaurant has a name or number assigned to each dish so that instead of saying the whole name of the dish like “cheese pizza with a double cheeseburger with olives and fries on the side” you can just say “Number 2”, it will save you both time and effort. Now, in this case, you are just saving a few words but you are saving something. But when it comes to requests from your client to your server you can save a lot of request data if you don't send the entire query and just the hash of the query.

This is known as “persistent queries” in graphql terms and save you some data on request and protect your graphql queries against some malicious queries being executed on your server. So, what you basically need to do is compile a list of all the allowed queries ahead of time and check any query against this list. You can even generate a hash for each query and just send the hash value in the request.

https://www.somewebsite.com/graphql/query/?query_hash=ad99dd9d364ewe6cc3c0dda65debcd266a7&variables=%7B%22user_id%22%3A%22221121370912475

The request will look something like the above example. No one can actually know the schema server is running, which query or mutations are being run, it’s just a hash. If your queries are totally static and you are not using some library like relay to generate these queries dynamically this might be the most reliable approach for you. You can even automate the entire process of hashing the queries and putting it inside your production application and you won’t require the query validation on your server since you already know all the queries being run on the server.

But before you go ahead and start implementing Query whitelisting just know a few limitations and analyze will it be good for you or now.

It will be really difficult for you to add, remove or modify any query on your server since now you have to communicate with all your clients and give them new hashes and if anyone runs a query which has been modified slightly will result in query failure.
If you are building Public APIs which are accessible by developers other then your own team, it’s really not a good idea to go with this approach.
Unexpected slight changes in your queries can cost your application to crash if there was ever poor communication between the teams.

Conclusion

To summarize everything we have discussed in this article, I would recommend using Depth Limiting as probably something every GraphQL server should have by default. And after that, you can build on top of that to add more layers and make your server more secure. Query whitelisting is the one case I feel which is for a very specific type of applications and you should analyze properly before implementing it. Other not so talked about approaches would be Query Time out so your queries don’t run infinitely and crash the server. While Query Cost analysis is a little complicated but it protects your server most against the malicious queries.

How to Get Started With a Graph QL, React, Apollo Client, and Apollo Server App- Part 2

Sachin Thakur — Sat, 11 Apr 2020 19:49:59 +0000

This blog is a part of 2 part series, you can find the part one where we create the backend server here. Additionally, you can find the code for the entire tutorial on Github. This series was originally posted on my personal blog. You can find links to both parts below

In the previous part of this blog series, we discussed why graphql is great and how it can help us minimize the data we download and make it minimal by only requesting the data we need. So let’s start building a lightweight frontend and see how we can use Apollo Client to make our react application more efficient.

Setting up React-Apollo Client

Now, here we are going to use create-react-app to create our starter code. create-react-app is a great way to start with setting up a react project and it is built and maintain by the react team so we can expect top-notch configuration for our react application. You can check our create-react-app here.

Now, since we have our basic react starter code, let’s start by adding our apollo-client dependency.

apollo-boost: Package containing everything you need to set up Apollo Client
@apollo/react-hooks: React hooks based view layer integration
graphql: Also parses your GraphQL queries

Now since we are done with adding our basic dependencies we now start by setting our apollo-client to interact with our server. So let's start by creating our apollo-client.js file.

Now let’s create our apollo client so we can start interacting with our backend service.

import ApolloClient from "apollo-boost";

const client = new ApolloClient({
  uri: "http://localhost:4000/"
});

export { client };

Now, the client gives us access to a lot of methods but we are only going to use mainly 2 of them and they are mutate and query .

Now, as the name clearly suggests mutate is use to execute mutations on our server on the other hand query . We also have access to other methods too like localState. Apollo client also helps us maintain the state of our react application so we don’t need redux or any other state management package and we also have access to caching inbuild with the apollo-client package.

Now, we need to let our react application get access to the data which our client can use to build the interfaces. For, that we need to wrap our entire application using the ApolloProvider . The ApolloProvider is similar to React's Context.Provider. And if you have used to react before you might know about React Context. It wraps your React app and places the client on the context, which allows you to access it from anywhere in your component tree. In App.js, let's wrap our React app with an ApolloProvider.

import React from "react";
import "./App.css";
import { ApolloProvider } from "@apollo/react-hooks";
import { client } from "./apollo-client";
function App() {
  return (
    <ApolloProvider client={client}>
      <div className="App">This is a react application</div>
    </ApolloProvider>
  );
}

export default App;

Now, as we have wrapped our entire application with ApolloProvider we can execute Query and Mutation anywhere in our application and get access to the data. Let’s see how we can do that. Let’s create a new file for our tasks and one file where we will write all our queries.

Since we have set up our apollo client and wrapped our entire application with ApolloProvider we can start requesting data with the useQuery hook! useQuery is a hook exported from @apollo/react-hooks that leverages the Hooks API to share GraphQL data with your UI. So let’s get right into it.

First, Let’s create our GraphQL query wrapped in the gql function.

import { gql } from "apollo-boost";

export const ADD_TASK = gql`
  mutation addTask($input: addTaskInput) {
    addTask(input: $input) {
      task
      id
      completed
    }
  }
`;

export const UPDATE_TASK = gql`
  mutation updateTask($input: updateTaskInput) {
    updateTask(input: $input) {
      task
      id
      completed
    }
  }
`;

export const GET_TASK = gql`
  query getTask($input: fetchTaskFilter) {
    fetchTasks(filter: $input) {
      task
      id
      completed
    }
  }
`;

export const GET_TASKS = gql`
  query getTasks {
    fetchTasks {
      task
      id
      completed
    }
  }
`;

Now, we can use these queries into the useQuery hook. When our component renders and the useQuery hook runs, a result object will be returned containing loading, errorand data properties. Apollo Client tracks error and loading state for us, which will be reflected in the loading and error properties. Once the result of your query comes back, it will be attached to the data property. So, we can handle all states of application from object which we get back from our useQuery hook.

So let’s create our first component with useQuery hook and fetch our tasks.

import React from "react";
import { GET_TASKS } from "./Query";
import { useQuery } from "@apollo/react-hooks";

const Task = () => {
  const { loading, error, data } = useQuery(GET_TASKS);

  if (loading) return "Loading...";
  if (error) return `Error! ${error.message}`;
  return (
    <ul>
      {data.fetchTasks.map(task => (
        <li>{task.task}</li>
      ))}
    </ul>
  );
};

export { Task };

Now, we are just needed to add our newly added component inside our App.js so we can see the result. Let’s do that.

import React from "react";
import "./App.css";
import { ApolloProvider } from "@apollo/react-hooks";
import { client } from "./apollo-client";
import { Task } from "./Task";
function App() {
  return (
    <ApolloProvider client={client}>
      <Task />
    </ApolloProvider>
  );
}

export default App;

Now, let's start our backend service and our front end service and see the result.

Now, let's go to http://localhost:3000/ and see what our app looks like.

Now, this doesn't look good to the eyes but you get the idea. We have set up our apollo client and we are able to fetch our data from the database. Now but we have one small problem. On the front page, we are over fetching, we are just using the task name but we are fetching all the id and whether they are completed or not. That’s not good over fetching means we are using more data of user during that network call and we want to save our network bandwidth, in our case, it will be next to nothing but when it comes to big application saving bandwidth means your applications loads faster, it is more responsive and that’s we need to improve the speed of our application. So let’s fix that and remove all the unnecessary fields and make our queries lightweight save some bandwidth. We can do that just by updating GET_TASKS query.

Now after doing that if we go back to our application we see that nothing changed and that’s the power of graphql. You can just ask for the data you are using and save on some network bandwidth.

Now, let's move forward and our second query which will be Mutation to add some data to our backend service. Let’s create a new component inside our src folder to add tasks to our backend.

import React from "react";
import { useMutation } from "@apollo/react-hooks";
import { ADD_TASK } from "./Query";
const AddTask = () => {
  let input;
  let completed;
  const [addTasks, { data }] = useMutation(ADD_TASK);
  console.log(data);
  return (
    <div>
      <form
        onSubmit={e => {
          e.preventDefault();
          addTasks({
            variables: {
              input: {
                name: input.value,
                completed: completed.checked
              }
            }
          });
          input.value = "";
          completed.checked = false;
        }}
      >
        <input
          ref={node => {
            input = node;
          }}
        />
        <input
          type="checkbox"
          ref={node => {
            completed = node;
          }}
        />
        <button type="submit">Add Task</button>
      </form>
    </div>
  );
};

export { AddTask };

Now, we created our component to create Task in our backend, let’s add it to our App.js file and see how it looks.

import React from "react";
import "./App.css";
import { ApolloProvider } from "@apollo/react-hooks";
import { client } from "./apollo-client";
import { Task } from "./Task";
import { AddTask } from "./AddTask";
function App() {
  return (
    <ApolloProvider client={client}>
      <AddTask />
      <Task />
    </ApolloProvider>
  );
}

export default App;

Now see our new Component and let’s add some tasks, and see if it works. Now we add our new task called Add new Task but only after we refresh the page because that's when the re-fetch of the data happens. We can easily fix that but we should be happy because now we are able to interact with both our queries and mutation on backend service and we can do that very efficiently by only requesting the data we need for our front end service.

Now, one more really useful method which Apollo client gives us is called refetch and as the name suggests we can fetch some data again if we feel that data might have been updated so let's see how we can use that method. Now to use that method we might have to do some refactoring of the code. But first, let’s see where that method lives.

Now, where ever we use useQuery we get access to the refetch method. Refetching enables you to refresh query results in response to a particular action. In our case, we can use the refetch method to fetch additional tasks whenever we add our new task. So let’s do some refactoring and move the state one level up so we can pass this method to AddTask component for it to use it. Let’s create another component called TaskContainer and move our AddTask and Task components inside it.

import React from "react";
import { useQuery } from "@apollo/react-hooks";
import { Task } from "./Task";
import { AddTask } from "./AddTask";
import { GET_TASKS } from "./Query";
const TaskContainer = () => {
  const { loading, error, data, refetch } = useQuery(GET_TASKS);

  return (
    <>
      {" "}
      <AddTask refetch={refetch}/>
      <Task error={error} loading={loading} data={data} />
    </>
  );
};

export { TaskContainer };

Now we have moved the state of Task component to a level up and we can pass this state as props to our Task component.

import React from "react";

const Task = ({ loading, error, data }) => {
  if (loading) return "Loading...";
  if (error) return `Error! ${error.message}`;
  return (
    <ul>
      {data.fetchTasks.map(task => (
        <li>{task.task}</li>
      ))}
    </ul>
  );
};

export { Task };

We have our task component unchanged except now instead of having a local state we have state coming from the props. Now, inside our App.js file we just have to import our newly created component and we are almost done with the refactoring.

import React from "react";
import "./App.css";
import { ApolloProvider } from "@apollo/react-hooks";
import { client } from "./apollo-client";
import { TaskContainer } from "./TaskContainer";

function App() {
  return (
    <ApolloProvider client={client}>
      <TaskContainer />
    </ApolloProvider>
  );
}

export default App;

Now, let's see how we can use our refetch method. As you know we have passed that method down to AddTask component so we have access to that method through props. So let’s get into our AddTask.js file. Let’s see what we want to do, so we want to refetch all our tasks whenever we add a new task, so we can add the refetch method inside our onSubmitcall after we have successfully added our new task. Let’s see how that looks.

import React from "react";
import { useMutation } from "@apollo/react-hooks";
import { ADD_TASK } from "./Query";
const AddTask = ({ refetch }) => {
  let input;
  let completed;
  const [addTasks, { data }] = useMutation(ADD_TASK);
  console.log(data);
  return (
    <div>
      <form
        onSubmit={e => {
          e.preventDefault();
          addTasks({
            variables: {
              input: {
                name: input.value,
                completed: completed.checked
              }
            }
          });
          input.value = "";
          completed.checked = false;
          refetch();
        }}
      >
        <input
          ref={node => {
            input = node;
          }}
        />
        <input
          type="checkbox"
          ref={node => {
            completed = node;
          }}
        />
        <button type="submit">Add Task</button>
      </form>
    </div>
  );
};

export { AddTask };

Now, when we go back to our browser and add new task we don't have to refresh our page and we see our newly added task there. Now, I know we could have done it many ways without making a network call but here I just wanted to show the methods which we get from apollo client which can help us in many other situations. Now, apart from refetch we also get polling in which we can specify after how many intervals of time we want a specific query to fire and fetch data from the backend service. Polling provides near-real-time synchronization with your server by causing a query to execute periodically at a specified interval. Let’s see a little example of polling too.

Now, By specifying the polling to 500, we’ll fetch the tasks every 0.5 seconds from our backend service. Now, these little methods can be handy during some situations and are good to have. One of the most important thing about apollo client is that provides us with caching build in. we can specify how we want to fetch data from our backend by specifying the fetchPolicy . It’s really helpful when you are building highly responsive and fast applications.

Now, this allows you to specify when results should be fetched from the server, and when data should be loaded from the local cache. The fetch policy tells Apollo whether to prioritize getting the most recent data from the server or getting faster responses from the cache. Now, it’s completely up to you how you want to define your fetch policy depending upon your use-case.

Conclusion

Creating an application with graphql can give you a lot of benefits and there are a lot of great libraries out there for doing so but so far apollo-client is one of the best and gives you a lot of useful methods which can be of real help in some scenarios. And building your services with graphql can give you a lot of benefits like saving on some bandwidth, the client has more control over the data, what data they want and can decide what data is useful for building certain components and what’s not.

How to Get Started With a Graph QL, React, Apollo Client, and Apollo Server App

Sachin Thakur — Thu, 09 Apr 2020 19:53:39 +0000

This is a two-part series. In part one we will learn what graphql is and what are some of its advantages and build a backend using graphql. In part two we will learn to integrate our graphql backed to our react frontend service using Apollo Client. This series was originally posted on my personal blog. You can find link to both parts below

Graphql has been around for quite some time now and we often think that graphql is some complex thing but in reality, all graphql is a specification of how the data will be exchanged between the server and the client over the HTTP. It’s essentially a query language for your API’s and defined what data can be fetched from the server. Now, this is unlike anything you might have used in terms of a standard API, where you have a specific endpoint for fetching specific data. Like in the case of a medium API, we might have an API called /api/allarticles/:userId which returns us all articles for a specific user. Now this was of building API is known as REST API’s and we have been building APIs using this technique for quite some time now and before that, we had SOAP in which we use to have XML data structure. Now, what makes graphql different if how it improves upon the ideas of REST. In case of rest, where we hit a URL and get some data back in case of graphql we can specifically ask for what we are looking for and fetch only a specific subset whatever we want to build a specific page.

Getting Started

Now, after this small introduction let dive right into some demo. In this demo, we will be focusing on building a small react application using Apollo Client a graphql client library that is available for all major front end javascript framework and Apollo server for building our backend. Now all code for this tutorial will be available on Github. So, let’s get right into building a simple application.

Now, this demo will be focused on building a simple application to get started with Apollo client on the front end with ReactJs and Apollo server for building a lightweight graphQl backend. Let’s start by setting up a simple folder structure. Now for sake of simplicity in this starting guide, we will have both backend and frontend inside the same folder. So, let’s get started.

Now, after setting up the folder structure we will start by building our backend first and then move on to build a react frontend to showcase our data.

Building Backend Service with Apollo graphQl

Now, Since we are done with the initial Folder let’s start by writing some code and get started learning a few things about the apollo server. So let’s get right into our index.js file and initialize our server with basic minimal configuration.

const {ApolloServer, gql} = require('apollo-server');

const server = new ApolloServer({
  typeDefs,
  resolvers,
});

server.listen()
    .then(({url}) => {
      console.log(`Server ready at ${url}`);
    })
    .catch(err => {console.log(err)})

Now, before we move any further let’s just analyze the 12 lines of code we have written so far and see what we are working with. Now most of the code is pretty straight forward except we see something called typeDefs and resolvers . So let’s first explore what exactly typeDefs and resolvers are.

Every graphQl server needs to define the data that can be accessed by the client and that can be done through a schema and these schemas are stored inside our typeDefs file. Now, this schema can have three root operation. These three operations are Query , Mutation and subscription . And all these have their specific purpose. Query are generally used for fetching the data which already exists in our database, Mutation are used to create or update any data and Subscription are used to listen to the events generated by our graphql server. Subscriptions depend on the use of a publish and subscribe primitive to generate the events that notify a subscription.

Now, since we are done with some basic introduction to Query , Mutation and Subscription . Similarly a resolver is essentially a function or a method that resolves some value for a field in the schema. They are the once which perform all the task to fetch data, create data, run some business logic to resolve the fields asked by the client. let’s get into some examples of how we can use them together to create our graphql server.

Now, let’s move forward with our example application. I personally prefer separating my resolvers and typeDefs so l et's create our files for resolvers and typeDefs .

After creating our files let’s look at our new folder structure and then we can start working with typeDefs because typeDefs are essentially like interfaces for our client based on which our client can ask for data from the server. So let’s start by creating our first typeDefs .

Now, as I said earlier that typeDefs is the way for the client to connect to our backend service and ask for data. So let’s see how we can define.

const {gql} = require('apollo-server');


const typeDefs = gql`
        type Query {
            sayHello: String
        }

`

module.exports = typeDefs

Now, in the above example, we have defined a simple Query which helps us fetch some data from backend and in our case it is sayHello and it returns a type of String as defined by the sayHello Query itself. Just make sure that you name your query so that they are self-declarative. Here our Query name clearly signifies what it’s going to do. Now as we have defined our typeDefs we also have to define our resolver function against this query which will actually resolve or compute some value and the way graphQl does that is by mapping each typeDefs name to each resolver function name. So here in our case, we have to define resolver with the same name. So let’s do that too.

const resolvers = {
  Query: {
    sayHello: () => 'hello random person',
  },
};

module.exports = resolvers

Here we have defined our sayHello function inside our Query and it resolves to certain value here in our case hello random person . Just make sure the return type of your resolver function and typeDefs make otherwise your queries will result in returning null . Now since we have created both our typeDefs and resolvers files we just have to make a little change to our index.js file and we are good to go. We just have to import our resolvers and typeDefs file into our index.js file and make use of them.

const {ApolloServer} = require('apollo-server');
const typeDefs = require('./typeDefs')
const resolvers = require('./resolvers')
const server = new ApolloServer({
  typeDefs,
  resolvers,
});

server.listen()
    .then(({url}) => {
      console.log(`Server ready at ${url}`);
      ``
    })
    .catch(err => {console.log(err)})

Now, since we are done with our introduction, let’s build a simple TODO list to get into doing CRUD operations using graphQl. Now, here we are not going to use some database, we will have a fake database inside our backend service in the form of a json object and we can manipulate that to perform our CRUD operations. So let’s create our fake JSON file.

const DAILY_TASKS = [
  {
    task: "Make Coffee",
    completed: false,
    id: 1
  },
  {
    task: "Learn GraphQl",
    completed: false,
    id: 2
  },
  {
    task: "Learn GoLang",
    completed: false,
    id: 3
  },
  {
    task: "Learn NodeJs",
    completed: false,
    id: 4
  },
  {
    task: "Learn GraphQl",
    completed: false,
    id: 5
  }
];

module.exports = DAILY_TASKS;

Now, We are going to have 3 Mutation to update, create and delete data inside our fake JSON file and 1 query for interacting and fetching our data.

Now, let’s create our first Query to fetch the data from our backend service. Let’s call it fetchTasks .

const { gql } = require("apollo-server");

const typeDefs = gql`
  type Tasks {
    task: String
    id: ID
    completed: Boolean
  }
  type Query {
    fetchTasks: Tasks
  }
`;

module.exports = typeDefs;

Here we define our fetch task Query and it has a return type of Tasks . Now let’s write a resolver function for our newly added query.

const DAILY_TASKS = require("./fake_data");
const resolvers = {
  Query: {
    fetchTasks: () => DAILY_TASKS[0]
  }
};

module.exports = resolvers;

Here our query is going to return the first task always. Before updating this behavior let’s run our server first.

Now, when we navigate to http://localhost:4000/ we are greeted with this GUI. This is known as graphql playground and we can run our queries here. Let’s run our first Query here.

Now, after running our first query we see our results it fetches data from our backend which we have in our fake JSON file. Now, let’s add some logic to our functions and accept some data as a filter from our clients.

const { gql } = require("apollo-server");

const typeDefs = gql`
  type Tasks {
    task: String
    id: ID
    completed: Boolean
  }

  input fetchTaskFilter {
    id: ID!
  }

  input addTaskInput {
    name: String!
    completed: Boolean!
  }

  input updateTaskInput {
    id: ID!
    name: String
    completed: Boolean
  }

  type Query {
    fetchTask(filter: fetchTaskFilter): Tasks
    fetchTasks: [Tasks]
  }

  type Mutation {
    addTask(input: addTaskInput): Tasks
    updateTask(input: updateTaskInput): Tasks
  }
`;

module.exports = typeDefs;

Now, in the above example, we have defined our mutation and queries to interact with our data. Now, one new thing we see is the !mark in front of our data types, now what this means is that this field is compulsory and we cannot execute our queries or mutation on the backend. Now let’s add some logic to our resolvers so we can interact with our data. Every resolver function inside our resolvers file receives 4 function arguments and in some form or another, almost all graphql server receives these 4 function arguments inside resolvers.

root — Result from the previous/parent type.
args — Arguments provided to the field by the client. For example, in our typeDefs we have addTask(input:addTaskInput) so the args, in this case, would be {input:{name:"some name",completed:false}} .
context — a Mutable object that is provided to all resolvers. This basically contains the authentication, authorization state, and anything else that should be taken into account when resolving the query. You get access to your request object so you can apply any middlewares and provide that info to your resolvers through context.
info — Field-specific information relevant to the query. This argument is only used in advanced cases, but it contains information about the execution state of the query, including the field name, the path to the field from the root, and more.

Here we will primarily focus on args to get access to our fields sent by our client or playground.

const DAILY_TASKS = require("./fake_data");
const resolvers = {
  Query: {
    fetchTask: (parent, args, context, info) => {
      return DAILY_TASKS[args.input.id];
    },
    fetchTasks: (parent, args, context, info) => {
      return DAILY_TASKS;
    }
  },
  Mutation: {
    addTask: (parent, args, context, info) => {
      const {
        input: { name, completed }
      } = args;
      const nextId = DAILY_TASKS[DAILY_TASKS.length - 1].id + 1;
      const newTask = {
        task: name,
        completed: completed,
        id: nextId
      };
      DAILY_TASKS.push(newTask);
      return newTask;
    },
    updateTask: (parent, args, context, info) => {
      const {
        input: { id, name, completed }
      } = args;
      const updateTask = DAILY_TASKS.filter(task => {
        return task.id == id;
      });
      if (name) {
        updateTask[0].task = task;
      }
      if (completed) {
        updateTask[0].completed = completed;
      }
      DAILY_TASKS.push(updateTask);
      return updateTask[0];
    }
  }
};

module.exports = resolvers;

Now, we have just added some simple logic to interact with our fake database. Now let’s see how we can interact through our playground.

Now, we see all our mutations and queries here. Now let’s run a few mutations and queries and see if it works.

We are done with the building of our server with minimal configurations. In part two of this article, we are going to use React and Apollo Client to build our front-end client and make use of the APIs we just built.

Generator Functions in JavaScript

Sachin Thakur — Sun, 29 Mar 2020 18:09:32 +0000

With ES6, EcmaScript releases a new way of working with the functions. In this article we will take a look at them and how and where we can use them

What are the generator functions?

Generator functions are a special type of function which allows you to suspend their execution and later resumed at any time. Thye have also simplified the creation of iterators but we will get into that later. Let’s start simply by understanding what they are with some examples.

Creating a generator function is simple. The function* declaration (function keyword followed by an asterisk) defines a generator function.

function* generatorFunction() {
   yield 1;
}

Now, in generator functions, we don’t use return statements but rather a yield which specifies the value to be returned from the iterator. Now in the above example, it will return us a value of 1. Now, when we call generator functions like a normal ES6 function it does not directly execute the function but rather returns a Generator object. The Generator object contains next(), return and throw which can be used to interact with our generator functions. It works similarly to an iterator but you have more control over it. Let’s see with an example of how we can use generatorFunction. Now, as I told you before we get next(). Now, the next() method returns an object with two properties done and value. You can also provide a parameter to the next method to send a value to the generator. Let’s see this with an example.

function* generatorFunction() {

yield 1;

}

const iterator = generatorFunction()
const value=iterator.next().value
console.log(value)

Now, as I said earlier that we can also pass values to the generator function through next and that value can be used inside generator the function. Let’s see how that works with another example.

function* generatorFunction() {

let value = yield null

yield value+ 2;

yield 3 + value

}

const iterator:Generator = generatorFunction()
const value=iterator.next(10).value // returns null
console.log(iterator.next(11).value) //return 13

Now, here when you obtain the generator you don’t have a yield you can push values to. So first you have to reach a yield by calling the next on the generator initially. It will return null always. You can pass arguments or not it does not matter it will always return null. Now, once you have done that you have a yield at your disposal and you can push your value via iterator.next() which will effectively replace yield null with the input passed through next and then when it finds another yield it returns back to the consumer of the generator which is our iterator here.

Now, let’s talk a little about the yeild keyword. Here, it looks like it’s working like return but on steroids because return simply returns a value from a function after a function is called and it will also not allow you to do anything after return keyword in a normal function but in our case yield is doing much more than that it’s returning a value but when you again call it, it will move on to the next yield statement. The yield keyword is used to pause and resume a generator function. The yield returns an object and it contains a value and done. The value is the result of the evaluating of the generator functions and the done indicates whether our generator function has been fully completed or not, its values can be either true or false. We can also use return keyword in generator function and it will return the same object but it will not go any further than that and the code after return will
never be reached even if you have 6 yield after that so you need to be very careful using the return and should only be used once you are certain the job of the generator function is done.

function* generatorFunction() {

yield  2;

return 2;

yield 3; //generator function will never reach here

}

const iterator:Generator = generatorFunction()

Uses of Generator Function

Now, generator functions can very easily simplify the creation of iterators, implementation of the recursion or better async functionality. Let’s look at some examples.

function* countInfinite(){

let i=0;

while(true){

yield i;

i++

}

}

const iterator= countInfinite()

console.log(iterator.next().value)

console.log(iterator.next().value)

console.log(iterator.next().value)

In the above, it’s an infinite loop but it will only be executed as many times as we call next on the iterator and since it preserves the previous state of the function it continues to count. This is just a very basic example of how it can be used but we can use more complex logic inside the generator functions giving us more power.

function* fibonacci(num1:number, num2:number) {

while (true) {

yield (() => {

num2 = num2 + num1;

num1 = num2 - num1;

return num2;

})();

}

}

const iterator = fibonacci(0, 1);

for (let i = 0; i < 10; i++) {

console.log(iterator.next().value);

}

Now in the above example, we implemented a Fibonacci series without any
recursion. The generator functions are really powerful and are only limited by your own imagination. Another big advantage of generator functions is that they are really memory efficient. We generate a value that is needed. In case of a normal function, we generate a lot of values without even knowing whether we are going to use them or not. However, in the case of the generator function, we can defer the computation and only use it when needed.

Now before using the generator function just keep some things in mind that you cannot access a value again if you have already accessed.

Conclusion

Iterator functions are a great and efficient way to do a lot of things in
javaScript. There are many other possible ways of using a generator function.
For example, working with asynchronous operations can be made easy, now since a generator function can emit many values over time it can be used as an observable too. I hope this article helped you understand a little about generator function and let me know what else you can or are doing with the generator function.

Understanding JavaScript the weird parts: `this` context

Sachin Thakur — Sun, 22 Mar 2020 11:22:17 +0000

The this keyword in JavaScript has confused a lot of developers. Whether you are just starting your career in programming or you are an experienced
developer. It confuses everyone alike.

Now before starting let’s get into the fundamentals of how this works in
javaScript. this always refers to the calling context of a function inside an object, which will usually be the object with which the function is associated with. Now, Since we have so many libraries at our disposal in the javascript ecosystem we just grab a library and start building something without actually understanding what is going on. While you will be able to build amazing applications but when it comes to debugging those applications that’s when the understanding of the weird parts of the javaScript comes into the picture. Now, javaScript is still evolving even after so many years but the fundamentals of language will always remain the same.

this does not refer to the function in which it is used, but always refers
to the object in which it is executed. Let’s understand this by an example.

const obj={
  myFunction: function(){
  console.log(this===window)
 }
}

obj.myFunction()

Now, in the above example, we expect this behavior because here this will always refer to the calling context of a function which here is obj.

Now this behavior will be true in any other object-oriented language. This is the default assumption because this is how this works in most other languages. Now, let’s change a few things and see how the behavior of this changes.

Now, in this example object declaration is the same but here we assign it
another variable and the call it afterward instead of calling it right away. Now if we call the newVariable, suddenly the value of this changes from obj to the global or window. Now, this tends to trip up a lot of developers. Now in order to understand what value this will hold we need to look where it is being called not where it is written. In the above example, it is being called in the global object and not the obj object.

Let's look at some complex examples.

const obj={
  myFunction: function(){
  console.log(this===obj)
  setTimeout(function(){
    console.log(this===obj)
    console.log(this===window)
  })
 }
}

obj.myFunction()

Now, this example is similar to the above example but here we use setTimeout which is an asynchronous task. Now, if we run this we get something different.

We see that inside setTimeout now the value of this again changes back to the window or global depending upon the environment i.e Nodejs or browser. Now even though it’s the same block of code the value of this changes to window. Now, going back to the first rule this does not depend on where the function is being written but where it is called and in case of asynchronous calls a new async function object on the window object. Okay, now let’s take a look at the same example but written a little differently using an ES6 arrow function.

const obj={
  myFunction: function(){
  console.log(this===obj)
  setTimeout(()=>{
    console.log(this===obj)
    console.log(this===window)
  })
 }
}

obj.myFunction()

Interestingly, Now the value of this changes back to obj instead of window. An important thing to note is that this always get binding happens in 3 ways- default binding, implicit binding, and explicit binding. Now whenever we define a standalone function execution, it is always a default binding and it always binds to window object.

Now, we have to keep that default binding will always be our fallback binding.

Let’s get to know a little bit about Explicit and Implicit binding and
understand how that works.

Implicit Binding

Now implicit binding happens whenever we have a function call and whatever is to the left side of the dot it is going to refer to that.

In this example, we have obj to the left side of the dot so it is going to refer to that i.e obj.

Explicit Binding

Explicit binding of this occurs when .call(),.apply(), or .bind() are used on a function.

We call these explicit because you are explicitly passing in a this context to call() or apply(). Let’s take a look at how explicit binding looks like in the following example.

const obj={
  myFunction: function(){
  console.log(this===obj)
 }
}

const newFunctionVariable=obj.myFunction

newFunctionVariable.apply(obj)

Now even though we are assigning myFunction to a new variable we can still say to what this context this function call will be bound to. We can see this by looking at another example where we can bind it to a completely different object below.

const obj1={

firstName:"Sachin",

lastName:"Thakur",

myName:function(){

console.log(this.firstName+" "+this.lastName)

}

}

const obj={

myFunction: function(){

console.log(this)

console.log(this==obj1)

}

}

const newFunctionVariable=obj.myFunction

newFunctionVariable.apply(obj1)

Now, in this, if we pass the first parameter as obj1it will take the this reference of obj1 even though the function is defined on obj. And this is how the Explicit binding works.

Now with the introduction of ES5 arrow function, the javaScript engine
introduced a new behavior. Before arrow functions, every new function defined its own this value based on how the function was called:

A new object in the case of a direct function call with window context as this (Default Binding)
undefined in strict mode function calls.
The base object if the function was called as an “object method”.(Implicit Binding)
You could also Explicitly define what this will refer to like we saw in the last example. (Explicit Binding)

An arrow function does not have it’s own this. The this value comes from the lexical scope. Arrow function follows the normal variable look rule. If the value is not found in its scope go one level up and find the value in the enclosing scope. That’s why we don’t need to bind this value to the object explicitly as long as it is available in it’s enclosing scope.

Thus, in the following code, the this within the function that is passed to setTimeout has the same value as the this in the lexically enclosing
function:

const obj={
  myFunction: function(){
  console.log(this===obj)
  setTimeout(()=>{
    console.log(this===obj)
  },0)
 }
}
obj.myFunction()

Conclusion

this can be a little tricky sometimes but if we know the basic fundamentals of how scoping words and how javaScript treats an object, we can easily understand how these core concepts work. this can be a little tricky in case of callback or async function where the value of this changes. Always remember this value is assigned the value of the object where it is being invoked.

Storybook: Doing Component Development the right way

Sachin Thakur — Sun, 01 Mar 2020 06:10:48 +0000

Nowadays, if you have ever tried to build a user interface you might have come across many problems. Building these interface components is a very expensive and effort consuming task. We have designers, product managers and many developers working on a single project.

The modern User interfaces are built with thousands of UI components that are reused between different screens and different user interfaces and sometimes between different products inside the same company to make the design look consistent. Now usually in these scenarios, there are design systems in place with the catalogs of all the reusable components in one place. This helps improves the productivity of the developers by up to 30–40%. Modern UI interfaces are build from thousands of reusable UI components

Now here Design System contains reusable components which can be used among different application to build complex, durable and accessible user interfaces. Since both designs and developers contribute to a Design system so it servers as a “single source of truth” where designs can test the Component design they build in different scenarios.

When Do we need a design system?

Now despite all the hype and pros of a design system, it is not for everyone. If you are working on a single project, you will be better off without a design system. It will just add to the complexity of your application. But if you sharing your components across different projects then building a designing a design system makes sense for you rather then copy and pasting component from one place to another.

okay, So what exactly does storybook do?

Storybook is used by developers for the following reasons

Building the UI component in isolation
To prevent UI bugs
Standardizing Styling across different Projects
Distributing UI Components among different projects

Okay, Great but how will Storybook help me?

UI/UX Designers

UI/UX designs can go into the storybook to see how exactly the components look and feel in different scenarios, see all the states of the component, how they are behaving in these different state changes and provide your valuable feedback.

Developers

Developers can easily share these components between different projects and see how exactly they are being used what properties do these components have and how they can extend them. This speeds up the development process since now you just have to build your component once and just import and use it elsewhere. Codesharing becomes easier and side effects can be easily handled at one single place.

Getting Started with React Storybook

Now the storybook book can be used with almost every frontend framework possible, and there are a lot of them. Why can we stick with just one and make it standard? Okay, enough of the framework rant. let us start with React. You can find documentation for other frameworks here.

Installing React Storybook

Now since Storybook is a part of the javascript ecosystem you can install it using your favorite package manager. For this introduction, I’m going to use yarn but npm also works the same way.

yarn global add @storybook/cli

It will globally install storybook CLI on your system. if you don’t want to permanently install storybook CLI you can also use npx. Read more about this here.

Now all we need a React application. And we are going to create that using create-react-app. Install creat-react-app in your by running following command in your system.

yarn create react-app storybook-intro --typescript
cd storybook-intro

You can read more about create-react-app here. Now let’s start by adding storybook to our project.

Now run the following command to add storybook to your project.

getstorybook

Now if you notice there are some extra folders add to your project.

.storybook is used for configuring storybook. we will do that later.

Now run

yarn storybook

Now if you go to http://localhost:9009/ you will see the following page. Now make sure to restart your server whenever you change any config or add any new package.

Now let’s start building some component then we will see how we can configure storybook and make it more powerful and fully utilize its purpose.

So let’s create a basic component. Let’s start with a button.

import React from "react";

import "./index.css";

interface IButtonProps {}
const Button: React.FC<IButtonProps> = () => {
return (
<>
<button className="button">Primary Button</button>
</>
);

};

export default Button;
export { Button };

Add the following CSS

.button {

background-color: #4caf50; /* Green */

border: none;

color: white;

padding: 15px 32px;

text-align: center;

text-decoration: none;

display: inline-block;

font-size: 16px;

margin: 4px 2px;

cursor: pointer;

}
.primary {
background-color: #008cba;
}

.danger {

background-color: #f44336;

}

Now let’s add a story for this component. btw you can delete the stories folder we don’t need anyway. Now create a new file button.stories.TSX alongside your button component.

Now let’s create our first story inside button.stories.tsx

import React from "react";

import { Button } from "./index";

export default {

title: "Button",

component: Button

};

export const Primary = () => <Button>Hello Button</Button>;

Let’s start the storybook server again and let’s see how our story looks.

Okay, we don’t see our newly added story. But why is that? If we go to .storybook/config.js file we see that the storybook is configured for javaScript, not TypeScript.

Now let’s configure it for TypeScript. This can easily be solved by just adding the correct regex in stories.

../src/**/*.stories.(ts|tsx|js|jsx)

It will pick all the JSX/TSX/js/ts files in the project. Now if you go to localhost:9009 we see our story. Make sure you restart the storybook server since this is a configuration change.

Now let’s make our component a little more standard so we can expect some props and make changes.

import React from "react";

import "./index.css";

interface IButtonProps {

buttonText: string;

primary?: boolean;

danger?: boolean;

}

const Button: React.FC<IButtonProps> = props => {
const { buttonText, primary, danger } = props;
let styles;
primary ? (styles = "primary") : danger ? (styles = "danger") : (styles = "");

return (
<>
<button className={"button" + " " + styles}>{buttonText}</button>
</>

);

};

export default Button;
export { Button };

Now since we update we also need to update our storybook component to send in these props which we just added to our component.

import React from "react";

import { Button } from "./index";

export default {

title: "Button",

component: Button

};

export const Primary = () => (

<Button buttonText="Primary Button" primary={true} />

);

export const DangerButton = () => (

<Button buttonText="Danger Button" danger={true} />

);

Now if we go back to our storybook we see 2 stories. One with Primary Button and one with Danger Button.

Now, This is just the isolation part of the development. we developed a storybook component in isolation but how do we tell other developers that we are expecting all these props like button text, primary, danger and they can change these to change the appearance of the button. That’s where storybook add-ons come to play which makes storybook so powerful for building a common component library.

Storybook has several recommended add-ons

a11y — Test components for user accessibility in Storybook
actions — Log actions as users interact with components in the Storybook UI
knobs — Interactively edit components input data in the Storybook UI
source — View a Stories code within the Storybook UI
viewport — Change display sizes and layouts for responsive components using Storybook. This can help you build responsive layouts

You can see all the add-ons here. On top of this, you can create your addon if you want. Learn more about that here.

Now let’s add some add-ons to our little project. Let’s start with the knobs add-on so that we can interact with our component.

Installation

First, we need to install the add-on to our project

yarn add @storybook/addon-knobs @types/storybook__addon-knobs

Now register knob in your .storybook/main.js file

// .storybook/main.js

module.exports = {
stories: ["../src/**/*.stories.(ts|tsx|js|jsx)"],

addons: [

"@storybook/preset-create-react-app",

"@storybook/addon-actions",
"@storybook/addon-links",
"@storybook/addon-knobs"
]
};

Now let’s add the newly added knob there. Go to the .storybook folder and create new file config.js and add the newly added addon there. Adding addon like this will it to all the stories. If you just want want to add the addon to only one story that can also be done. You can read about that here. But if you are building a library you won’t be adding add-ons one by one to each file. So let’s start by creating a config.js file.

// .storybook/config.js

import { withKnobs } from "@storybook/addon-knobs";
import { addDecorator } from "@storybook/react";

addDecorator(withKnobs);

Now before we see any changes with our storybook we need to use knob inside our story. So now go to button.stories.tsx and use the knob. Now the knob provides us with a lot of knobs like text, boolean, object depending on your data type. Now in our case, we only need text and boolean since these are the only types we support in our button component. Now import the appropriate knob from the @storybook/addon-knobs

// Button/button.stories.tsx

import { text, boolean } from "@storybook/addon-knobs";

Now go to the component story and use the knob as follows.

// PrimaryButton inside Button/button.stories.tsx
<Button

buttonText={text("Button Text", "Primary Button")}

primary={boolean("Primary button", true)}

/>

// DangerButton inside Button/button.stories.tsx

<Button

buttonText={text("Button Text", "Danger Button")}

danger={boolean("Danger Button", true)}

/>

Now if you go back to localhost:9009/ you see your newly added knobs in action.

Now we can change the text of the button and use boolean to set the state of the button and see how the button behaves when its state changes.

Another very useful addon is the info. Now when you install it every story in your library gets a Documentation page. These can be used for documenting your component so the other developer can understand how and why it can be used.

To add this addon just install the addon

yarn add @storybook/addon-info @types/storybook__addon-info

Now, lets first register it to our main.js file onto our addons.

// .storybook/main.js
module.exports = {

stories: ["../src/**/*.stories.(ts|tsx|js|jsx)"],

addons: [

"@storybook/preset-create-react-app",

"@storybook/addon-actions",

"@storybook/addon-links",

"@storybook/addon-knobs",

"@storybook/addon-info"

]

};

After this, we also need to configure this addon to work with our storybook so go to config.js and register this new addon.

// .storybook/config.js

import { withKnobs } from "@storybook/addon-knobs";

import { addDecorator, addParameters } from "@storybook/react";

import { withInfo } from "@storybook/addon-info";



addDecorator(withInfo);

addDecorator(withKnobs);

Now go back to your button story and configure this addon.

import PropTypes from "prop-types";



import { Button } from "./index";

export default {

title: "Button",

component: Button,

parameters: {

info: { inline: false }

}

};

Button.propTypes = {

buttonText: PropTypes.string.isRequired,

primary: PropTypes.bool,

danger: PropTypes.bool

};

We just need can use the info the parameter to either pass certain options or specific documentation text to your stories. and add prop types to show the props received by the button component info. It is also possible to disable the add-on entirely. Depending on the scope at which you want to disable the addon. Just pass info:{disable:true} Now if we go back to localhost:9009/ after restarting the server we see a new section called show info on the top right corner.

Now if we go to docs we don’t see anything interesting. Just the component and how it is being used.

Now let’s add some documentation to better elaborate this component what it does and how it should be used. We can pass another key to info the called text which describes what the component does and how it can be used.

Now after adding the text if we go back to localhost:9009/ and click on show info we see our documentation of the component.

Conclusion

As you see throughout this article, Storybook is easy to use and has a lot of add-ons and make it easy for the code to be shared among different project along with the proper documentation and we can build all our components in isolation and all the team members can see what components have been built and how they can use these components. And if a new person joins he won’t have to worry whether a component has been build or how to use a component. This significantly reduces the development time and helps strengthen your interfaces and make them consistent throughout different projects.

P.S :- all code for this article is available here

TypeScript -JavaScript on steroids

Sachin Thakur — Fri, 28 Feb 2020 10:52:38 +0000

We all know that JavaScript is arguably the most popular and widely used tool for building software these days, it seems as if javaScript has taken over the world of software development from building a website to web servers with NodeJs, with Electron on your machines and finally thanks to Facebook, with React Native, it’s native to your phone. There is no doubt it’s a Swiss Army Knife of building software. Everything that can be written in JavaScript will eventually be written in JavaScript.

So JavaScript is everywhere, However, the dominance of JavaScript happened so quickly now we have few problems. It’s nothing wrong to have one language everywhere, but it’s not the language we like to have but it’s the language we have. JavaScript is still evolving, we have ES2015, ES2016, ES2017 which are still coming with some good add ons, but some gaps are still there. We have enterprise applications running on javascript but don’t have a good way of writing this enterprise-level software i.e. building components like classes, interfaces that are not present in JavaScript, we don’t have static types like most another popular language like C, CPP, python which makes software more stable and free of run-time errors which might cause problems. Now, this is where TypeScript comes into the picture.

Now TypeScript is an open-source syntactic superset of javascript that essentially compiles to JavaScript but TypeScript offers much more than just syntactic sugar, It enables great tooling and developer experience through the power of static typing. Now some of the improved enhancements which TypeScript provides include better refactoring, static type checking to remove unwanted runtime errors, statement completion, and many more.

There are many benefits of using TypeScript over JavaScript. **TypeScript** was created to statically identify constructs that are likely to be errors. Now, what does this mean? let’s understand this by comparing a piece of code between JavaScript and TypeScript.

//JavaScript

function getName(fullName){
      if(fullName){
          return "John Doe"
      }
   return "John"
}

let name= getName('false') // John Doe

Now in javascript nothing will stop us from passing a string to a function that is expecting a boolean. Now JavaScript will run this which might lead to some errors at runtime. And when you are dealing with a huge amount of code errors like this can easily happen which will lead to some very weird bugs. Now this can entirely be avoided by using TypeScript’s type Annotations

//TypeScript

function getName(fullName:boolean):string{
      if(fullName){
          return "John Doe"
      }
   return "John"
}

let name= getName('false') // throws error 'string' can be assigned to a parameter of type 'boolean'.

This prevents us from making mistakes that would have been avoided if we had static type checking in JavaScript. Now the great thing about TypeScript is the editor support. Let me show you by a little example.

Do you see a little red underline? Now, this is TypeScript telling us that we have done something wrong and we need to fix it. Great! so now instead of remembering UppeCase() only accepts a string, we can trust TypeScript to remember it. Imagine having thousands or even tens of thousand of methods and line of code, we cna still rely on TypeScript to have our back.

Getting started with TypeScript.

it’s really easy to get started with the TypeScript, before moving forward all you need is NodeJs and NPM installed and you are good to go. Now open the terminal and type the following commands.

npm install -g typescript

Setup a basic NodeJs Project. Follow the following steps in your terminal to create a basic NodeJs project.

mkdir awesome-typescript
cd awesome-typescript
mkdir src
npm init -y
npm i typescript --save
touch tsconfig.json

Now the next step would be to initialise a basic config file.

Now after this all we need to do is create a .ts file in our project.

After doing all this we end up with this. Good, Now you can follow along with more examples. Now we will write all the code in .ts file and .js file will be the compiled version of the typescript code which in our case is es2016 because we specified it in our tsconfig file.

Now there are also many other benefits to using TypeScript like the types in TypesScript.

We know that in JavaScript we only have the following types

Number
null
boolean
String
undefined

Rest everything in JavaScript is an Object

Functions are first-class Object in JavaScript world
Arrays are also objects
ProtoTypes are Object

Weird Right?

Now when we talk about TypeScript we have clearly defined types. Apart from what is defined in JavaScript, we have more types like

Now we define something as any in our application when we don’t know what that type exactly going to be. It gives us flexibility but we should always avoid using this as it can start causing problems sometimes if we don’t know what we are doing.

Notice that here we reassigned a from a string to a number but it didn’t give us an error. it gives us the flexibility but also increase the change of producing unnecessary bugs.

Void

void is a little like the opposite of any the absence of having any type at all. You may commonly see this as the return type of functions that do not return value

tuples

Tuples are your organized arrays. Tuple types allow you to express an array with a fixed number of elements whose types are known.

Now here we see a red underline which means our editor is telling us we messed up somewhere. Here we tried assigning a string to a number inside an array. Pretty cool right!

null

Now, this article is getting a little longer but we have a lot of types and other cool features that can’t be covered in one article like enums, interfaces, Decorators, Method Overriding which can be very helpful if you want to build a stable and reliable software.

You can find more types on TypeScript getting started website.

When does it make sense to use TypeScript

Prefer Strict Type Checking: Adding strict type checking reduces a lot of overhead. It is possible to do runtime type validations in javaScript but that will just increase the overhead which can easily be removed by using compile-time validations which are done by typeScript.
Large Software or Multiple Developers: Adding TypeScript makes much more sense when many developers are working on a single code base, which will always be the case if you are working on a large project. TypeScripts Interfaces, Method Overrides, access types (which methods are private, protected or public) can be useful.

Conclusion

Now whether or not you decide to add TypeScript to your existing or upcoming project you can surely agree that TypeScript adds some good functionality to JavaScript and make it more stable and reliable.

FYI: you can easily migrate your existing project to TypeScript without putting much effort and you can write pure JavaScript inside TypeScript file.

P.S: This article was originally written on https://blog.thakursachin467.tech/2020/02/typescript-javascript-on-steroids/