DEV Community: Akash Singh

JavaScript delete operator might cause some unexpected performance issues.

Akash Singh — Sat, 21 Jun 2025 03:57:21 +0000

So I was working on some benchmarking with a piece of code in JavaScript and I was scratching my head over the runtimes that I was seeing. I literally could not make sense of what was happening. And in a wild attempt at debugging, I stumbled upon a quirk that I had never known.

The v8 engine does not really like the delete operator. And using this operator on an object can have a tangible impact on the performance of your code. In my case, it was almost 3 times worse performance than if I had manually set that key to undefined or false

That said, I was able to reproduce this in Safari v18.5 as well along with all Chromium based browsers. So not really sure if this behavior is limited to the v8 engine.

Benchmarking code

Here’s a simple code I wrote based on my experience to easily benchmark the performance impact of using delete vs. manually setting the key to something else. Note that in the code example here I’m setting it to false but using undefined yields similar results.

const mapDelete = {};
const benchmarkDelete = (i = 0) => {
  while (i < 25) {
    if (mapDelete[i]) {
      delete mapDelete[i];
    } else mapDelete[i] = true;
    benchmarkDelete((i += 1));
  }
};

const startDelete = performance.now();
benchmarkDelete();
const endDelete = performance.now();
console.log(`Execution time delete => ${endDelete - startDelete} milliseconds`);

const mapFalse = {};
const benchmarkFalse = (i = 0) => {
  while (i < 25) {
    if (mapFalse[i]) {
      mapFalse[i] = false;
    } else mapFalse[i] = true;
    benchmarkFalse((i += 1));
  }
};

const startFalse = performance.now();
benchmarkFalse();
const endFalse = performance.now();
console.log(`Execution time false => ${endFalse - startFalse} milliseconds`);

I ran this code in multiple environments such as Chrome, Safari and node and the results were more or less consistent. The first method’s execution time was around 3 times slower than that of the second method.

Node

I tested with v24.2.0 which was the latest available version at the time of writing this article.

Chrome

Tested on Version 136.0.7103.114 (Official Build) (arm64) on macOS 15.5

Safari

While Chrome and Node are both using Google’s v8 engine, Safari uses Apple’s own engine called JavaScriptCore, also known as Nitro. Tested on Safari 18.5 on macOS 15.5.

Why?

I tried to find the exact reason but I couldn’t really find anything definitive or official, but I did come across a couple of other articles and posts on StackOverflow talking about this or something close to this. The logic seems to be that when you use delete the underlying JS engine stops treating it like a conventional hash map and loses some of the optimizations it has for working with them.

This post goes into a lot more details about the underlying optimizations that v8 engine does, but I think something similar applies to most other engines as well.

TL;DR

If you care about the runtime and performance of your code/app and heavily use delete for objects that are used as lookups with very frequent read operations, then it might just be better to use a different approach or just set that key to undefined manually.

A complete guide on being a great manager, written by an engineer

Akash Singh — Wed, 21 Aug 2024 22:53:08 +0000

I’m not a manager

I’m a software engineer in the Bay Area and I’ve been working in the tech industry for a significant part of my adult life. For all these years, I’ve always had a manager- whether it was working in a small startup or a large company. I personally don’t think I have any inclination to become a manager, at least not anytime soon, but their role and impact on my work has fascinated me; I’ve always tried to think about what I would have done if I was in their shoes. Obviously, I never really knew their exact situation and constraints but that didn’t stop me from thinking about it.

Your impact

I cannot emphasize enough on the level of impact you as a manager have on your direct reports. I’m sure you’ve heard of the quote “People leave managers, not companies” and yes that is a wild claim that doesn’t always makes sense, but I feel that there’s some truth to it. Nowadays, with mega size tech companies, people don’t even necessarily leave their company to leave their manager, they just hop on to a different team in the same company. Anyway, the point I’m trying to make here is that your relationship with your engineers directly impacts their quality of life, at and outside of work, on things like motivation, stress, and anxiety. For me, my relationship with my manager is one of the biggest factors impacting my entire perception of the job. And a bad relationship doesn’t always lead to attrition as there are other factors that come in to play like pay, availability or opportunities, mobility, etc. but it does impact overall team morale and culture.

I’m sure all of you who are managers already know this and this isn’t something new at all, but the purpose of starting this conversation here was to stress that this perspective should always be in your mind. You have a direct and a very significant impact on someone’s life. And if I were to paraphrase the words of uncle Ben, I would say “With great impact, comes great responsibilities”.

What you’re working with

Choosing to pursue the management ladder might feel like you’re choosing to step off the factory floor and step into the office where you’ll do more white collar and less labor intensive work. And you’re right, it is a lot like that. But that definitely does not mean that it easier or better. If anything, the job you’re choosing is significantly harder. The tools and equipment that you wield on the factory floor are predictable, mechanical, and deterministic. You’re leaving them behind and working with people now, who are complex, non-deterministic, have emotions, and are unique. Unfortunately, there is no manual that comes attached with the people that you’ll be working with and you’ll need to figure everything out on the job.

"How can I help?"

I think something that can help here is keeping in mind some of the constants that we know to be true about human nature. We know that everyone is built different (insert built different meme here). People are unique in their ways and that has a direct impact on their work and their presence in a team/project. This is one of the most important constants to remember as a manager. Every single person you manage is unique. And as much as some people with expertise in scientific management would try to have you believe that workers can be measured by their productivity (measure of work per unit time), and that’s all there is to engineers and your job is to manage them like a resource, reality, in my opinion is fairly different. What each of them brings to the table is different. What expertise and skill they have and what they want to do is different. And most importantly, the management style that works best for each of them is different. I think it is crucial to your success as a manager to pay close attention to these differences and try and be the kind of manager that they want and need you to be.

