Shiva kumar

Myself, Michelle Kumar. I have 24 years of experience. I graduated in 2019, and then I started working with Edureka. So, during my stay at Edureka, I worked mostly with PHP and JavaScript. Coming to PHP, it's mostly CakePHP framework and sometimes in bulk and Laravel PHP as well. And coming to JavaScript, it is vanilla JS and then Node JS. So I worked on projects like maintaining their e-commerce portal and building a few APIs for the recommender's smooth functioning. And then some backend functionalities for the records admin panel. I also worked on the computer location system and the invoicing system. So, the major works I have done is optimizing their landing pages so that they get a better score in their core web portal steps. And that improves their Google search page results. I was with them for 3 years and 9 months. After that, I worked with another company for 3 months. During my stream, I can work with Deeppage and MySQL. During my entire career, the databases I mostly work with are MySQL. I have 4 years of experience with PHP and JavaScript, 2 years with Node.js, and 3 plus years in MySQL. So, yes, this is about my past experience.

So, to implement rate limiting in a Node.js Express application, the first thing to implement is to identify from where this traffic is coming from. Let's say, if your user is logged in, you can identify him with this user ID. Or, like, if a client is logged in with his client ID, you can identify from which client this traffic is coming from, and then you can implement rate limiting based on the client ID. Like, only for some particular amount of time, this client could hit this API only this many times. And next, if this is not a logged-in client, we could use its IP address, like the IP of the machine, to implement rate limiting for him. And coming to the technical implementations of it, there are libraries which could take care of it, like NPM packages. So, you could install that NPM package, and then, based on this IP address, it is going to take care of the rate limit for each endpoint, which you are going to implement as in a middleware because Express JS or Core JS have this middleware. Right? So, you can implement it by using the NPM package or, like, you can write your custom code, which does these things, like the client ID and how many times he hit a particular endpoint or, like, checking the client's IP of the machine and how many times a particular endpoint it did. So, technically, you can implement it in the middleware of your application. And to store how many times a request is made to a particular endpoint by client or, like, by a particular IP address, you need to store this data somewhere. You could either store it in your DB or you could store this data in-memory databases like Redis, where you create an entry for each IP or each client for a particular endpoint, how many times you hit that particular endpoint. And using that data, you can manage the rate limit. And, yes, apart from this, there is one more thing as well. Instead of handling it on the application end, if you are using some cloud providers like AWS. So, yeah. For AWS, you can implement rate limiting using the WAF. Like, they provide a WAF functionally, and using that, you could do the rate limiting for your endpoints.

What mode just to be confused about? I'm not sure what you mean by that. Event loop name and compute heavy application. So, basically, 1st, vendors and event loop get blocked when there is a synchronous operation that could run for a large number of times because only synchronous operations run on the event loop and those operations get pushed to the callback queue. So if there is an operation which could be synchronously calculated, like, let's say, in incrementing a variable and an infinite while loop, If you write some while loop code which could keep on incrementing the variable, this is a synchronous code. This will continue indefinitely since it only has a while loop. So in order to reduce the load on computer applications, the first thing we could consider is creating workers because a worker will run on a different thread and then pass on the results to the main thread. And the second thing is we can use clustering, where you fork an existing process to create a child process, and this child process can share the row. Either you can send your requests to these child processes or you could send the request to this child process, and then get the result from it. Or else you can span new threads. I think there are libraries which support this as well. Since Node.js is single-threaded, there is support to span a new thread. Basically, workers are the same thing - span a new thread and make this heavy computation pass on this heavy computation to that new thread. And once the entire computation is done, get those results back to the main thread so that Node.js will appear as if it's not getting blocked. So, basically, spanning new workers, new threads, and then using clustering to have the child processes in place. These things will help in preventing the blocking of Node.js.

This one will be the rest of the next page update. So, using Express to build an API for the CRUD operations to post the first thing, we need to connect to the post with this database. There are NVM packages to do so. Like, you would use packages like SQL, I believe, to connect with the database. And the next thing is, like, creating the endpoints or the routes. Using Express, you could create a route for each CRUD operation, like create can be one operation. I mean, read can be one operation. Delete can be one operation. Update can be one operation. And yeah. So it will be noted. For update, you can use the post request. For insert again, you could use the post request to output through the data. You can use the get request. So, you know, you create endpoints using Express, and then you connect to the PostgreSQL database using some SQL-based packages like when the SQL.

