Abhishek Rathore

Okay, sorry. I'm Abhishek Rato. I've been working in the IT industry for the last 12 years, and currently, I'm working at InJoint Gaming, a gaming company where I'm a senior technical lead. However, I'll soon be promoted to a solution architect or technical architect, a similar position. My role here has involved transitioning into multiple roles, including the center of excellence and leading a team of 20 to 28 people. At present, I'm managing the RGS, Remote Gaming Server, which is built in Golang, but I have extensive experience in Node.js and TypeScript as well. It's a microservice-based application, with some parts developed in Golang and new modules developed in Node.js. I'm familiar with Node.js, React.js, Next.js, and I've worked on AWS. I'm also heading the DevOps team for the Remote Gaming Server, which involves deploying microservices into Kubernetes. I'm quite familiar with AWS EKS, ECS, and other services required for deploying an application on AWS, including RDS. We're using MySQL and the Elasticsearch stack, which includes Elk, Kibana, Logstash, and Elasticsearch. In my previous project at the same organization, I was part of the center of excellence, and I built a framework called Quest. It's an internal framework used for game development, specific to the domain of casino gaming and related types of games. The framework is built in TypeScript and based on the Pixy.js library. It also includes a GUI tool built in Electron. The whole team was headed by me, and the framework provides a complete end-to-end solution for developing games of this type. With the GUI tool, developers can easily input assets and create a game, which can then be tweaked and additional features developed. That's my introduction, thanks.

To facilitate communication between a React based front end and a Node.js back end for real time data updates. So, we can use normal HTTP request and response framework AJAX calls, or we can use Node.js's fetch API as well. We can use XHR also. There are multiple ways to do communication between a React front end and a Node.js. For the Node.js backend service, I'll prefer implementing Express to accept HTTP requests.

Designing a scalable web application architecture involves several key considerations. One approach is to use a microservice architecture where each module is categorized into a separate microservice with its own database requirements. This allows for easier implementation and scalability. For example, based on the requirement, every module will be categorized into a microservice. It will have its own database requirements. We can implement one API gateway so that microservices do not interact with each other directly. Communication will flow via the API gateway. This makes it easy to scale the application because we can create replicas on the cloud. We can run multiple replicas if the load is there. We can use ALB load balancers to distribute the load into different replicas of the microservice.

Custom measures I take to protect web applications from SQL injection and access it. Alright. Sorry, I'm not aware of this answer. I'm not ready for this answer.

Of sticky sessions and load balancing and its impact on web application performance. So, sticky sessions and load balancing is, so for example, let's say we have a Node.js application and a microservice is there, and multiple replicas of a particular Node.js application are running. Sticky sessions in AWS load balancing means that if user 1 creates a session and two replicas of the application are running, then sticky sessions means the session data or communication will always happen with the one single instance of that application. So, for example, there is Replica1, Replica2, and then we have this User1. Let's say user 1 logs in and opens the application in his web browser, and it gets attached with, let's say, Replica 2. So, during the whole session, the sticky session means this user will always be attached with Replica 2 unless Replica 2 goes down because of some issue. Otherwise, the session will remain with it.

Actual pattern that you would use to build a scalable real-time bidding system, and how would you ensure its responsiveness under heavy load? Which architectural pattern would you use to build a scalable real-time predictive system? Alright, so I haven't worked on anything like this before. Yeah. So I haven't worked on any bidding system, but for this, I would prefer using WebSockets because it has to be real-time bidding. And, even if all other users need to be aware of it. And what I would prefer is to use Kafka or some other service which will make it very easy for different microservices to connect with each other. So Kafka provides an event system, an Event Bus, where microservices can send events to Kafka and Kafka then allows some other microservice to listen to that event. So in this way, it is very easy and there's no law left. And it ensures that the event is delivered to all subscribers. So in this way, implementing a real-time system will be very easy.

When deciding which design pattern to use when starting a new feature or component, we need to understand the requirement of the feature or the component we are going to build. For example, if the preferred framework for everyone is always MVC, but it depends on if we need to implement a factory pattern or adapter pattern or what is required. It depends on if the application is going to be a real-time application or it's a normal application which can be built on HTTP. Based on such factors, based on these requirements and load requirements, we decide which design pattern we should use for a new feature or component.

