Karan Jain

About my background by giving a brief introduction to myself. So, as you know, my name is Karanjan. I'll be working as a Node sales developer for around a decade now, going purely into a technical background. I worked for a decade now, going purely into a technical background. I worked in the health care domain. Is it recording? Yeah. So I've worked mostly in the health care domain. Couple of projects which I've worked on in the health care domain is due to insurance and the claim adjudication system. Those were my recent projects. Before that, there were projects, like, really straight related, into the US and Canada, the MLS, and the East Bay, open houses. So we pulled up all that information from the MLS data warehouse, and then we used to keep track of all the data in our database. Then there were some drip campaign related functionalities, which we used Twilio and SendGrid. We used to send scheduled SMSes, and all the emails to our customers. And then I worked on another real estate domain, like fgfggone031, if I remember correctly. That is the one domain where I worked in the real estate. Then my first project was a very interesting project, which was a Raspberry Pi with the Node JS server in the US and Angular. So we used to have a display set up in different malls in Bangalore, and in some restaurants as well. So we used to play the advertisements for our customers onto those displays, and that's how the company started getting revenue for the company and for the employees. And I started as an install developer. Like, I worked for around six years as a install developer completely. Then I started focusing more on AWS technology, so I stopped working more as a front-end developer. I started working as a back-end developer, plus the AWS serverless technologies like Lambdas, SQS, Kinesis, S3, DynamoDB. So I've worked on other Amazon services, which I've worked on, including RDS, Glue, Step Function, and that is also part of my experience.

To answer these questions, I've been using notes. We can apply a lot of load balancing on top of having multiple servers. We can also apply low load balancing on top of it. If we have a lot of traffic, that's one step we can do, or we can start using the Lambda function serverless technologies. If our functionalities can be processed within a couple of minutes or seconds, then Lambda functions are fine. It's going to take more than 15 minutes for Lambda to work, after which it doesn't work. We can also go over the firewalls as well. So, using those firewalls, we can achieve all those things. And we're, again, on the top of a bargain. Maybe we have to apply load balancers so that we can distribute our requests to multiple servers, and we don't have to apply the firewalls. But in the container part, yeah, we can apply the load balancer. I'm talking about the last three containers. There, we can apply a load balancer. If you're using EC2, there also, we can have multiple servers and then apply a load balancer where the traffic can be distributed. What other ways are there? To configure for an unexpected large volume of incoming requests, another part is, assume you're running a very well-performing 2 or 3 servers where you're able to perform well, but unexpectedly, you start getting a large volume. And you can have a scaling group. Yeah. You can add a scaling group here according to your need. Like, if your server is growing more than 80% of CPU usage, you can have one more server spin up that can handle your other requests. Similarly, you can have the same scaling loop to reduce as well. Like, if your usage is now going lesser than 30%, then whatever servers you have spun up, you can just close and then terminate them.

So, we enter branch security in kit for parallel feature developments and hard fixes. For parallel feature development, we basically start by working in the development environment. We have four environments: production, eval, stage, and development. We work in the development environment for all normal functionalities. According to the epic, we create a branch for the feature. We start working on it in that branch. Once our development is done for that particular feature or story, we deploy the whole branch into the stage environment. For hotfixes, we create a hotfix branch from the main, and then we deploy that same branch. Once we're done with the development for the hotfix, we deploy that same branch to development and stage. It's tested by different parties: development is tested by developers, stage is tested by testing people, and eval is tested by the business. Once everything is fine, we use that same branch to deploy into the master. That's how we work with hard fixes.

How would you aggregate a node application for high availability and fault tolerance in the cloud? It's more of a same answer to having a lot of traffic. So high availability, maybe we can have multiple servers running in different regions. Like, I'm taking an example of AWS. We have multiple regions. So we can if our user base is spread across the world, then we can have multiple servers spinning up according to whatever is nearest to our demographics. Like, assume a lot of them are from India, then we can have a server running in Mumbai, and a lot of them in the US and in US East 1 or US West 2. So we can deploy the servers there. That will achieve high availability. And fault tolerance, again, scaling groups can help with that, or maybe alarms can help with that. So an alarm: what can happen is if any of the servers go down, it can trigger an alarm. And from the alarm, maybe we can trigger a scaling group, which can help us spin up a new server and terminate the older one. That's how we can achieve fault tolerance as well.

What criteria will you use to decide between deploying a Node.js application? To be honest, I have never used the server or GCP. Mostly, all of the companies are moving toward serverless. I'll say AWS is much better because I've been using AWS for a long time, and working with AWS, I should not say that. AWS has much more resources as compared to SQS, KNSL, ClueJobs, Fargate, ECS, Lambdas, and step functions. Orchestration is very easy in AWS. To be honest, I don't have much knowledge on the Azure or GCP. I've not worked much on them, so my answer is totally on AWS.