If you haven’t already had this conversation with your direct reports then I highly encourage that you set up some time and have this conversation. You can start with a question like “tell me about the best manager you’ve ever had” or “tell me what does an ideal manager look like to you”. And yes, this conversation will require a lot of trust and openness to take any meaningful shape. If your direct reports do not trust you enough to be honest and open with you (more on this later) then this conversation might not lead to anything. But if you have that rapport, then please have this conversation and I’m sure it will be helpful for everyone involved. And if you’re someone who’s already had this conversation or know exactly what management style works for each of your direct report then in my eyes you’re already a great manager. 🙌

Ebbs and flows of Will

Another constant that I would like to point out here is that motivation/productivity/drive-to-work (let’s call it will) comes in ebbs and flows. Nobody will have the same level of will throughout the week/month/year. And I’m not talking about seasonal effects like people traveling to meet family for the holiday season or people taking more vacation to enjoy the summers. I mean to say that there are more personal and intimate factors that come into play that determine the level of will and I feel that as a manager it is very important to keep this in mind and if possible plan around it. This would be hard to gauge as people might not volunteer this information since there’s potential for this to be misused. I wish I had a good solution for how to factor this in, but I feel like it is important I point this out and trust that someone smarter than me will have some recommendations on what could work to gauge the level of will.

And building up on that, if you notice or feel that the level of will has been on the low for a little longer than what is normal, which is different for everyone (all the more reason to know the pattern for each person), then one of the factors at play could be burnout. It is fairly common in our industry (actually must be common in every industry, I just know about ours) and I’m sure everyone at some point have had a run in with it. I feel like as a manager it is very important to have a measure of burnout in the team and also at an individual level. Knowing when someone is experiencing burnout and approaching them with empathy could make a difference of night and day in the experience of your engineers. Yes, I understand that not every company/team has the privilege to account for burnout and provide relief as their own survival might be on the line, but even then, it is definitely possible to approach the situation with empathy. I don’t think there’s a single approach that would work for everyone and I don’t want to prescribe solutions here but I do think that it is very valuable for a manager to keep a pulse check on burnout on both a team and individual level.

Who works for who?

Before I even start this section, let me first start by saying that I have a lot of ideas around structuring and power dynamics in a team/company/corporation and they aren’t always aligned with the structures that commonly exist in the workplaces today. Maybe, I will talk about this in more depth later.

From my perspective, the people who you have power over, are the people you are most accountable to. Yes, it is important for you, the manager, to take ideas and directions from the leadership (people above you), understand their needs and wants and then translate that to the team. But when it comes to who has an opinion about your work that matters, I would argue the opinion of your direct reports is at least as important as those of the people above you, if not more. Your success, as vague and subjective as that term can be, is truly dependent on how your engineers are feeling about your management and the quality of their life while working with you. The role is, for most part, to act as a bridge between the leadership and the workers. Once you’ve communicated the asks and goals of the leadership, your job becomes to trust the engineers and then work with them to figure out how you can help them out to do what they need to do. And this is not that hard, it all just starts with one question, “Hey, how can I help you?”. All you need to do after the project goals and asks are communicated, is ask this question and listen to your engineers. And at first you may get a lot of “umm, nothing” but that’s ok, because even for the engineers it takes time to understand what needs to be done, and how and what they need help with. So just be consistent and don’t forget to ask, how can I help. If you’re already in the habit of asking your engineers this question then really there isn’t much more to this section and you’re already doing great!

The secret sauce of all good relationships: Trust

The question I talked about in the last section, “Hey, how can I help?”, seems like a fairly simple question that shouldn’t be too hard to answer, but there’s an underlying factor that hugely impacts the quality of the answer, and that is trust. How much trust do your engineers place in you? how open and honest can they be with you, without any fears of retaliation? Trust is a fundamental aspect of all human relations and there’s no reason that the relationships at work would be any different. Trust is even more important in a relationship where there is difference of power and influence. And because of this power dynamic, the responsibility to build trust and nurture it falls more on the manager than it does on the engineers. It is an inherent nature of humans to hide things, especially things that they feel can be used to judge them negatively, from authority. That is why it is critical that a) you convince your engineers that you’re not an authority figure but rather a helper, there to make their life better or b) show that you can be trusted with this authority because you only use it for their good (There may be other ways too that I’m not smart enough to think of). Whatever path you choose, unfortunately, you will have to work hard to gain this trust. It will not be placed in you by default. But once you have earned this trust, people will be more open to being vulnerable around you and sharing not just their strengths, but more importantly their weakness, which will truly empower you to not only plan and do your job better, but actually take real steps to help your engineers overcome their weaknesses and grow.

Whenever I think of this, I always wonder if the managers actually know when their engineers truly trust them. I’ve tried to think about ways to measure this trust but it seems like a really difficult problem. Any question around it can be answered to make it appear like they trust you, if there’s a perceived incentive to show that. You could create anonymous forms where people answers related questions and maybe anonymity would help gather more honest responses. Maybe you can focus on what they talk about with you and how frequently, if ever, they say something that makes them vulnerable. I’m really not sure what the best way is and maybe the right way to gauge trust is different for different people, but I do think that there’s immense value in building a relationship based on trust and respect than one that is based on fear and necessity.

Building on this trust

