DEV Community: Saurav M H

Browser Game Design using WebSockets and Deployments on Scale - Part 2

Saurav M H — Wed, 30 Sep 2020 18:08:36 +0000

I would definitely recommend you to read the first article before we continue the journey here -

Building a multiplayer game using WebSockets - Part 1

Saurav M H ・ Jul 6 '20

#javascript #react #webdev #node

A gist of part 1 of the series:

In the last article, we talked about how to create a browser turn-based multiplayer game using socket.io and NodeJS.

The topics covered were:

Using Football Draft as an example of a turn-based game
The server architecture overview and folder structure
Introducing socket.io and handling exposed ports
Creation of rooms and namespaces and some user actions

Let's continue from where we left

We will do system design for generic turn-based games here. Let's proceed with scenarios in order of user interactions.

User enters the homepage
After the user creates or joins a new room
Waiting till others arrive before starting the game
Rotating turns
Handling player exits in-game

👋 Users enter the homepage

This can be your welcome page. In my case, I have added one previous page reading the username/alias. Here we explain the users the rules of the game and show users a clear option to join or create a new room for them to play.

Client Side

BTS

You can always refer the whole documented code from my GitHub links provided at the end.



if (this.action === 'join') {
    // @optional Check if correct password for room
    // Check if room size is equal to or more than 1
    //     If yes, join the socket to the room
    //     If not, emit 'invalid operation: room does not exist'
}

if (this.action === 'create') {
    // Check if room size is equal to zero
    //     If yes, create a new room and join socket to the room
    //     If not, emit 'invalid operation: room already exists'
}

👥 After: User Creates or Joins the Room

After a user creates a room or starts a new game, a gameState is created for the given roomId. GameState is essentially a central state management section on your server. All your client actions will be validated and updated on this gameState.

The state can be a simple Javascript object or a table/collection in your database. The reasons you might want to use a database instead of a simple JS object might be:

You have longer game sessions
- Reason: Chances are the server instance that might restart or crash due to some reason. Using a database for the gameState management helps you mitigate this problem
There are multiple server sessions running
- Reason: It is usually a good practice to run multiple instances of your socketio or NodeJS processes when running on scale. You can check out the node cluster module for this. Scaling is explained in detail later 😌

Yes, in my case I am storing state in a JS object (Stop attacking me, Jesus!). Well, I didn't think of scale at the start of the project and I'm glad I didn't go down this rabbit hole. But the silver lining is, you can easily plug in a Redis DB when initializing the socketio object. The rest will be handled by the library. But again, we want to take this a few steps further 🚀 I have explained the project scaling in detail later on in this article!

BTS



this.store = {
    password: '$2y$04$qE0oJbl7eixKMLhS7u6ure9wS/I1wcA.DtJOhaMe3oqsa1rQKAEO6', // Storing hash, coz well security!
    clients: [{
        id: this.socker.id, // Default socket.io client-session id
        username: this.username, // User alias/username
        isReady: false // Default
    }...]
}

🕑 Waiting time till everyone is Ready

We just can't start the game when a selected number of users join the game. Users must confirm they are ready, and once every user is ready the game starts.
Optional - allow users to unready themselves

Client Side

BTS



/**
 * Mark player as ready  ---> to start the draft in the given room. If all players are ready then initiate the draft
 *
 * @access public
 */
isReady() {
    this.socker.on('is-ready', () => {
        // 1. Flip the player's `isReady` state to true (only for the player which emitted this event)
        // 2. If all players are ready then trigger beginDraft()
    });
}

🔄 Rotating Turns

You might think of this as the core part of the game logic. We basically rotate the chance to pick items amongst the players. Think of the clients array as a Circular Queue. For this:

We will first randomize the clients queue (this.store.clients) order.
Start a timeout for each player's turn. Auto pick/don't pick an item on timeout expiry. (I have gone with no items pick on timeout expiry)
Rotate the chances on the whole queue, until the required number of rounds are reached
Update the gameState on every update from the player turn.

Again, the above steps are just my game logic. You can tweak them according to your requirements. Just make sure the gameState is up-to-date after each user action. You might run into consistency issues otherwise

BTS



 /**
 * Consume player item and update the gameState. Reset the timeout and initiate the next turn.
 *
 * @access    public
 */
shiftTurn() {
    this.socker.on('player-turn-trigger', (selectedItem) => {
        if (currentChance.id === this.socker.id) {
            // 1. Update the gameState
            // 2. Add the selectedItem to the userItems list
            // 3. resetTimeout()
            // 4. trigger nextTurn()
        }
    });
}

🚫 Handling Player Exits inGame

It is very important to handle player exits inGame. The user may choose to exit using the in-game menu or just close the application or his/her internet connection might just die (poor lad! we all have been there). Under all these circumstances it is important to make sure your application doesn't crash. This may affect other players' games.

