Devendra Yadav

So myself, and I'm a developer as well. So I have started my career with them as a Java developer, then I moved into a Node.js developer. Then I have experience with the full stack, like, on the back end side, I am known as a developer, as well as with a few frameworks. And I have also experienced with AWS and Azure. And on the front end side, I have experience with Angular, AngularJS, and ReactJS.

So for data consistency, I will use "like" on the front end side, I'll use the verification for forms. So let's say if I'm submitting some forms, I will validate the username and password. Passwords will be character long and that. After that, on the API side, I can also assure that all the required information which is coming from the front end side should also be validated on the back end side using some libraries, actually, class validator and all. And after that, on the back end side or on the database level, I can assure that all the data types that they are sending is perfectly fine. So if I'm working with MySQL, I'll use the character length and the data types. So it'll be appropriate, what they can even require.

Design is ready to implement road based access control in a Node JS SQL API connected to area at front end. So for implementing the strategy to implement role based access control in Node JS, we can implement a system where we identify the type of user when we receive their credentials. We can save that information and provide all the roles and permissions for that user. We can create a JWT as a token. Once the user sends their username and password, we will provide that JWT token. And after subsequent requests, we can review that token. We can decrypt the token, which is the payload of it, and check what type of user it is when they signed in. And based on that, we can see if this particular API or this particular permission is accessible to that user or not. For example, if I'm logged in as an admin, I have full access to permissions. And if I'm logged in as a user, I don't have access to those permissions. To implement that, we can implement multiple plugins according to the JWT token. On the Node JS side, we can implement some middleware where we can check if this particular API is available to that particular user or not based on the authentication problem we have received.

So how would you prevent memory leaks in a long running Node.js application? To prevent a memory leak, first, we need to allocate appropriate memory for the heap stacks. And to allow that, we have to have at least 1 GB of RAM and at least half a CPU available to Node.js. And apart from that, if we have that long running process, we need to send that particular process as a child process, or we can send that particular process as a subprocess to it, and provide all the necessary information. So that particular process, which we wanted to prevent memory leaks, should run its own threads, and it should use its own memory and not just the main process's memory. From that perspective, we can check if that particular thread or process will not impact the main application of the project.

What would be your approach for catching data in a Node.js application interfacing with a React front end? For the caching mechanism, we have lots of ways. We can let's go 1 by 1. So the first one we can do is create a static class on the Node.js side. A static class, I mean to say, let's say if I have logged in and I have fetched some data for the API and that API will not be changed, then we can just store that particular data into the memory itself on the Node.js side, but it's supposed to be minimal, not lots of data. The reason is it's always going to occupy memory. So the first solution will be. The other will be the database, something like Redis or Memcached, which will allow us to get some data on the back end side for the same request. So for let's say, take an example of React.js. Let's say when we open a product page or home page, okay, so for the home page, 90% of the users have the same home page, same dashboard. So we can catch those requests, those API requests into the Redis database. Then once the request will come from the front end, we can check if this request has already cached available on Redis or Memcached. If it's available, then we just provide that cache. And if it's not there, we can just call the database, and we can store that into the Redis, then send it to the real JS. But afterwards, if the same request will come, then we can just provide the same response to the user, and we can also use other technologies like TypeORM. So TypeORM also provides some caching mechanism where we need to allow caching on the database level side. So again, it will be managed on the memory level, but it's managed automatically by TypeORM. But, yeah, we have also some ways to manage that as well on the TypeORM library as well.

How would you handle state management in complex area application using multiple stores? How would you handle state management in a complex area application using multiple stores? Okay, when we're using a complex system for AI with JavaScript and multiple stores, we can use technologies like Redux or recoil. For Redux, we can create multiple stores, but we need to handle them carefully. If we're creating any store, it's not supposed to duplicate data to other stores. For example, we can create two stores: one for orders and one for products. If we create a product store, its reducers and actions will be allocated to that store. Similarly, the orders store will have its own reducers and actions. When we need to check if a product module is not getting data from the orders store, we can architect it in such a way that the product store gets data from its own store, not the orders store. This is a common approach for using multiple stores in JavaScript.

So we are querying the database. Returning the new promise. So let's start from user to user. Okay. So first of all, the query database itself is not inside any function, actually, which we are awaiting for it. So it will just execute. But after that, if after the query database, there are next statements that will be executed afterwards. And another thing is, there is no statement as a finally. Okay? So when we query the database, if the connection fetches, we'll go to the case that will be perfectly fine. But again, we need to close that particular connection as well with the database. So the advanced or more optimized way will be when we query the database, we will provide the query next step from user, the end users to go to console dot new user. But afterwards, we can also connect, finally. So finally, we'll always execute after, even after it will go to the error or provide the result. So in the finally, we can close the database connections.

Steps would you take to enhance the performance of the re application cloud hosted for AWS or GCP? There are, like, lots of ways to enhance the performance of a React JS application cloud hosted on AWS or GCP. So there are ways we can create a cloud, actually CloudFront for the React JS where we can distribute that. CloudFront will be, like, more fast than a static website. Something like, if we use EC2 or S3 as a hosting mechanism, we can use CloudWatch. Apart from that, we can also use a load balancer if the application requires a Node JS connection in certain scenarios, like for example, next year when we require the Node JS server. In that case, we can create a load balancer. The load balancer will automatically check the load of the application, and if it's required, it can create or initiate the next one.

When we are scaling a Node.js application on AWS and GCP and we want zero downtime, the best way I can find right now is using ECS clusters. ECS is elastic container services, which we can use on AWS, GCP, or Azure. All it requires is a Dockerfile. We need to create a Dockerfile from the Node.js application, which has common instructions, such as how to start and restart the server. To get zero downtime, we can deploy that into the ECS using target containers, and we can also use Kubernetes. Kubernetes allows us to create and check ports. On the ECS side, if we deploy that particular function, we can create as many tasks as we want. One service can have multiple tasks. We can create, for example, five different tasks for the AWS functions or the Node.js application. Once we deploy the new version, it will automatically check if there are any running Node.js tasks. It will wait for the request to be completed. Then, if it's completed, it will replace that particular task. This will get us zero downtime. We can also use Kubernetes to enforce zero downtime while deploying the Node.js application by using the cluster mechanism.

Suggest improvement for a React Native application's performance observed on low-end mobile devices. So, just improvement of our React Native application performance observed on low-end mobile devices. Okay. So, I don't know much about the React Native application, but on low-end mobile devices, we can have lots of things which React or are also available, React-side also available. So, the first thing is, we don't have to store or use the hot reload mechanism very much, actually. And the other thing is, we need to destroy components if we have used them and have moved to the next screen. We can also use performance monitoring to check which particular area or screen the performance is hitting, actually. And we can pinpoint that, and we can resolve that by checking with performance monitoring as well.

Next.js is a framework built on top of real JavaScript, first of all. When integrating Next.js into an existing React application, we can utilize two methods of providing data to the DOM. One of them is building the whole page under the SEO level, and the other is building it on the client level. If we want to implement SEO, we typically focus on the home page and a few product pages, which we can decide, and we can generate those pages on the Node.js side, also known as server-side rendering. We can build our entire page on the server side and just provide the content or the HTML document to the client side. This will improve performance and also allow us to achieve better SEO for the application. Apart from that, Next.js has its own tools available for handling images, caching images, and more. Next.js is also used to cache images, which will fill in the gaps and increase the performance of the application. We can also cache those pages, making certain pages, such as the home page, a bit faster to open. Once it's faster, it will be good for SEO as well.