This trust that you build with your direct reports is very crucial for you and your success as well. One of the best ways to grow as a manager is to get good, constructive, and honest feedback from people you’re accountable to. When they are open and honest to tell you what they think you’re doing wrong or what you can do better, you’ll have the right information to direct your energy towards. Yes, the feedback you receive from the people you report to is important and yes, on the surface it might feel like that is what matters more to grow your career, but the part that not a lot of people think about is that the way your direct reports perceive you and think of you, is equally important in your growth. Their relationship with you impacts all the metrics that are important to you and your team’s success and can be the differentiating factor between a team full of content and happy people doing their best work and a team which is lacking in energy and motivation and feels burnt out. I really feel that this feedback mechanism should be more robust and personal than the usual organization wide quarterly or bi-annual surveys that ask some industry standard questions about how people feel about their managers. These surveys provide a much more zoomed out view that are good for capturing sentiments but are not really that useful on an individual level to learn from. That feedback will have to be more intimate and personal from each and every one of your direct reports. And as it is with any feedback, it is very easy for our mind to quickly come up with reasons and justifications for our own actions, it is very important to fight this instinct and be a good listener and try to empathize and understand where the other person is coming from. I know this is very easy to preach and I myself struggle to fight the instinct to justify my actions. But I do think that this is even more important in a relationship where there is a perceived power imbalance. It makes it even harder to motivate people to truly be honest and provide real feedback because if they do not think it is valued, the incentives to not speak up and continue to maintain the status quo will become even stronger. So again, I will just stress this one more time that the onus of building trust with your direct reports is more on you as the manager.

Identifying when something is not right

If you have nurtured this trust and are honest with your teammates, it will make it possible to identify when there’s a mismatch. You cannot be the right manager for everyone and there might be situations where differences make it such that you might not be the right manager for someone. It doesn’t mean that you cannot work with them. If you’re both professional and respectful then sure it can ”work” but it might not be the best for you and your engineer. And obviously it is best to try and identify this at the time of hiring but you won’t always get to choose your team members. Even if you do, over the years people may change and grow in different directions which can lead to this mismatch. Either way, it is important to identify it and address it. Obviously, changing managers is not a luxury all organizations will have and it should be the last resort. But there are things that must be done before to try and address the situation. The most important thing would be to have an honest conversation. Not in a way that would threaten your direct reports and make them fear for their jobs but in a way that makes it possible for them to suggest changes that can make the situation better for them or for you to suggest changes to them that can make it easier for you to be their manager. Clear, honest, and empathetic conversation can go a long way in helping address such situations. But whatever be the approach, it is, in my opinion, important to address such situations before the relationship reaches a point from where it is very hard to recover from.

When engineers and managers collide

I’ve had the opportunity to work with and experience both situations where either the managers do some coding and also do management things or the managers are mostly removed from actual coding and mostly spend their entire energy and focus on management work. Unfortunately, in my experience with both, the managers usually do build a higher degree of separation from the code than the engineers whose entire energy is spent on building and maintaining the code base. This is where I think I might offend some managers, and trust me that is not my intention. But I feel like I must say that it is important to remember the choices you made and stay in your lane. This is not to say at all that you do not have the skills or the talent to understand the code or that you aren’t a good engineer. In fact weirdly enough our industry tends to “promote” the best engineers to management positions so it is potentially more likely that you were a great engineer, when you used to be one. But now that you have made the decision to step away from day-to-day engineering it is important to trust and delegate the engineering decisions to those who are more intimate with the engineering. The past of being great engineer helps you in understanding the scope, potentially recognizing problems, and asking the right questions, but it is important to recognize that you’ve actively chosen to step away from the engineering piece itself and that you might not be the best when it comes to taking some engineering decisions. It might be even more tempting to take these decisions when working with more inexperienced engineers since they do not yet have the same depth of experience and the ability to identify problems early on, but even in that situation, I would say the right way to guide is through asking questions and helping them arrive at the issue that you had already identified instead of telling them what to do. Philosophically, in my mind, it is a bit like parenting, you need to nudge and guide them to the right thing and ask questions to help think rather than dictating what to do. And maybe sometimes you might even have to let them fall a little and then offer a helping hand to truly provide an environment where they can learn and grow and build confidence. Obviously this doesn’t mean that you let them push a shady pull request to production on a Friday evening, but maybe let them spend some time with a potential idea and give them an opportunity to develop it themselves to see its flaws. Either way, the message is to try and trust then engineers with the engineering and influence them as needed but try to avoid taking decisions on their behalf and telling them how to do their work.

And I feel like this is a good point to also plug something about leadership that I’ve learned from my experience in the industry. Management and leadership are not always the same. Being a manager is not the same as being an engineering leader. These two are actually quite different and just because you are a really good engineer and have the ambiotion to become a leader doesn’t mean that you should start transitioning your career to become a manager. It important to understand this difference. I’m personally still figuring this out for myself but I feel like I’ve started identifying how management is a very different job and doesn’t have as much overlap with engineering as I used to think in the past. As a good manager, your primary skill that will lead to your success is not engineering. It is definitely one of the skills and it will help a lot but it is not the center stage skill that will make you successful. I don’t have an exhaustive list but some of the things I’ve identified that makes a great manager are empathy, understanding of human nature, ability to foresee and plan for non-technical issues, building processes and operating procedures to reduce risk and fatigue, and so many more that I don’t know of yet. The point I want to make is that you should pursue management only if you want to take up that specific job, do not pursue it because you confused the title of manager to always mean leader.

Being a manager is hard

If all of this sounds really hard to you, that is because it is hard. It’s way harder to be a good manager than it is to be a good engineer. Obviously this is a personal opinion and like I said at the beginning of this article, there’s a reason I don’t see myself taking up this challenge anytime in the near future. I’m happy working with my tools and applied sciences knowledge to deal with deterministic things that are easier to mold and shape to get the required outcome than having to do the same with people with wildly different hopes, dreams, feelings and ambitions.

But just because it is hard doesn’t mean that you can’t have support. I feel like if you’re open and transparent with your engineers and share with them what’s been stressing you out and what are the things bothering you, you will develop a two-way connection where not only will they feel more encouraged to be open with you but also be there for you to support you and empathize with you. This type of communication can really help build a relationship that is based on understanding and respect and nurture a more meaningful connection with people you spend most of your working time with. I truly believe that there is absolutely no reason that manager-engineer relationships can’t be similar to the relationships between peers and dare I say even nurture into an actual friendship that extends beyond the workplace. After all, these are the people we spend a large part of our day-to-day lives with; wouldn’t it be nice if we actually got to know them as real people and not just as that person who does x at your company?