For our case we need to:

Clear all the timeouts inGame
Broadcast the last synced list of items for all users in the current room
Reset the current gameState or continue the game by removing disconnected-user from the player queue

Deploying the application

CI/CD for React Application

Add your GitHub URL and click to deploy

This is the easiest deployment stage of the pipeline. You can use Vercel/Netlify or other free (I do mean generously free!) auto build and deploy tools. You just need to add your GitHub project URL on the Vercel dashboard and click deploy (yes indeed very easy).

Deploying the HTTP and Websockets Server

Before discussing the "continuous" part of CI/CD, let's see how do we set up the deployment.

TLDR;
We will be using Nginx as a reverse proxy server, creating two virtual hosts: one for HTTP requests and another for WebSockets requests.

It's okay if you didn't understand some or any part of the above. Even if you did, and are curious about the details, I will be elaborating the same with concise examples.

What is Nginx?

It is a web server that can be used as a reverse proxy, load-balancer, mail-server, handling cache, etc. It handles large amounts (up to millions) of requests and yet is light-weight and super-modular to use.

But, for our use case, we will be using Nginx as reverse-proxy. Before you ask,

A reverse proxy is a server that sits in front of one or more web servers, intercepting requests from clients.

Creating Virtual Hosts

Virtual Hosts are more of an Apache (It's a webserver just like Nginx) Term. Nginx coins this as "server blocks"

You can point each server block to a domain/subdomain you want. Here, we are creating two subdomains:

soc.mydomain.com -> Endpoint for websockets connections
api.mydomain.com -> Endpoint for HTTP connections

Now, to keep the whole configuration modular, we will be following a standard folder structure.

You will see a similar recommended template in Nginx docs too, this one has additional configs which will make writing configs for each host a breeze!



.
├── ./conf.d/
│   ├── error-pages.conf          # default error pages for each code
│   ├── gzip.conf                 # standard gzip configs
│   ├── url-filter-cgi.conf       # Filter urls to auto return error status
│   ├── real-ip-resolution.conf   # Uses real-client-ip if using cloudflare or amazon proxies
│   └── ...
├── ./vhost.d/
│   ├── api.mydomain.com.conf # HTTP config       -> user-config
│   ├── soc.mydomain.com.conf # Websockets config -> user-config
│   └── _default.conf
├── nginx.conf                    # set a global-default for nginx
├── mime.types                    # allow-list for mime types 
└── ...

Here, ./vhost.d/ is where we place all user-generated configs.

Now let us configure a server block for handling HTTP requests,



───────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ File: api.mydomain.com.conf
───────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ server {
   2   │
   3   │   listen      80;
   4   │   listen      [::]:80;
   5   │   server_name api.mydomain.com;
   6   │
   7   │   include conf.d/error-pages.conf;
   8   │   include conf.d/url-filter*.conf;
   9   │
  10   │   location / {
  11   │     return 301 https://$host$uri$is_args$args;
  12   │   }
  13   │
  14   │ }
  15   │
  16   │ server {
  17   │
  18   │   ssl_certificate                      /my_cert_path/api.mydomain.com/fullchain.pem;
  19   │   ssl_certificate_key                  /my_cert_path/api.mydomain.com/privkey.pem;
  20   │   ssl_trusted_certificate              /my_cert_path/api.mydomain.com/chain.pem;
  21   │
  22   │   listen                              443 ssl;
  23   │   server_name                         api.mydomain.com;
  24   │
  25   │   include conf.d/error-pages.conf;
  26   │   include conf.d/url-filter*.conf;
  27   │
  28   │   root /home/saurav/my_application;
  29   │
  30   │   location / {
  31   │         proxy_pass http://localhost:3000/;
  32   │         proxy_http_version 1.1;
  33   │         proxy_set_header Upgrade $http_upgrade;
  34   │         proxy_set_header Connection 'upgrade';
  35   │         proxy_set_header Host $host;
  36   │         proxy_cache_bypass $http_upgrade;
  37   │         proxy_hide_header X-Powered-By;
  38   │   }
  39   │
  40   │ }

Here, we open the port 80 for internet communication, HTTP protocol to be specific. The server_name is the endpoint you want to create a virtual host. In simple words, the public endpoint you want to route your requests to.

We will discuss both the server blocks in detail, after the below config.

Let us take an example for configuring a WebSockets enabled server block.



───────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ File: soc.mydomain.com.conf
───────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ server {
   2   │
   3   │   listen      80;
   4   │   listen      [::]:80;
   5   │   server_name soc.mydomain.com;
   6   │
   7   │   include conf.d/error-pages.conf;
   8   │   include conf.d/url-filter*.conf;
   9   │
  10   │   location / {
  11   │     return 301 https://$host$uri$is_args$args;
  12   │   }
  13   │
  14   │ }
  15   │
  16   │ server {
  17   │
  18   │   ssl_certificate                      /my_cert_path/soc.mydomain.com/fullchain.pem;
  19   │   ssl_certificate_key                  /my_cert_path/soc.mydomain.com/privkey.pem;
  20   │   ssl_trusted_certificate              /my_cert_path/soc.mydomain.com/chain.pem;
  21   │
  22   │   listen                              443 ssl;
  23   │   server_name                         soc.mydomain.com;
  24   │
  25   │   include conf.d/error-pages.conf;
  26   │   include conf.d/url-filter*.conf;
  27   │
  28   │   root /var/www/my_application;
  29   │
  30   │   location / {
  31   │         proxy_pass http://localhost:3001/;
  32   │         proxy_redirect off;
  33   │
  34   │         proxy_http_version 1.1;
  35   │         proxy_set_header X-Real-IP $remote_addr;
  36   │         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  37   │         proxy_set_header Host $host;
  38   │
  39   │         proxy_set_header X-Forwarded-Host $host;
  40   │         proxy_set_header X-Forwarded-Server $host;
  41   │
  42   │         proxy_set_header Upgrade $http_upgrade;
  43   │         proxy_set_header Connection "upgrade";
  44   │
  45   │   }
  46   │
  47   │ }

The first server block

Creates a 301 redirect from the virtual host location, soc.mydomain.com in the above example to an https connection. If you do not require an SSL connection, you can choose to define your configs here itself.

The second server block

Add SSL certificates location (I use certbot to generate SSL certs, feel free to explore other options). This step is not necessary if you are using Cloudflare, Amazon, or any other edge delivery proxy services, as you can configure the certs from their portal.
proxy_pass: Point to the server accepting the client requests. In our case, we are running the WebSockets backend on the same server, hence we add a proxy_pass for our localhost connection.
proxy_set_header: Adding appropriate request headers.
- Here, we set the Connection "upgrade" to allow switching protocols from polling to websockets. This feature is tightly bound to socket.io, as they use this feature to support older browsers. You may skip this header if you are using websockets directly
- X-Forwarded-Host: The original host requested by the client in the Host HTTP request header
- X-Forwarded-Server: The hostname of the proxy server.
- X-Forwarded-For: Automatically append $remote_addr to any incoming X-Forwarded-For headers.
- X-Real-IP: This might be tricky to understand, but bear with me. Assume a user is at IP A, the user is behind a proxy B. Now the user sends a request to loadbalancer with IP C, which routes it to Nginx. After Nginx has processed the request, the requests will have the following headers:
  - X-Forwarded-For: [A, B, C]
  - X-Real-IP: B: Since Nginx will recurse on X-Forwarded-For from the end of the array to the start of the array, and find the first untrusted IP.
- If X-Forwarded-For does not exist in a request, then $remote_addr value is used in the X-Real-IP header, otherwise, it is overwritten by recursing on the X-Forwarded-For header array, taking into consideration set_real_ip_from rule(s).

Now, we have seen how to configure reverse proxies to serve your application over the internet, be it HTTP requests or WebSocket connections. The next important part is how to handle the load and horizontal scaling of your application. Do we even require scaling? If yes, under what specific conditions?

All of the above questions and many others are answered in the below section.

🚀 Scaling your application

There are basically two kinds of scaling

Vertical Scaling: Increasing the server capacity to handle and process more requests
Horizontal Scaling: Increasing the server instances, to distribute and process more requests

We will be focusing more on horizontal scaling here. More specifically, focusing on scaling NodeJS applications. Even though some methods can be used for scaling other than NodeJS, details for other platform applications are out of the scope of this article.

Network Balancing Overview

When do I scale?

First off, make sure your NodeJs process is ONLY using asynchronous I/O. If it's not compute-intensive and using asynchronous I/O, it should be able to have many different requests "in-flight" at the same time. The design of node.js is particularly good at this if your code is designed properly.
Second, instrument and measure, measure, measure. Understand where your bottlenecks are in your existing NodeJS server and what is causing the delay or sequencing you see. Sometimes there are ways to dramatically fix/improve your bottlenecks before you start adding lots more clusters or servers.
Third, use the node.js cluster module. This will create one master node.js process that automatically balances between several child processes. You generally want to create a cluster child for each actual CPU you have in your server computer since that will get you the most use out of your CPU.
Fourth, if you need to scale to the point of multiple actual server computers, then you would use either a load balancer or reverse proxy such as Nginx to share the load among multiple hosts. If you had a quad-core CPUs in your server, you could run a cluster with four NodeJS processes on it on each server computer and then use Nginx to balance among the several server boxes you had.

Note that adding multiple hosts that are load balanced by Nginx is the last option here, not the first option.

How to scale a NodeJS application?

As mentioned, you can use the node cluster module. But in this example, we will be using pm2.

PM2 is a daemon process manager that will help you manage and keep your application online

My pm2 monitoring on server

Apart from being an excellent monitoring tool for your server jobs, there are various abstractions pm2 provides which makes it the go-to manager for deployments.
It also includes cluster mode, which is a clean abstraction built over the node-cluster module.

An example use-case would be:

Create a deploy_processes.json file ```json

{
script : "server.js",
instances : "max",
exec_mode : "cluster"
}

- Run `pm2 start deploy_processes.json`
- Run Reload after any changes: `pm2 reload deploy_processes.json`. This allows for reloading with 0-second-downtime, as opposed to `pm2 restart`, which kills and starts the process again. (*This statement is taken from the official docs, I've not made it up*)

Make sure while scaling in general, your application is **StateLess**. Do not store any information in the process or anywhere in runtime. You may use RedisDB (in-memory storage), MongoDB, or any storage of your choice to share states between the processes.

Also when scaling NodeJS applications, make sure you are not spawning many **child processes**. This just creates a lot more processes than your CPUs, causing a context switching hell for the OS.

## 🤔 Going ServerLess, are we?

Maybe. Handling scaling, errors, monitoring, and what not! becomes a pain once your application gains more users. I nowhere remotely have such a huge userbase, so I did not need serverless in my case. But it is indeed an interesting and vast field. I am currently porting this project to AWS lambdas and utilizing their other services.

Maybe I will save my server cost, maybe not.
Maybe I will have better request response times, maybe not.
Maybe I will scale this properly, maybe not.

One thing I know for sure, this path will be super interesting and a pretty good learning experience too. I had started this project with the primary focus of playing with DevOps, and I don't intend to stop now.

**If you are interested, here are my project links:**

- Backend (Websockets + HTTP) - [https://github.com/sauravhiremath/fifa-api](https://github.com/sauravhiremath/fifa-api)
- Frontend (ReactJS) -  [https://github.com/sauravhiremath/fifa](https://github.com/sauravhiremath/fifa)
- WebCrawler (Python3 + Scrapy) - [https://github.com/sauravhiremath/fifa-stats-crawler](https://github.com/sauravhiremath/fifa-stats-crawler)

> _Lemme know if you have any questions or suggestions for future articles_

> ✌️**_️ Have a great day!_**
> 
> Follow me on twitter @[sauravmh](https://twitter.com/sauravmh) for updates and maybe some cool stuff!

Going OpenSource - A dive into facebook's jest

Saurav M H — Tue, 11 Aug 2020 10:33:14 +0000

Authors

What is MLH Fellowship?

The MLH Fellowship is an internship alternative for software engineers, with a focus on Open Source projects. Instead of working on a project for just one company, students contribute to Open Source projects that are used by companies around the world. It is a great way to get real-world software development experience from the comfort of your home. The open-source community is very helpful and encourages new developers to take part in their organizations. One gains exposure, can test their skills, gain knowledge, and bond with the community to produce quality code that helps people around the world.

How is it different from other Open Source programs?

At the beginning of the program, fellows are placed into small groups called “pods” that collectively contribute to the assigned projects as a team under the educational mentorship of a professional software engineer. Apart from work, the fellowship program also provides opportunities to build a network and have fun while doing so! Students get to work on the latest Open Source technologies and are matched with projects according to their skills and interest, providing students with a learning opportunity while contributing to real-world projects. But, it’s not just about coding. Soft-skills and team-building exercises are conducted by MLH regularly, in addition to technical hands-on workshops! It’s a remote opportunity but provides a global platform for students to showcase their skills. During the Fellowship, we contributed to the Facebook/Jest project.

What is Jest?

Well, this was the opportunity we were presented at the start of the fellowship. We were over the moon to have got this project!

Jest is a JavaScript testing framework designed to ensure the correctness of any JavaScript codebase. It allows you to write tests with an approachable, familiar, and feature-rich API that gives you results quickly. Jest is well-documented, requires little configuration, and can be extended to match your requirements. Jest makes testing delightful.

Where did we start?

Before contributing to any open source projects, you must use it. You would find it very difficult to contribute if you don't know what the project is supposed to be doing. That's how we started. Using Jest to write our tests for applications we had created before.
Following the first week of the MLH fellowship, we had a meeting with the contributors of Jest to better understand the roadmap of the tasks and projects assigned to us. It was a productive session and helped us gain insight into the project. Reaching out to the contributors is highly recommended if you get stuck while contributing to any open source project. You can reach out to the community members via the mailing list.
The next stage was understanding how the project works. This was the week of diving deep into the code base of Jest. The documentation & conference talks come in handy while doing so. Since you are working on the project as a beginner, it is always a good idea to provide future contributors a form of guide that will help them in contributing, just like we are doing with this blog! Another way of getting familiar with the project is debugging the workflow & taking notes via discussions to further research upon. Coming to how to start making contributions, it is suggested that one starts with some beginner-friendly issues if they are new to the project. This is a great way to get some momentum going and getting familiar with the contribution guidelines as well.

Do we need to master using Jest to contribute? 🤞

You don't need to be an expert to contribute to Open Source. If you are a beginner, you can surely find projects that can help you grow your skillset and get real-world software development experience. If there is a learning curve involved, like there was in Jest for us, that is a good thing because now you have a learning opportunity while making contributions.
Coming to the point of how to understand such large codebases? Well, you don't. The project is divided into individual packages that make it easier for you to navigate and explore the codebase. You can have a general idea about the workflow. You can dive deep into packages separately when required to contribute to it. For this, you can take a look at the issues section of the GitHub repository, and filter issues with easy to get started ones. And ofc, if you get stuck anywhere, the community is there to help you!

Okay, I know the bug/feature proposal. Where do I start making changes? 🤔

It starts by opening up an issue. Your issue should be well documented and explain the motivation behind it. If you are requesting a new feature, you should mention what the feature is, how one can go forward to implement it & why it is important. If your issue relates to solving a bug, you should mention how to reproduce that bug. What changes are breaking due to it & what the expected behavior should be? You should have a detailed explanation of what you want to achieve and how to achieve it. Ask for feedback on your issue from the community members to get more insights on it.
Documenting is crucial as it helps others help you. If you are already familiar with how to solve the issue, you can open a pull request for the same. Documentation plays an important role here as well. You should mention what changes you made and why. What issues you were facing and how you fixed them. If the change that you have made is going to affect the existing codebase. And remember, don't forget to add a line in the logs!

The workflow of a test run 🚀

I believe this post by Kunal does justice to it Jest-architecture

The importance of community 👥

In your open source journey, the community will play a very important role. The sole purpose of having a community is to make collaborations and learning easier for everyone. This lets us create software that is used and. contributed to by people around the world. From a beginner's point of view, your interaction with the community is what's going to help you at most times. In times when you are facing a blocker, need more input and suggestions on a particular topic, or want to get your PR reviewed, the community members are the ones who will point you in the right direction as they know the project inside out. Your peers are also a major motivation. Taking an example of the pair programming sessions/debugging we had, helped us resolve bugs (more about that later) in a faster and efficient way.

How to ask questions & request feedback

Don't just say Hi in chat! This can’t be stressed enough. Everyone is quite busy with their lives, including you. So add a short and concise form of your question in the discussion channels. Tag an appropriate person (look at the channel rules first).
Try providing links or short-reproducible forms of your problem to the other person. This increases the chance of your question getting more attention and solved sooner.
Ask 10 short questions instead of a long one (not too short). Asking concise questions helps the person in receiving an answer sooner, as not much time is spent in understanding the context of the text as compared to say a long question.
This brings us to another good point, break large PRs into smaller ones if possible! This is highly encouraged as it helps the reviewer understand the changes in a more simplified way and this breaking down of process leads to effective discussions and feedback.
Mention the steps to reproduce the error in your message, so that others can know what you are dealing with. Also mention what you tried to fix it, and what it led to, to avoid duplicate answers and things like "I already tried that".
Requesting feedback is important when making contributions. Showcase your work in a well-defined manner, so that it is clear what you had tried to achieve. This includes providing information about changes you made and how it affects the functionality of the code.
Code readability is also very important. Following the organization standard, providing comments where necessary, is required.
Don't spam the channel if you don't get a reply immediately. Be patient and wait for the appropriate amount of time before asking again.

So it was the end of a general contribution guide for opensource. Let's take a deep dive into how we tackled our problems and some tips with Facebook's Jest project

New Feature: Reporting individual tests

feat: report Individual Test Cases #10227

sauravhiremath posted on Jul 02, 2020

Summary ⚡

[Part 2 of 2] - Depends on #10293
Initially jest runs would update testSuites incrementally, and update individual test cases batch-wise. This PR attempts to report the progress of the individual (atomic) test-cases.
Supported for Jest-Circus Runner.
Introduces eventListeners for the worker processes to send back the test results to their parent.
Handles progress reports both when running tests parallelly (spawning workers) and inBand (Sequentially).

Previous References and suggestions

Fixes: https://github.com/facebook/jest/issues/6616
Reference: https://github.com/facebook/jest/pull/9001

Test plan ⚡

[x] Add custom message support in jest-worker
[x] Update onCustomMessage functions to pass tests (caused by updating its Type) API implemented as suggested here - https://github.com/facebook/jest/issues/6616#issuecomment-402782271
[x] Fix the memory leak issue

Current Implementation

Authors

Co-author - Saurav M. H @sauravhiremath Co-author - Kunal Kushwaha @kunal-kushwaha Co-author - Rogelio Guzman @rogeliog

Acknowledgements

@kunal-kushwaha for his super awesome contribution 🚀 🚀 @rogeliog for laying down the foundation for this PR. 🚀 @SimenB and @jevakallio for their time and reviews 👏

View on GitHub

Sometimes for bringing in a new feature you will have to go through the majority of the child repos and may get overwhelming. It is pretty normal for monorepo projects. In this case, make a rough chart or flow diagram so you know what you are doing and not get lost in the huge project.
Okay okay, we had one tiny advantage here. The problem was already discovered. I cannot stress enough how much a well-defined problem is equally important as compared to its devised solution.

The problem:

It seems like Jest currently only reports progress when a complete suite passes. We propose that instead, it should report progress every second for individual test cases. (well we made it much better than per-second, more on it later)
Otherwise, the progress output is confusing. "Tests: N" being a separate line in the output gives the impression that it's just as granular as "Test Suites: N" and will be incremented immediately when a test case passes.
So the problem text alone can be confusing. And you bet just reading the above statement is not enough. So, here comes an explanatory image

The solution

Breaking the issue into separate features

Support sending Custom Messages to the parent from a worker thread
Report the progress for individual test cases

Support sending Custom Messages to the parent from worker threads

It adds the jest-worker ability for workers to send "custom messages" to their parent while they are still running. This will eventually allow us to report per test case updates to the reporter.
This part was particularly tricky, as there were some legacy code which was very confusing to work with (pretty common with huge codebases)
Leveraged the introduction of eventEmitters in Nodev10 (used emittery which is a typed form of node eventEmitters) to send the messages instead of using the traditional callbacks.
The emitter was used only for parallel runs (supporting worker threads). For in-band runs, there wasn’t much modification needed.
Modifying a major chunk of the jest-worker module, this PR was landed without any breaking change.

Report the progress for individual test cases

The proposed feature:
- Initially, jest runs would update testSuites incrementally, and update individual test cases batch-wise. This PR attempts to report the progress of the individual (atomic) test-cases.
- Supported only for jest-circus runner.
- Introduces eventListeners for the worker processes to send back the test results to their parent using emittery
- Handles progress reports both when running tests parallelly (spawning workers) and inBand (Sequentially).
Again the proposal is incomplete without a demonstration for it

Finding bugs is a learning opportunity - The Memory Leak

How did we find it?
- Thankfully there was a memory leak test inside jest. Essentially it created a shallow copy of the objects and then deleted all the references (or edges) to this node. (I refer to the node here in global object heap context.) If the object was still not garbage collected then it means there is a memory leak because there are still other objects referencing it. This is essentially how memory leak is detected. Fortunately, we don’t have to code this manually, someone has already built an npm module for it.
What we tried and for how long?
- Oh boy! This was the most tiresome part. Knowing how the memory leak worked was not enough to debug this. At first, we tried manually finding any naive mistakes in the codebase, but it was of no avail.
- Next thing, we took the memory snapshots at various intervals while running tests. Here we run the tests inBand, so it's easier to understand where things are going wrong.
- Then we profiled these snaps and tried finding useful information here. No luck here too.
- Did a heap memory log of the tests, but nothing out of the blue here too.
- Now, we used the oldest recipe in the cookbook, as recommended by the master chefs. NUKING THE CODES! (kudos to @taneliang for finding this hidden recipe)
- We started removing chunks of codes, to see if which part was causing the issue. This was our last resort and we started with the place we thought was most vulnerable to the memory leak. And, VOILA! We found it
How did we fix it?
- We found it was due to a direct reference for the object being sent to the worker thread. And even after the worker process was orphaned, it still held the object reference with it. So, we solved this by creating a deepCyclicCopy (which is a fancy way of saying we did a deep copy of an object which may or may not have cyclic references) and sent it to the worker threads again. And yes, it worked!
- It was a one-line fix. JUST ONE LINE!

sendMessageToJest = (eventName, args) =>
    this.eventEmitter.emit(
      eventName,
      deepCyclicCopy(args, {keepPrototype: false}),
    );

What did we learn?
- But, coming to this one line was one of the best journeys we had. We learned a lot about
  - Chrome v8 heaps.
  - How the garbage collection is handled internally.
  - How does Node maintain different heaps and inter-references between the worker thread it spawns.
- These were some of the things we learned when fixing this bug.

So, concluding it…

Yay! You survived the nerd blog. Here, have a cookie 🍪

Also, We are no experts here and neither is our work perfect. Just some fellows sharing their experience. You may agree or not agree with some of our points here. And it’s completely fine, we respect you for questioning our work. This is just a roadmap we took and laid, you may either tread this path or find your own. Both have their fun and hurdles :)

So that was about it. That’s how we started with a project we had never contributed to before and landed a new feature during the Fellowship. A huge shout out to all the community members, MLH fellowship team, & everyone else for being a part of this journey and empowering everyone to achieve more.

Thanks for reading.

About the Authors

About Kunal:

Hello everybody! My name is Kunal and I am a junior from India. My interests include DevOps, Machine Learning, and Web Development. I have been a part of various open-source programs like the MLH Fellowship, Google Summer of Code, Google Code-I, etc. Outside of work, I am a core team member of various college societies and programming boot camps where I teach students Data Science and DevOps. I also volunteer at a community (codecau.se/yt) which I started, as an instructor, & have thousands of students learning with us.
I have been contributing to open-source since my freshman year and it has made a lasting impact on my career journey. My goals include working on products & services that have an impact on the world. Hence, I would love to work for an organization that’s leading the future of the industry.

About Saurav:

A friendly neighborhood developer from India :D A computer Science Engineering student doing specialization in Bioinformatics. Absolutely love working on DevOps and Full Stack Web Development. Have experience working on product and platform architectures for startups. Have been part of Technical Chapters and delivered Talks on Deep Learning and Product Deployments. Keen believer of open source community. Currently part of MLH Fellowship and been an OSS contributor for 2 years.
My work was and always will be driven towards making people’s life easier and building products that create a difference. To sum it up, I love my Arch and OpenSource :)

Building a multiplayer game using WebSockets - Part 1

Saurav M H — Mon, 06 Jul 2020 20:00:53 +0000

A definitive guide for building your multiplayer game on a browser the right way using socket.io on NodeJS and React. Ranging from folder-structure to project deployments

Getting started with a unique idea is important. But it is much more crucial to set the foot in the right direction when starting with a project.

"The future belongs to those who learn more skills and combine them in creative ways."

Robert Greene, Mastery

Why another tutorial?

This is very important to clarify. There are tons of guides online focusing on “Getting started with socket.io” and it gets more frustrating when all of them are chat apps. But here we will focus on “Getting started with building a scalable project using Socket.io”, which is not a chat app :).

This guide will explain more about the Code Infrastructure rather than focusing on UI/UX. So bear with me if UI doesn’t look so appealing.

What is socket.io?

Socket.io is an abstraction built over the WebSockets protocol. Websockets is a protocol that allows a bilateral synchronous exchange between a client and a server. Or a bi-directional communication pipe in simple words
Note: Here WebSockets and socket.io will be used interchangeably (even though they are different in some aspects) unless stated otherwise.

Why WebSockets and not HTTP?

For real-time multiplayer games, we require the client to send information packets to the server and server sending/broadcasting data simultaneously. This can’t be achieved using HTTP as the client has to send a request to the server to actually receive something. This isn’t a viable scenario for multiplayer games.

What do you mean by the “Right way”?

The Right way — here means getting started with a Codebase which can be easily scaled further, and simultaneously not creating much hassle for smaller projects. It addresses common practices that can be followed for a much more modular project. This in no manner states it is the official way to build WebSockets projects. But is simply my opinion on it, you can easily swap out bits and parts of the project you don’t like :D

What is the project about? ⚡⚡

So coming to the core of the guide. This guide explains building a “multiplayer socket.io game” through a real-world project. This way it is much easier to see the project in action and we know the code/infrastructure works too! The project is…

Multiplayer Football Draft Simulator

What does this game do? ⚡

It is a turn-based multiplayer game. Where people enter and create a room. Other people hop into the room. Then the game begins where all players are shuffled and first-person gets the chance to pick the football-player he wants. He can search from the list of players (viewing their stats, position, ratings, and other details) and confirm his selection within the allocation time. Now, the turn is passed to another player. This repeats until every person has picked their whole football squad.

Pretty simple? Yes/no, it doesn’t matter. We will see the detailed breakdown of the code infrastructure behind this.

Server Architecture ⚡⚡⚡

Game architecture

The above diagram explains how everything is connected from a birds-eye point of view.

Both the HTTP and Websockets server in this guide uses NodeJS. We are using Redis DB as socket.io supports its integration out of the box also the read/write operations are much faster as data is stored in-memory. MongoDB is used as a more permanent storage solution. The game results and the user teams for each room are stored in MongoDB after the end of each draft round. It also stores user credentials if they wish to register (this project has an optional registration/login step).

The WebCrawler is written in Python3, using the Scrapy library. The football players dataset has been crawled from https://sofifa.com. It consists of more than 20,000 players including their rating, statistics, worth, clubs, etc. It also has an optional data-analysis jupyter-notebook for playing with the scraped data, but its discussion is out of scope for this guide.

The Folder Structure (ExpressJS + MongoDB + socket.io)

NodeJS does not enforce code structure on you. This gives us a lot of flexibility to design them, but you can go horribly wrong which can lead to difficulty in maintaining and scaling the projects. This particular project structure can be used when working with sockets + NodeJS

Let's dive in how the project codebase is structured

.{src}  
├── controller  
│   ├── authController.js      # Handles authentication requests  
│   ├── searchController.js    # Handles search queries  
│   ├── userController.js      # Handles user profile operations  
│   └── ...  
│  
├── database  
│   ├── db.js                  # Initialize DB connection  
│   └── ...  
│  
├── middlewares  
│   ├── authenticated.js       # Decode and verify JWT token  
│   ├── error.js               # Common Error Handler  
│   ├── logger.js              # Control logging levels  
│   └── ...  
│  
├── models  
│   ├── roomsModels.js         # DB model for rooms  
│   ├── usersModel.js          # DB model for users  
│   └── ...  
│  
├── schema  
│   ├── rooms.js               # DB Schema for rooms  
│   ├── users.js               # DB Schema for users  
│   └── ...  
│  
├── socker  
│   ├── roomManager.js         # Socket listeners/emitters handle  
│   ├── sockerController.js    # Control socket connections  
│   └── ...  
│  
├── app.js                     # Entry file for the project  
├── env.js                     # Store environment variables  
├── routes.js                  # All routes initializer  
└── ...

The backend is divided into different directories according to the project requirement. If you want to skip or swap certain modules, it is as easy as adding another directory.

Most of the sub-directories are common to node projects, so I won't explain them in detail here. The comments beside each directory should give an idea of what it is.

We will focus more on subdirectory socker/. This the place where your core socket.io code will reside.

The entry point for socket.io (App.js)

Here two servers are created, app — listening to HTTP requests and server — listening to WebSockets connections. It is recommended to keep them connected to different PORTs to avoid confusion.

You might be wondering what is "socker" on line 1 and 8.

What is socker?

Socker is just a function alias (because I am building a football draft game here, duh!). This function attaches the Server (passed in line 8 of app.js) to an engine.io instance on a new http.Server. In simple words, it attaches the socket.io engine to the server passed to it.

But the above code doesn't explain much. Now, the following questions arise:

How do I interact with connected clients?
Where are namespaces?
Where are the Rooms/Channels?
Most importantly, where is the game?

Creation of Namespaces and why?

Namespaces are an important feature of socket.io. It represents a pool of sockets connected under a given scope identified by a pathname like /classic-mode , /football-draft , /pokemon-draft , etc. This is basically creating different endpoints or paths. It allows us to minimize the number of resources (TCP connections) and at the same time separate concerns within your application by introducing a separation between communication channels. By default, socket.io connects to the/ namespace.

Creation of Rooms/Channels and why?

Within each namespace, you can create arbitrary channels or rooms. This further allows you to create connections which sockets can join or leave . Here we use channels to create different rooms where users can join or create to play together.

Example of joining a room

The join() operation checks if the required roomId is already created. If not, then it creates the room and adds the player to the given roomId. And if it is already created it joins the room directly.

A wholesome example summarizing the use of namespaces and channels:

That's it for Part I. The code structure shown here works for medium size projects quite well. If you are building a quick prototype, you may omit or combine the schema and models folder. Do not hesitate to make the project lighter if required :)

What if the project size increases? The current structure might not work well. You can create sub-folders as per required services and components ( user-authentication , __tests__ , analytics , etc.). You might even create microservices i.e. deploying each process or service individually allowing you to load-balance or scale only the processes under heavy-loads.

Remember do not over-engineer your product, build and deploy in stages!

Be it a joke or an engineering-project, no one likes overdoing it :)

If you are interested, here are my project links:

Backend (Websockets + HTTP) - https://github.com/sauravhiremath/fifa-api
Frontend (ReactJS) - https://github.com/sauravhiremath/fifa
WebCrawler (Python3 + Scrapy) - https://github.com/sauravhiremath/fifa-stats-crawler

Next article/articles will focus on:

Creation and handling of rooms for each namespace.
A brief explanation of the client-side of the project (in ReactJS)
CI and Deployment of each project package.

Let me know if you have any questions or suggestions for future articled

✌️️ Have a great day!

Follow me on twitter @sauravmh for updates!