```javascript // The class implementing the singleton pattern class Singleton { static instance; constructor() { if (!Singleton.instance) { Singleton.instance = this; } return Singleton.instance; } } // Usage let a = new Singleton(); let b = new Singleton(); console.log(a === b); // Expected to print: true ```

The data might not be displaying as expected on the web page due to several reasons: Fetch data then response. Set data response to Twitter. One thing which I noticed, the dependency area of useEffect is empty. So I think there should be something because useEffect will get executed if obviously, if the component is initialized on the 1st time, and then after any of the dependency variable gets changed. Second thing is, fetch data because I cannot see the implementation of fetch data function, but generally, what happens if you use something like x u s or Fetch API, then you will have to convert into JSON as well, kind of dot JSON or something similar if it is a if you are expecting JSON in response. That could also be one thing which may break, which may cause the web page to not show the data properly.

Blind has suffered repeated outages due to its monolithic structure in the past. Then I want to move to a microservice architecture. How would you design the transition to ensure high availability and which observability metrics would be critical during the process? Alright. So yeah. So a monolithic structure is where the complete code is present in one single application, although it may still be modularized, it is not properly categorized into microservices. A microservice is a combination of an application, a module, and the database. So how would we design the transition to ensure high availability? So what we need to do is categorize the microservices based on the functionality of the application. So, based on the modularity and requirements of the application, we'll divide the monolithic application into different microservices. We'll ensure that the backend part is properly implemented in Node.js so we can easily deploy the application and make the microservices stateless, so we can easily create replicas of the microservices. To ensure high availability, these stateless microservices can be created in different availability zones. High-level, to make sure an application is highly available, we need to ensure it is deployed in multiple zones, more than one zone. A multi-AZ deployment is required. For example, if one deployment zone goes down or the application in one zone goes down, our load balancers can directly point to another availability zone. So that's one thing. Plus, there should be multiple replicas running based on the load. I would recommend having at least one replica so that if the main replica goes down, the ALB can point to the replica. It's also important to keep replicas because if you have high load, it's better to have multiple replicas, then load balancers can distribute the load and it eases out the application.

Building a full stack JavaScript application, how do we ensure that the memory usage is efficient both on the client and server side? Yeah, so how do we ensure that memory usage is efficient? So, we can ensure it by writing code that is properly formatted, with complexity that is not too high. The objects, if any, being created should be destroyed after being used. And on the server side, there should be no memory leakage. To ensure this, how can we do it? We can test it using Chrome or Node.js profiling tools. Based on that, we can identify if the memory keeps going up. If we use that, then it means there's a memory issue or memory leakage issue that needs to be addressed. And if you perform any action, the graph will go up, but then it should go down gradually as well. If it's not going down, then it's an issue that needs to be addressed.

We have questions about what testing framework and strategy would you recommend for a React application with a focus on user interface consistency and integration. So, we can use Mocha, and then there's Jest. I think these are the two good frameworks which I would prefer using there are plugins available for just which we can use for React applications. With a focus on user interface consistency and integration, so yeah. We can use the React plug-in to ensure that DOMs are being created on time and these are working fine. Secondly, we can write some integration tests as well. For example, we can use Test Containers or something which runs a test container for any database, for example, if you're using MongoDB or any MySQL or NoSQL database. We can ensure that the integration, the connection with different databases, is working properly. And we can mock different microservices to ensure that the connection and integration works with different API gateways or whatever the application will be using. We can write such test cases to ensure that it is fine. Plus, we can write test cases to ensure business logic as well. For example, if you are using Redux or something, the data which is coming to it, the logic we have written, the input and output value is expected as per expectation.

And would you choose Redis over MongoDB for session storage considering performance and data structure flexibility? So, Redis is more of a cache database, and MongoDB is a NoSQL database. If you want, we can use Redis as a session storage. However, I'll generally prefer MongoDB, but we can keep the session storage in Redis and set the expiry time similar to the sessions. In this way, Redis will be much faster for session storage but will be less flexible. But if you use MongoDB, you'll have more data structure flexibility because in MongoDB, you can store data and perform CRUD operations, and everything is available because it's a complete NoSQL DB. However, Redis is more preferred as a cache.