Philosophy

If you’ve made it this far then you may have noticed by now that I used the phrase “in my opinion” or “I think” a lot in this article. So I figured I would make a little section to clarify that this article is based on a very personal worldview. Most of the things I’ve talked about are based on my personal philosophies and how I see work and the people I work with. A lot of it is based on my past experiences and what I’ve seen so it is highly likely that everything that was said here is either way too obvious or absolutely ridiculous. Either way I hope you understand how my philosophy has shaped this article and I hope it doesn’t offend or hurt you.

I have spend a lot of time thinking about work, culture, and what my ideal world would look like and have been fortunate enough to have a few friends in life (both, at and outside of work) who listen to my ramblings and instead of telling me that it’s all crazy talk, actually philosophize with me. I’m really grateful to them for listening to me and sharing their ideas with me, but I just want to say that if after reading this you felt angry or upset or felt that you’ve wasted your time, they share some of that blame.

P.S.

While writing this, I constantly kept thinking about what I as an engineer can do better to help my manager and make their life easier and make my own life easier in the process. Maybe that will be something I write about next 🤔

Testing Typescript GraphQL Server using Jest with Docker

Akash Singh — Wed, 01 Jun 2022 02:01:07 +0000

While working on a backend built using typescript, graphql, and mongoDB I reached a point where I needed some code coverage to continue development. Documenting test cases in graphql playground wasn't scaling anymore and I'm strictly against using Google Docs/Sheets for documenting test cases and running them manually after every code change. So, I decided to go with Jest for executing and documenting the test cases.

Overview

This article assumes that you have an existing backend codebase that uses typescript, graphql, and mongodb and is executed using docker. So, the basic infrastructure looks something like this, a docker-compose file runs the backend and database docker containers where the backend service can connect to the database container on a specific port. The backend service runs graphql and listens for connections on a specific port on the local machine and runs graphql playground for manually testing the queries & mutations.

Also, I set up my backend service to read the database connection details (url & name) from the environment variables, which comes from .env file. Make sure to add this file to gitignore to ensure this doesn't get pushed to the remote and other environments (eg. production).

Setting up Jest

Assuming that you already have everything from the overview section running as expected and you're able to use graphql playground to execute queries and mututaions, we'll get started with setting up Jest in this section.

Since we're using Typescript, I will be working with ts-jest.

Installation

Run the following commands in your terminal.

# Install pre-requisites
npm i -D jest typescript
# Install ts-jest
npm i -D ts-jest @types/jest
# Initiallize
npx ts-jest config:init

Once we've installed ts-jest, let's add a test script to our package.json which will run jest on our codebase and execute all the *.test.js tests files.

"scripts": {
  /* ... */
  "test": "jest"
},

Connecting to Database

In order to connect jest to our database, we would need to read the connection string from the environment variable. There are multiple ways to access environment variables in jest, so we'll cover the easiest method here.

We can tell jest when it gets executed to provide access to the environment variables inside test files by passing an argument to the jest call in package.json.

"scripts": {
  /* ... */
  "test": "jest --setupFiles dotenv/config"
},

The --setupFiles dotenv/config argument allows us to access environment variable within test files.

Now that we have access to the environment variables, let's write our first test which will connect to the database. src/first.test.ts

import mongoose, { Mongoose } from "mongoose";

let conn: Mongoose;

beforeAll(async () => {
  conn = await mongoose.connect(
    `${process.env.DATABASE_URL}/${process.env.DATABASE_NAME}`,
    {
      useNewUrlParser: true,
      useUnifiedTopology: true,
      useCreateIndex: true,
      useFindAndModify: false,
    }
  );
});

afterAll(() => {
  conn.disconnect();
});

Note that we don't have a test cases yet, but we're just setting up the test to connect to the database before starting and close the connection after completing all the tests.

Connecting to Graph for Testing

Now let's set up our test file to connect to our graph and call the queries and mutations from the schema. For this, we'll create a new graph that takes our schema and executes our queries & mutations on it.

Let's create a helper file that will set up the graph and help execute queries and mutations from test files. Let's call this file graphqlHelper.ts:

import { graphql } from "graphql";
import { makeExecutableSchema } from "@graphql-tools/schema";
import { typeDefs } from "../typeDefs/typeDefs";
import { resolvers } from "../resolvers/resolvers";
import { User, IUser } from "../entity";
import { UserService } from "../services";

// Create the schema from typeDefs and resolvers
const schema = makeExecutableSchema({
  typeDefs: typeDefs,
  resolvers,
});

// Create the helper method that returns the graph
export const graphqlHelper = async (
  query: any,
  variables?: any,
  user?: IUser,
) => {
  // Create the graph
  return graphql(
    schema,
    query, // Query or Mutations will be passed when calling this helper
    undefined,
    {
      req: {
        user, // add the user object to the req object
        userId: user?._id, // add the userId object to the req object
      },
      res: {
        cookie: () => {},
        clearCookie: () => {}
      },
      // Add user & userId to context to simulate logged in state
      user: user, // add the user object to the context
      userId: user?._id, // add the userId object to the context

      // Add the entities to the context
      User,

      // Add the services to the context 
      UserService,
    },
    variables // variables that gets passed when graphqlHelper method is called
  );
};

Now that we have the graphqlHelper method, we will import it in our test file first.test.js

import mongoose, { Mongoose } from "mongoose";
import { graphqlHelper } from "./graphqlHelper";

let conn: Mongoose;

beforeAll(async () => {
  conn = await mongoose.connect(
    `${process.env.DATABASE_URL}/${process.env.DATABASE_NAME}`,
    {
      useNewUrlParser: true,
      useUnifiedTopology: true,
      useCreateIndex: true,
      useFindAndModify: false,
    }
  );
});

afterAll(() => {
  conn.disconnect();
});

Writing tests

