Syed Waheed

So, we can provide authentication and authorization by using a middleware. So using a middleware, we can check whether the request, whatever is coming from the client side, we can authenticate whether it's a proper user or not and based on that we can process the request. Even in case of an authorization, when we process, suppose in a login scenario, if a user is entering his credentials and when he tries to log in, so to authenticate whether the user is correct or not, it goes to the middleware and it will check whether it's a valid user. Based on his credentials and based on everything, it will create a token by using a payload and a security mechanism, such as a JWT token. Once it's created, it will get back from the response and whenever a user tries to access anything, he will access through the token. So by using a middleware, we can authorize whether it's a valid token or not and we can process his request. SALT is something that, when we create an encrypted token, it makes the encryption mechanism much stronger, so the decryption will not happen to it. Therefore, no one can decrypt it using this SALT.

What is course configuration? So initially, course means cost, origin, resource sharing. So whenever any it'll, you know, we try to access any resource which is running on any different resource, so we should get this course error. To handle these errors, we need to configure the course. We need to add a course by using the course module where we can add it to our project, use it on our server. So if we import a course module and use it as a middleware, then we can also provide access only for some particular white label resources by configuring that. We can provide the headers and grant the app access permission to the particular resources by passing a header. These are the few course configuration options to handle course errors.

Whatever usage often we will get, we should use. So, middleware is like a middleware. So whenever we get a request from the client and if it goes to the server, in between, we'll have a middleman. So whenever we can, suppose in a meeting, we have a meeting to check, whatever the request is coming. Is it a proper request? And does this request have a session? And the user who is the client user, like first, which is coming from the client, is he a valid user, is he an authorized user, or not? To check this situation, we can use a middleware. This is one use case we got. So what we can do when we write a logic in a middleware to find whether the request which is coming from the client is a valid request or not based on its headers, based on its security token. And apart from this, we can also write a middleware to handle errors. Suppose in case, we got any exception or any error, we can handle by using a try-catch. In case of dynamic error handling, we can create in every way. And whenever we throw up an exception or an error, instead of sending back a response directly from here, we process this to the next function, which we have along with our request object and response object. We process this request to the next function. So, what we do is, as this response will go back to the client, while going back, instead of sending directly a response from the cache, instead of that, we send this to our middleware and based on the error, we then send the status, what kind of error, you can send the proper, meaningful error along with the status code to the client, so that the client can understand what happened in this case, what happened at the service. These are the few use cases of middleware.

What are the log levels? Yeah. In the project, we used a Winston model, which can help generate loggers, and we can write these logs to files. So, there are three levels of log. One is to print all the errors. One is to print the information we need, and we can even add another level as a debug. And I think if there's another level called warnings, it's in place, but I'm listening. You can even use it to print warnings. So, what we can do is maintain separate log files for each log level. Like, for errors, we can have a different log file. For info, we can have a different log file. For debug, we can have a different log file. So, yeah, for warnings, we can have a different log file. If you then we can make a single log file where we can have all the errors, infos, warnings, debugs, everything. Yeah. I spoke and covered both log levels. So, these logs basically can print loggers, which we can use to print server-side logs. So, for client-side, we can have logs at the browser. Even there, we have console logs – console log, info, console log, time, and console time. Yeah. It's also one type of log. To find out the time of a log can help check the code execution.

Yeah. So mode is a single-threaded and it's a non-blocking. So as it is a non-blocking, it will handle conferencing. So, whenever we have multiple functions, let's say we have multiple APIs that need to be done, in this case, what we can do is create a promise for each API. By using promises, you can create a promise for each API. And using promise.all, we can process all these promises concurrently, all these processes. So we can get a single output from it once everything is done. And as well as we can even handle any operations confidently, you can even create a child process of a main process. So we can start a child process panel so that the whole process will run parallel to each other. Even in this way, we can handle options concurrently. These are a couple of ways, and we can use even callbacks as a way to handle conferencing.