Database schema migrations in Node.js. I think you can use the sqlite3 library, the sqlite3 ORM, whichever is present. And the sqlite3 ORM can be used for migrating the database schemas. You create a schema, and then you run the code so that this, I mean, whatever database schema you have, that could be migrated to the new database. So, using Sequelize as an ORM with more JavaScript, you can migrate the database schema.

To do any file related operations in ModJIS, we will be using the FS module. The FS module is responsible for reading, creating, or uploading files. So, we could use the first module to do this stuff.

Yes. Assuming this code is used to identify the presence of an API key for an Express middleware, the issue I could find is that the API key is hard-coded because you are reading it from an enrollment file. So when you are reading it from an enrollment file, the API key is hard-coded. So if the API key is hardcoded, the same key needs to be shared by all the clients or all the users who hit this particular endpoint. So if all users are using the same key for your endpoint, then there is a chance that this key might get leaked. And if someone gets a hold of this key, they will be able to access this endpoint forever because this key is not being generated using some logic since it is hard-coded. So that was the issue. Basically, the API key is hardcoded and it is shared by all the users of this endpoint. And if someone gets hold of this key, they could use this endpoint with no issues until you change it in the environment file. And again, to change something in the environment file, either you need to make the changes, deploy your application, or you need to log in to the server and make these changes to the environment file. So this is not a good practice. You should be generating your API keys and then invalidating them in a timely interval so that your API stays safe.

So, basically, you are trying to access, whenever the user is hitting this particular endpoint. You are trying to read something from the DB, get user from DB. So the first issue is, there is no exception handling in here. Let's say if this get user from DB function throws an error. I mean, if it throws an error, since there is no exception handling, this is going to break your Node.js application. Your server and the app legend, which is a WebSocket, are coupled. So your application will break. If there is an error not being handled, it will bring down the entire application for every single request. And if someone is trying to push this since the application was broke, they are going to get an error, and this application is not going to be accessible to them. The first thing is there is no exception handling in place. And if there is suppose the user data is not found, you are throwing a new error. Throwing an error is like throwing an exception, and this was not being handled anywhere. So instead of throwing the new error, user not found, it's better to send a response in here. You could send a response within a status code like 404. It's status code 404 and message, like user not found. So now what happens is, if there is no user data, instead of throwing an error and breaking your entire application, you just send a 404 response to the user saying that user is not found. So yes. There needs to be exception handling in place, first thing. And the second thing is, instead of throwing an error at the route level, because if you are throwing an error at the route level, somewhere it needs to be caught. If there is a response middleware or something, we could use that. But since nothing is in here, it will break the application. So instead of throwing an error if the user data is not found, you could send a response to the user with status code as 404. I'll restrict the 400 status code response you could send with the message you are in your phone. That would avoid breaking of this application.

So, if you're asking about implementing a caching layer, and you're asking about caching the results of queries from a Postgres database. Let's say there is an employee table in the Postgres database, and it retrieves data from that table. If you're asking about caching the data retrieved from the database or the results of some queries. If you want to cache the resultant data from a query, you could use Redis, and you could integrate the Redis cache with your Express application. There are NPM packages for Redis integration. So you could use those packages and integrate your Redis with your Express application, which could cache the results of the queries that are run on your host database. And these queries, whichever you are caching, they should not change often. Like, there should be at least a 1- to 2-minute interval. And there must be, let's say, if this data is not going to be changed often and it is going to be requested often. In that case, caching such data will be beneficial to reduce the load on your database servers. And if you are asking about caching the response of a request. Let's say, if it is requesting some HTML page, if you want to cache these responses instead of calculating the results every time. So, you could use edge caching, like something at the enterprise level. You could use CloudFront. And if you are thinking about using something at the server level, we could use something like Varnish cache, or we could implement something like storing the response, whichever the HTML file is, generated on somewhere in the server, and then the name of the file which are some hash you create, and that hash and that particular request you've got, you could store this data in a post request database, and then, when a request comes, if there is a similar request, you already get the location of the file, and then, so the same file instruction, regenerating the file again and again, that you could do for web pages kind of request. But if it is mostly about caching the results of inquiries, you can have a ready sync place to store the results of queries to catch the results of