Now that we have everything set up, let's write some test cases in our first.test.js file. For the purpose of this article I will be writing a simple register, login and me test case where we will test creating a new user using the register mutation, logging in with that user using login mutation and then fetching the logged in user's information using the me query.

import mongoose, { Mongoose } from "mongoose";
import { graphqlHelper } from "./graphqlHelper";
import { User } from "../entity";

let conn: Mongoose;

beforeAll(async () => {
  conn = await mongoose.connect(
    `${process.env.DATABASE_URL}/${process.env.DATABASE_NAME}`,
    {
      useNewUrlParser: true,
      useUnifiedTopology: true,
      useCreateIndex: true,
      useFindAndModify: false,
    }
  );
});

afterAll(async () => {
  // Cleanup users created as part of test
  await User.deleteMany({ email: /.*@example-jest-user-test.com/ });
  conn.disconnect();
});


const registerMutation = `
  mutation RegisterMutation($email: String!, $password: String!, $firstName: String!, $lastName: String!) {
    register(email: $email, password: $password, firstName: $firstName, lastName: $lastName)
  }
`;

const loginMutation = `
  mutation LoginMutation($email: String!, $password: String!) {
    login(email: $email, password: $password) {
      _id
      email
    }
  }
`;

const meQuery = `
  query MeQuery {
    me {
      _id
      email
    }
  }
`;

describe("resolvers", () => {
  it("register, login, and me", async () => {
    const randomNumber = Math.floor(1000 * Math.random());
    const testUser = { email: `jestuser+${randomNumber}@example-jest-user-test.com`, password: "testpass", firstName: "Jest", lastName: "User" };

    const registerResponse = await graphqlHelper(registerMutation, {
      email: testUser.email,
      password: testUser.password,
      firstName: testUser.firstName,
      lastName: testUser.lastName,
    });

    expect(registerResponse).toEqual({ data: { register: true } });

    const dbUser = await User.findOne({ email: testUser.email });

    expect(dbUser).toBeDefined();

    const loginResponse = await graphqlHelper(loginMutation, {
      email: testUser.email,
      password: testUser.password,
    });

    expect(loginResponse).toEqual({
      data: {
        login: {
          _id: `${dbUser!._id}`,
          email: dbUser!.email,
        }
      }
    });

    const meResponse = await graphqlHelper(meQuery, {}, dbUser || undefined);

    expect(meResponse).toEqual({
      data: {
        me: {
          _id: `${dbUser!._id}`,
          email: dbUser!.email,
        }
      }
    });
  });
});

Executing

We have the tests ready and now we just need to execute them. However, there's one problem. When you run npm run test in your local (host) terminal, the test fails as the database connection times out. This is happening because the database is running inside docker and the container is only accessible from within the docker environment.

So, to execute, let's open the terminal of our backend docker container. To do this, we'll ssh into the docker container. We first need the ID of the backend container. So let's run this command in our terminal:

docker ps

And you should see an output like this:

CONTAINER ID   IMAGE                       COMMAND                  CREATED      STATUS      PORTS                                            NAMES
8491cf18587f   backend_server   "docker-entrypoint.s…"   2 days ago   Up 2 days   0.0.0.0:4000->4000/tcp, 0.0.0.0:9229->9229/tcp   backend-server
0f15447c0ae2   mongo                       "docker-entrypoint.s…"   2 days ago   Up 2 days   0.0.0.0:27017->27017/tcp                         db

From here, copy the CONTAINER ID of the backend server and then run the following command:

docker exec -it 8491cf18587f /bin/bash

where 8491cf18587f is the CONTAINER ID of the backend docker container.

Once you have access to the container's terminal, navigate to the folder which contains the app files (including package.json). This might look something like

cd /app/

depending on your docker configuration.

Once you're in that folder, run npm run test to execute the tests within the docker container. This time you should see the tests get executed and an output that looks something like this

root@8491cf18587f:/app# npm run test

> server@0.0.1 test /app
> jest --setupFiles dotenv/config

 PASS  dist/first.test.js
 PASS  src/first.test.ts

Test Suites: 2 passed, 2 total
Tests:       2 passed, 2 total
Snapshots:   0 total
Time:        4.257 s
Ran all test suites.

root@8491cf18587f:/app#

Voila! You have succesfully executed your Jest tests from within your docker container. Now the only thing left to do it is to write a docker-compose file that will allow you to execute the tests from your local (host) terminal.

Docker-Compose

Let's write a docker-compose file that can execute our test cases from our terminal without having to connect to the container's terminal using SSH. Here is what we need to do to in this docker compose file, run the mongoDB image and then run the backend image, but in the backend image instead of running the command npm run dev (or whatever is your execution script), we'll run npm run test.

This is what the docker-compose.test.yml file should look like:

version: "3.7"

services:
  test-server:
    build:
      context: .
      dockerfile: Dockerfile
      target: base
    volumes:
      - ./src:/app/src
    container_name: test-server
    expose:
      - 4000
    ports:
      - "4000:4000"
      - "9229:9229"
    command: npm run test
    links:
      - db

  db:
    container_name: db
    image: mongo
    ports:
      - 27017:27017
    volumes:
      - data:/data/db

volumes:
  data:

Now let's run this docker-compose file from the terminal:

docker-compose -f docker-compose.test.yml up

This will run the two containers and then execute the jest test scripts and print a similar output as before in the console. However, you'll see that running this will result in console showing the logs from the db container as well and if you want your console to look clean and only have the output of npm run test then launch the docker compose using this command:

docker-compose -f docker-compose.test.yml run test-server

You should now see the output of the test case execution in your terminal.

Once you have executed the test cases, run the docker-compose down command to kill the containers.

docker-compose -f docker-compose.test.yml down

And that's it, you've successfully configured jest to execute test cases on your graphql typescript server inside docker!

Complete Guide on Debugging Typescript Node Application in VS Code Using Remote Development Feature

Akash Singh — Tue, 11 Jan 2022 04:55:42 +0000