We can run it infinitely. Can we run an infinite loop? If we run an infinite loop based on the situation, if we run an infinite loop accessing any memory, then an infinite loop will let us do that. The stack and memory will get filled up, and it may crash our server. And what we can do, suppose if there is no memory usage and in case of it's taking into account any event loop, which will run at the same time. And what happens is the event will check the event queue, and it will notify it will image the event which are going to commit which are going to complete in the event queue, and it will push to the call stack. So this is also one loop which is running infinitely without stopping and checking the event queue and then emitting the events to the call stack. What we use if and if it's in a method? I think based on the situation, if we are consuming a lot of memory, then an infinite loop will fail. If not, for an example, this event loop. For an example of this event loop, what we do, we can just check the event queue and monitor the event queue and it will image the event. So in this way, we don't use any memory, so it won't work.

When an error is thrown from a method and we don't handle that error, in such cases, it will crash our server. It will stop our server from processing. And the control goes to the controller. This control goes to the controller for an example, let's take you're processing any file, and the function is to process a file, 3-day file or write a file. But you don't handle any error, you're not handling anything in that situation. And the file is also not present, but you are trying to read that file. It will save, and the error will go to the main process, and from there, it will go to the function, and it will raise to the main process, and it will stop it.

Design patterns are something that we can use to create code, to write code in a proper way, so that we can avoid unexpected errors. So I have used the singleton design pattern, for example. This is much helpful. If you want to create a class that gives you a single instance every time you try to create a new instance, it will just return the same instance for you. With this, you don't have multiple duplicate instances of it. Another one I have used is the model pattern. What we can do is encapsulate a few things, like private things, inside a module and provide only those that are needed to access outside. We can also have a dependency injection design pattern where we can create a service in case of an algorithm. We have a dependency injection pattern where you can create a service based on the logic, based on the requirement, you can write a logic on it, which has components. If you need to run that logic or if you need that service, then you can inject it into the particular component. Even if it's needed, suppose that state can be created as a separate service, which is needed at a root level, then we can inject this at a root level. If not, if there is some particular service which is only needed for a particular function, then we can inject it to that particular function.

We use async and await to handle asynchronous programming. Async and await is used for asynchronous programming. So, let's take an example of fetching data from third party APIs. In that case, the actual behavior of the Node.js case is asynchronous. It won't wait until you get a fetch. You fetch a complete data from the gateway. As soon as it will go to that function and it will execute the function, it comes out of that and goes to another function. It won't wait there. So, we want to wait there. We want to wait until it gets the data. Then only we need to go forward. In this case, we use async and await. We are mentioning to the function to wait until it gets any complete data by using the await keyword, so that the execution will stop there and it won't process further. It will fetch complete data from the third party API. And once it gets the complete response, then it goes to the next process.

Deepak logging in production. So in production, we can usually print error logs. And if needed, we can use debug logs, but mostly we use error logs. But if anything went wrong at the production to find out, debug logs are beneficial, but I think it is used to find out the root cause of what happened. I think we can use it to find out the root cause of it.

So which all promises we can use for parallel request processing? Yeah. For parallel request processing, you can use a promise.all. So all the promises, we can pass it as a form of an array in an array so that all the promises will process in parallel to each other. And once you've all the promises processed, you will get the final result from the promise.all function. In case if any promise gets failed, then you won't be having the promise.all will be stopped, and it will print an error.

So to achieve a join in MongoDB, we can join by using the fields by checking the field condition so we can join the two collections by using the field. And in the case of a message where you can join by using conditions on the column, but in MongoDB, you can choose fields and make a condition, and there are only a few that can join two documents.

Can we recommend a secure authentication flow for a micro service setup? The Node.js application using AWS. So, for a microservices setup, if you want to set up an application, you can throw in an API gateway. We can add a middleware. So whenever the request comes to the API gateway, we can authenticate the request by using a JWT token, and then process the request to the particular microservice. This way, we can secure our application. We can secure our microservices and even add more things to secure against cyber attacks, like that's another option. This is done using a middleware. We can secure our routes by using the JWT token. So we can verify if the token is valid or not by using the secret keys. And then forward the request to a particular microservice based on the route.

To ensure a high code quality for a large-scale code base, actually, using JavaScript. So what we can do is implement unit test cases for our functions and our APIs. So by this, what happens is that we can avoid any errors in a production environment. This makes our code quality really strong, so we can have a 100% assurance that our code will not produce such low-level errors. We can assure that the API's functions and everything we have to do will pass all test cases, including positive and negative test cases, and all test-case scenarios. This will ensure that code quality is there, and we can even, if possible, try to split this large-scale application into a microservices architecture. So we can have different services for different features. Even this will be helpful, as the main application load will be distributed among these services.