In notice, how would you efficiently manage sessions in distributed environments? Manage sessions efficiently in a distributed environment. There are multiple ways, and it should not be that difficult. Again, not talking about AWS servers because WebSocket is a bit tricky in serverless environments. Managing sessions in EC2 instances is not efficiently managed. Once a WebSocket connection is created, as in Node.js, everything is rest-like, we create a normal API. It's stateless; if you want to maintain a state, you need a session, then you can have a WebSocket created. Another way could be using Cognito, which maintains a continuous session for a particular user unless you're not signed up. Maintaining efficient sessions. We can manage sessions in Node.js by using sockets. Most APIs are stateless, so if we want to use a stateful API, we can go for WebSocket. Otherwise, we can use tokens. Assuming it's a stateless API, so basically, we can manage sessions using tokens. Whenever the user logs in, a token is created, which helps manage the session of that particular user. We've kept the session for up to 1 hour. Within 1 hour, the user can perform all authenticated operations. Otherwise, if he tries to perform any unauthenticated operations, he will get an error. As soon as the token expires, if he's using the same token, he will get an error. It's the client's responsibility to generate a new token as soon as it gets the error. That's all. We can manage these sessions.

Fetch Data response dot JSON. Consult dot data e f. How do you read this to correctly handle errors in an asynchronous context? Try catch. So, basically, I'm not returning anything. They're just I kept printing out. The issue lies in the way the try-catch block is being used. The current implementation is: ```javascript try { const response = await fetch('https://example.com/api/data'); const data = await response.json(); // some code } catch (e) { console.log(e); } ``` In this code, when an error occurs, the `console.log(e)` statement will print the entire error object, which can be quite large and not very informative. To rewrite this to correctly handle errors in an asynchronous context, you can modify the try-catch block to print only the specific error message or the error stack: ```javascript try { const response = await fetch('https://example.com/api/data'); const data = await response.json(); // some code } catch (e) { console.error(`Error: ${e.message} (${e.stack})`); } ``` In this modified code, the `console.error` statement will print the error message and the error stack, which should provide more informative error messages. Additionally, you can also use a more descriptive variable name instead of `response` to avoid potential conflicts with the global `response` variable: ```javascript try { const fetchDataResponse = await fetch('https://example.com/api/data'); const data = await fetchDataResponse.json(); // some code } catch (e) { console.error(`Error: ${e.message} (${e.stack})`); } ```

Examining the following note is an express code snippet. This indicates a performance issue in setting the database. Can you enter what might be causing the changes and how it could potentially be fixed? Constant users await user dot find users dot users. It's just to await user dot find. Then once users are found, you can get the UID, also request the parent ID. Instead of making the first one, which is also a database call, the second one, I don't know. Maybe that's just some internal JavaScript function that helps to find. So what we can do is in the database query, while making a call at the 1st, 2nd, 3rd line, we can optimize it because as you know, right now, you have a user, 100, 200 users, when it goes to millions, pulling up all the million records should not be the correct approach. As you are getting the unique ID of that user, you should pass that unique ID in the database call and pull up the one record itself, not more than 1. That way. That should be the only solution.

How do you ensure Cloud Native Node Trust application responds gracefully to both predictable and unpredictable failure scenarios? Failure scenarios. So, basically, failure scenarios, your message has to be correct so that the user understands what the failure is. Second thing, for that's about repeatable scenarios for unpredictable scenarios. Again, whatever the API was and is intended to do, in case of any failure, the data should roll back. That is the first thing. And then, it should tell the user if the data gets rolled back, then it should not mention to the user that there is some error, so they can retry again. And in the case of unpredictable or even in the predictive version, we should set some alert that this error came up so that the respective team can look into it. Anything else? Yes. You can set up CloudWatch alarms, which can be integrated with a lot of things. You can have SMS or maybe Splunk integration as well, then that can help to get the notification.

Techniques I would use to reduce the complexity of large Spring Boot application is Spring Boot. To reduce the complexity of large Spring Boot application, I am not sure about what sort of complexity happens in the Spring Boot application. What could be done is I've never logged into the many of the Java code. Spring Boot application complexity. Maybe if any code has complexity, try to divide it into chunks so that each and every functionality is understandable, have a proper commenting. What else? So that was an argument installed so that it can force you to make it a smaller function. Yeah. Complexity. If you found that complexity is more than 15 lines of any particular code, it asks you to shorten it down. We can also do code refactoring, extract methods, use dependency injection, and modularize the application. Major things divided into chunks so that those chunks can be reused for many other things.

How do you perceive the trade-offs between using Java and Python for Microsoft-based offline applications, and there are some advantages to both. I've not worked much with Java, but I've thought about the trade-offs of Python. Java supports basic or multiple processing, maybe by using threads or worker threads, and we can do similar things in Python, but it's very difficult to achieve because when I work with the Python team, I suggest they should achieve parallel processing of certain tasks. Ideally, these tasks shouldn't depend on one another because they're independent, and you can call them and say they're little difficult. So, I would say I shouldn't choose Python. I should choose Java if I have only these two options. I think code in Java is very strict, but everything is class-based. So, every variable and everything has to be strict, like.NET. Python is similar to Node.js in that you can define any variable to anything. However, sometimes playing with objects in Python can be tricky. In Node.js, any JSON object without a key will give you undefined, whereas Python will give you an error if the key is not present in the JSON. This will happen similarly in Java, but Java has everything properly data-structured. If you're accessing a variable that's not of the correct type or interface, Java will give you an error while coding. Java is complex, so there must be some issue with it, which is why people are moving to other languages or Python. Maybe microservices are a factor. If you have multiple teams, some knowing Java and some knowing Python, you can divide tasks between them to achieve functionalities faster. Unless you think that in the future, a member of the team will be laid off, and then it'll become difficult to handle the code, you should use one interface, either Java or Python, or Node.js. That's what I can think of.