This is simple guide to get started with debugging typescript node application in VS Code using the Remote Development extension. The issue with this use-case is that the application files are mounted to the container, built there and then server runs the built files from within the container, thus leaving the host folder open in VS Code completely disconnected from the server. The solution is to open the application folder inside the docker container in VS Code and then using the source-map there to debug (add breakpoints).

Pre-reqs

I'm assuming that you already have a working typescript application that has been set up to run inside a docker container using docker-compose or the docker CLI.

VS Code Remote Development

VS Code Remote Development is an extension pack that allows you to open remote folders in your installation of VS Code. For more details on how it works, I highly recommend going through the official documentation available here.

To get started, install the extension in VS Code.

Setting Up Project

Now that we've installed the extension, let's set up our application to make sure that debugging works as expected.

tsconfig.json

We need to make sure that our tsconfig.json is set up to create source-maps for our application so that VS Code can then use those source maps to place breakpoints.

Let's make sure that we have the following lines in tsconfig.json:

{
  "compilerOptions": {
    // ... your compiler options go here
    "sourceMap": true,                           /* Generates corresponding '.map' file. */
    "outDir": "dist" /* Redirect output structure to the directory. */,
  },
  "include": ["src"]
}

docker-compose.yml

We need to make sure that we expose the debugger port on our docker application. To do this, add port 9229 under the ports section of your application.

The file should look something like this:

services:
  service-name:
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - ./src:/path/to/app/src
    container_name: container-name
    expose:
      - 4000
    ports:
      - "4000:4000"
      - "9229:9229" # Debugger port

launch.json

Now we need to create a launch configuration for VS Code to attach the debugger to our node application.

I use this simple configuration:

{
    "version": "0.2.0",
    "configurations": [
      {
        "name": "Docker: Attach to Node",
        "type": "node",
        "request": "attach",
        "restart": true,
        "trace": true,
        "port": 9229,
        "address": "0.0.0.0",
        "localRoot": "${workspaceFolder}/dist",
        "remoteRoot": "/path/to/app/dist", // Note that this is the same location from docker-compose
        "outFiles": ["${workspaceFolder}/dist/**/**.js"],
        "skipFiles": ["<node_internals>/**/*.js"],
        "protocol": "inspector",
        "sourceMaps": true
      }
    ]
  }

Connecting to Container (Remote)

Now we need to run our container in docker and connect VS Code to this container. First launch your container using docker-compose or docker CLI. Then click on the Remote Explorer option in VS Code sidebar. You should see a list of all the running docker containers here. Once you see your container, click on it and select the option Attach to container. This should open up a new instance of VS Code and start setting everything up for remote debugging. You can look at the Debug Console to track the progress. Once that is complete, you need to open the application folder in your container in this instance of VS Code. So click open folder and then select /path/to/app (mount location in docker-compose). You should now see your application files in VS Code along with the dist folder containing the built files and the source-maps.

At this point you're all set to start debugging in VS Code.

Debugging

Set breakpoints where you want and then go to the Run and Debug tab in VS Code sidebar and run Docker: Attach to Node (the name you set in launch.json).

Now when the line is reached, your code execution should stop there as expected and you should be able use all the debugging features of VS Code with your typescript docker app.

Next time when you open the project, just run the docker container, go to the Remote Explorer tab in VS Code and open your existing remote instance for this container and start debugging.

Complete guide on deploying a Docker application (React) to AWS Elastic Beanstalk using Docker Hub and Github Actions

Akash Singh — Tue, 31 Aug 2021 10:11:21 +0000

I recently went through the struggle of setting up a pipeline for deploying a dockerized react app to Beanstalk and the whole process has left me with a new found respect for the magicians we sometimes take for granted, dev-ops engineers.

In this article I will go over the process I used to deploy a Docker image to beanstalk using Docker Hub for hosting the image and GitHub Actions for building and orchestrating the whole process. In my journey I discovered that there are multiple ways of achieving this and there really isn't a "best" approach for all use cases. However, my familiarity with beanstalk and fear of getting started with a new technology like ECS was the main motivation behind using this approach. So if you're anything like me keep reading.

I have broken the whole process into smaller, independent (somewhat) steps that give a clear, high-level picture of the entire pipeline from setting up Docker to having the image running on Beanstalk.

Pipeline Steps

Create necessary accounts
Dockerizing your application
Building the image on Github using Actions and pushing to Docker Hub
Deploying Docker Hub image to AWS Elastic Beanstalk
Making Docker repository private (Optional)

Create necessary accounts

Let's sign up for all the services that we'll need for this setup.

Github
Docker Hub
Amazon Web Services (AWS)

Dockerizing your application

Why Docker?

Why use Docker? Good question. In my opinion it's the closest you can be to sharing a single "machine" for development with your all your peers. If this answer doesn't appeal to you then I sincerely urge you to read more on this topic as there are plenty of articles written by more qualified developers talking about why you should use Docker and how it can make your life easier.

Setting Up Docker

Now that you're convinced, let's go over the docker configurations. For the purpose of this article, I'm going to assume that you already have a basic react (or any other) application set up with docker that you can start by building the image and running the container. If you don't have it set up then you can start with create-react-app and then add docker manually or clone a boilerplate like this one.

Here's what the Dockerfile for my react application looks like:

# Dockerfile

# pull official base image
FROM node:13.12.0-alpine

# set working directory
WORKDIR /app

# add `/app/node_modules/.bin` to $PATH
ENV PATH /app/node_modules/.bin:$PATH

# install app dependencies
COPY package.json ./
COPY package-lock.json ./
RUN npm install

# start app
CMD ["npm", "run", "start"]

# expose port
EXPOSE 3000

Now that you have a dockerized application, let's create docker configurations for production server which uses nginx reverse-proxy web server (I named it Dockerfile.prod).

# Dockerfile.prod

# build environment
FROM node:13.12.0-alpine as build
WORKDIR /app
ENV PATH /app/node_modules/.bin:$PATH
COPY package.json ./
COPY package-lock.json ./
RUN npm ci
COPY . ./
RUN npm run build

# production environment
FROM nginx:stable-alpine
COPY --from=build /app/build /usr/share/nginx/html
# to make react-router work with nginx
COPY nginx/nginx.conf /etc/nginx/conf.d/default.conf
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

Note: If you're not sure why we use nginx, then I highly recommend reading more about it.

This basically creates an image for my application and runs the build application script. It then copies the files generated by the build script (npm run build) to the nginx image under the /usr/share/nginx/html location, exposes port 80 and starts the server.

Here's an optional docker-compose file that I use along with the Dockerfile to build & test build script code in local. I use it by running docker compose -f docker-compose.prod.yml up --build and then going to localhost:80 in my browser.
You don't need this in order to continue with this tutorial.

# docker-compose.prod.yml

version: '3.8'

services:
  frontend-prod:
    container_name: frontend-prod
    build:
      context: .
      dockerfile: Dockerfile.prod
    ports:
      - '80:80'

Building the Image on Github Using Actions and Pushing to Docker Hub

Now let's set up Github Actions to build the production docker image whenever you push code to a branch and then deploy that image to Docker Hub. I'm assuming that you have already set up a github account and are able to push code to your repo. If you haven't done that yet, then you should stop here, create a github account, push your code to a new repo and then come back.

Github Actions YAML File

Github Actions works by reading a .github/workflows/.yml file in your codebase for instructions. It uses the basic YAML syntax which is human friendly and should be fairly easy to get follow. Let's create this YAML file from Github's UI and add some basic steps.

We're going to add the following content to the file:

name: Dev deployment from Github to AWS
on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Latest Repo
        uses: actions/checkout@master

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v1

      - name: Login to DockerHub
        uses: docker/login-action@v1
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_PASSWORD }}

      - name: Build and push
        uses: docker/build-push-action@v2
        with:
          context: .
          file: Dockerfile.prod
          push: true
          tags: <your repo name>/<your application name>:latest

Here we're setting the name of the action which you can see on line 1. Then we say that on push event on main branch we're going to run the jobs defined below. Next we define the deploy job which runs on ubuntu-latest machine. Then we define the follwing steps:

Use actions/checkout@master action to checkout the main branch
Use docker/setup-buildx-action@v1 action to set up Buildx, the tool we'll use to push the image to Docker Hub
Use docker/login-action@v1 action to authenticate with Docker Hub. We'll set secrets object will in the repository settings on Github in the next step.
Use docker/build-push-action@v2 action to build the image using Dockerfile.prod file and then push it as / on Docker Hub with the latest tag.

Now that we have added these steps to the main.yml file, let's commit the changes and go back to our local machine and pull the latest.

Github Secrets

Now let's create the secrets in our Github repo.

Use the same process to add the DOCKERHUB_PASSWORD secret.

Running the Action

Now that we have everything set up, let's make some minor code changes in the main branch and push. Once you do, you should be able to navigate to the actions tab on Github and see the deploy action running. It should look something like this.

Once the action is complete, open your Docker Hub account and make sure that the image was pushed succesfully.

Deploying Docker Hub image to AWS Elastic Beanstalk

In this section we're going to set up AWS to deploy the Docker Hub image to Elastic Beanstalk and have our application available on the world wide web! We'll achieve this by sending instructions to beanstalk from Github Actions to pull and run the image from Docker Hub.

Setting Up AWS

Before getting started, you should complete creating an account on AWS and then setting up payments, etc. to be able to create a Beanstalk application.

Creating Beanstalk Admin User for Deployments

Follow these steps to create an IAM user with programatic access that we'll use to deploy packages to our Beanstalk application from Github Actions:

Navigate to IAM
Create a new Group (We'll call it beanstalk-admin here)
Add the AdministratorAccess-AWSElasticBeanstalk permission to the beanstalk-admin group

It should look something like this:

Ignore the other permission for now.

Create a new user called github-deployment-user
Give Programatic Access to this user and add it to the beanstalk-admin group
Copy the Access key ID and the Secret access key. We're going to need these later

Create Beanstalk Application

Let's create a new Beanstalk application that we'll deploy to. Navigate to Elastic Beanstalk, click Create Application, name the application, and then set the platform as Docker and leave everything else as default.

Now that we have everything set up on AWS, let's create the instructions file that will tell beanstalk to pull & run the right image from Docker Hub.

Create Dockerrun.aws.json

Beanstalk can work with docker-compose or Dockerrun.aws.json for getting instructions on what image to deploy but to keep things simple and set us up for the last step of this pipeline we're going to be using the Dockerrun.aws.json file. You should create this file at the root of your project folder.

// Dockerrun.aws.json

{
    "AWSEBDockerrunVersion": "1",
    "Image": {
        "Name": "<your repo name>/<your application name>:latest",
        "Update": "true"
    },
    "Ports": [
        {
            "ContainerPort": "80"
        }
    ],
    "Logging": "/var/log/nginx"
}

Here we're telling beanstalk to pull /:latest image and then expose PORT 80 of the container.

Update Github Actions to Send Instructions to Beanstalk

Now we're going to update the Github Actions YAML file we added earlier. Let's add the following steps to our existing deploy job:

# .github/workflows/main.yml continued

      - name: Get Timestamp
        uses: gerred/actions/current-time@master
        id: current-time

      - name: Run String Replace
        uses: frabert/replace-string-action@master
        id: format-time
        with:
          pattern: '[:\.]+'
          string: "${{ steps.current-time.outputs.time }}"
          replace-with: '-'
          flags: 'g'

      - name: Generate Deployment Package
        run: zip -r deploy.zip * -x "**node_modules**"

      - name: Deploy to EB
        uses: einaregilsson/beanstalk-deploy@v16
        with:
          aws_access_key: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws_secret_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          application_name: <beanstalk application name>
          environment_name: <beanstalk environment name>
          version_label: "docker-app-${{ steps.format-time.outputs.replaced }}"
          region: us-west-2
          deployment_package: deploy.zip

Here we're adding the following steps:

Get the current timestamp (this is for tracking the version on beanstalk)
Use action frabert/replace-string-action@master to replace : with - in the timestamp string (optional)
Create a zipped package deploy.zip of our codebase excluding node_modules folder. Note: We're doing this to send the Dockerrun.aws.json which is at the root of our project to beanstalk.
Use action einaregilsson/beanstalk-deploy@v16 to push the zip to beanstalk. Make sure that you set the right values for application_name, environment_name, and region

As you might have guessed looking at the steps, we'll need to add AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY secret keys to our Github repository. AWS_ACCESS_KEY_ID is the Access Key ID and AWS_SECRET_ACCESS_KEY is the Secret access key for the github-deployment-user that we created on step 6 in the Creating Beanstalk Admin User for Deployments secton.

Now that you have added the secrets to the Github repo, go ahead and commit & push the updated main.yml and the newly added Dockerrun.aws.json files. This should start a new deploy job under the Actions tab with the commit message as the title. Expand the job to make sure that you see the new steps that you added to your main.yml file.

Once the job completes, and if everything goes well, you should have your application deployed successfully in beanstalk and you should be able to access it by going to the beanstalk instance's public URL.
Note: If some thing breaks on AWS and you see the health of you application is red, then go to the Logs tab and download full logs. Unzip the package and look at eb-engine.log file. You should be able to find what went wrong by searching for the [ERROR] line in there.

Making Docker repository private (Optional)

Now let's talk about how we can make our Docker Hub repository private. So far our application was publicly available on Docker, meaning that anybody will be able to find and pull this image from Docker Hub. In this section we'll go over making the Docker repo private and authorizing our beanstalk instance to be able to pull the image from Docker Hub.
I struggled a bit with this part due to outdated documentation on Amazon's site and not having any recent answers from the community on Stackoverflow.

Here's basically what we need to do:

Make the Docker repository private by going to Docker Hub and changing the settings.
Create an authorization token and save it in a file that beanstalk can read.
Save that file on S3 so that our github-deployment-user can access it during deployment.
Update the Dockerrun.aws.json file to use the autorization token we created on step 2.

Making Docker Repo Private

This is pretty straight forward. You go to Docker Hub, then find the repository, go to settings and make it private. Docker gives you 1 free private repository with each Docker Hub account.

Getting the Authorization Token and Saving in a File

We'll call this file dockercfg because that is what the documentaiton keeps calling it but feel free to name it anything you want, like my-nightmare-file. This is what the contents of the file should look like:

{
  "auths": {
    "https://index.docker.io/v1/": {
      "auth": "<your auth token>"
    }
  }
}

Now the easiest way to create this file is by running the command docker login in your terminal and then copying the auths object from config.json file stored in ~/.docker/ folder (Windows folk, please Google the location). Now the problem here is that on macOS you'll see something like this:

{
  "auths": {
    "https://index.docker.io/v1/": {}
  },
  "credsStore": "desktop",
  "experimental": "disabled",
  "stackOrchestrator": "swarm"
}

This is because docker is using your keychain api to securely store the auth token instead of writing it to a file. Which is great, until you need the token. But thanks to the power of Stackoverflow, I learned that you can generate the authorization string by running this in your terminal:

echo -n '<docker hub username>:<docker hub password>' | base64

Once you have this, create the dockercfg file as above (with the auth token) and save it on your computer. We're going to update some AWS configurations and upload it to S3 next.

Uploading dockercfg to S3

Now you need to upload this file to S3 bucket that is in the same region as our beanstalk application and add S3 read access to our github-deployment-user IAM user so that the beanstalk application can read the file.

AWS Setup

To add permission to our user, go to IAM then go to user groups, select the beanstalk-admin group and add the AmazonS3ReadOnlyAccess permission.

Uploading to AWS

Now let's go to S3 and create a new bucket. We'll call it docker-login-bucket but you can call it anything you like. Make sure you uncheck the Block all public traffic option. Once the bucket is created we'll upload the dockercfg file which we created in the previous step. On the Upload page, after you select the file expand the Permissions section and select Specify Individual ACL Permissions and after that enable both Read access for the third option, Authenticated User Groups. This will allow our beanstalk user to read the contents of this file.

Updating Dockerrun.aws.json

Now we need to tell beanstalk that our Docker repository is private and point it to the dockercfg file so that it can use the authorization token when pulling the image from Docker Hub.

We'll add an authentication object to the Dockerrun.aws.json file which will point to the dockercfg file in S3.

"Authentication": {
  "bucket": "docker-login-bucket",
  "key": "dockercfg"
},

After adding this, the Dockerrun.aws.json file should look like this

{
  "AWSEBDockerrunVersion": "1",
  "Authentication": {
    "bucket": "docker-collaborationteamsad-auth",
    "key": "dockercfg"
  },
  "Image": {
    "Name": "collaborationteamsad/sparks-dev-fe:latest",
    "Update": "true"
  },
  "Ports": [
    {
      "ContainerPort": "80"
    }
  ],
  "Logging": "/var/log/nginx"
}

Now that we've updated the Dockerrun.aws.json file, let's push the code Github and check the new deploy action that gets created. If everything was set up correctly then the pipeline should complete successfully and you should be able to see your application running on the beanstalk application URL.

Congratulations! You have successfully set up a pipeline to build a Docker image using Github Actions, store it in a private repository on Docker Hub and then deployed it on an AWS Elastic Beanstalk application. Every push to the main branch should now successfully deploy your code. 🎉

Update - 8/28/2021

If you want to use docker-compose.yml instead of Dockerrun.aws.json for deploying then follow the steps provided here.