Raman Thakur

Hi, I'm Raman Thakur and I am from Himachal. I have a total of 3.4 years of experience in NodeJS. In NodeJS, I have worked with ExpressJS and NestJS frameworks. I have also worked with TypeScript and in databases I have worked with Postgres, MySQL, and MongoDB. I have also worked with Microservices Architecture, primarily on KafkaJS, RabbitMQ, and Redis. As for my projects, I have worked on various projects such as netting applications, property-related applications. My last project was about a social media agency where someone can hire a creator or publish content they want to make, a YouTube short or YouTube video based on their product. They can hire any creator based on that, and if the creators bid for that particular project and he accepts, our platform will deduct a 2% charge of the total exchange between the buyer and the creators.

TYPEORM is more advanced than other ORMs such as SQLISE and are more used in the NestJS framework because it provides in-built support for TypeScript, so that our models and schemas are properly, statically typed. There is no such concept in SQLISE or anything else because SQLISE is good with common JavaScript, but when it comes to TypeScript, SQLISE does not provide as many leverages as are provided by the TYPEORM library. So, yes, it is mostly used in NestJS and it enforces us to properly define our tables and structures according to our database.

So, in ExpressJS in order to handle an error we have a number of ways, but out of them most common are try-catch mechanisms. Like, we can add try-catch in our particular file where we want to catch an exception or an error. In the catch block we can handle the error according to us, like if we want to define a custom error based on the exception we have encountered either from our codebase or our database, we can define it in the catch block. And other mechanisms are also there, such as the away2js package in ExpressJS, in which we do not need any try-catch, it just allows us to handle any error based on our input. For example, if we have a database query for find1, then we can define two variables, in one variable it will store any exception or error that will occur, and if it doesn't, then in the second variable it will give us the provided data that will be getting from the database. And third is a global exception or global error handling, we can define a global file where we will define every exception or we can add a switch case for every exception or error and based on that our controller services will, if any error comes in our service file or controller file, it will be directly handled through the global exception that we have defined or global error handling file.

The main consideration I would like to say is that we must ensure the page and page number parameters are coming from the front-end. We have two parameters that we have to pass to our MySQL database in order to implement the page initial functionality, namely page and limit, and offset. But from the front-end, we will be getting page and page number. So, if we have page, then we have to make sure that the page and page number parameters must be coming from the front-end. In case the front-end hasn't sent us those parameters, we have to define a default value for them, so that undefined values or any other nullify values do not resist our database and if that is the case, then it will produce an error to our application. Additionally, another consideration will be there that if we are implementing the page initial, we must return the metadata to the front-end, like overall records we are having in our database, so that they can properly maintain the page initial at their end, like they have to show the number of pages in the front-end at the cursor and all.

In ExpressJS, we don't get any inbuilt support for TypeScript, we have to manually add libraries to allow ExpressJS to handle TypeScript. So for API endpoints, we can define types for our functions, like we have to make sure what will be the response of a function. As we know, it will be returning a promise by default, but what kind of promise or what kind of data will be there after the promise is resolved must be returned from the controller so that on a router file we have proper context of the value that will be returning. And also the endpoints, generally we pass string to the endpoints or the base URL of any page. So we can declare a variable, and we can declare its type as string, and in that variable or a constant file, we will be defining all our routes. So in that way, we can handle the typecasting of our API endpoint and make sure that only the string value is passed to the endpoints and the promise is returned from the endpoint that has been attached to that API endpoint.

When I am working with TypeScript or NestJS, I would prefer TypeORM because it makes it easier to interact with TypeScript than other ORMs because of its inbuilt TypeScript support. And also it has a more flexible query builder than other ORMs like SQLite. In SQLite, we have a disadvantage because if we have a nested query and all, in some cases we have to use nested literals and all. But in TypeORM, it is like a mixture of our functions and raw queries. So we can easily define our nested queries, even sub-queries in TypeORM as compared to SQLite. So if I have an application in which I have a lot of number of joins or a lot of tables and that must be statically typed, I would prefer TypeORM in that case over any other ORMs.

So, one performance issue that I can identify from this code is that the event is not unique, for example, it will be universal. So, if I have a large number of users, the event or socket may hang up here because the event will be triggered n number of times depending on our user load, which will create a performance issue.

Rate limiting is a concept where we can limit the number of requests that our application can handle in a defined number of seconds. So in Node.js we have throttling, we can build a throttling mechanism using the npm packages or if we are working with the NestJS framework, we have a throttle decorator predefined where we can define a number of requests that our application can handle in a frame of seconds. For example, if I want my create user endpoint to only be triggered once in every 5 seconds, I can define there a number of hits it will take in 5 seconds. In Express.js we have to use a npm package for throttling that we have to define on our main file or a particular route where we want to use it, so that it can limit the number of hits on a particular endpoint.

I will make sure that I don't have any congruent database schemas to be migrated into the database. First, I will ensure all other schemas have been migrated to the database, and then I will handle this particular database schema individually. I will look for changes to reduce its complexity in the code. For instance, if I have a complex data structure, such as an array of objects in a field, I would like to break it into multiple tables or multiple database schemas so that the complexity can be reduced and the main functionality can be achieved using fragmented or distributed tables in that case.

The most effective way to manage state in real-time applications is to publish events only when necessary. I don't want my events to be subscribed to all the time on the front end or back end because we have other libraries like Pusher.js, which mainly uses web sockets and is more lightweight. So, I would only connect to a particular event when data is coming from that event. Like, I will only subscribe to that event at that particular moment, rather than subscribing to it all the time on the front end.

While dealing with multiple third-party APIs, I would manage my codebase in such a way that I have helper functions for every. For example, if I'm integrating Twilio or any third-party, I would make sure there is a separate function for its connection and a separate function for its message sending or receiving message. In that particular message, I will use try-catch blocks. In the try block, I will attempt the operation, and in the catch block, I will catch all exceptions. Because on Twilio or any other third-party, they have defined all their error codes or all their error messages that will be sent by them. If in case of any bad request or any other exception from our end, in the catch block, I will try to handle all of them. However, to handle them asynchronously, I will use async/await and I will define all the helper functions as async functions. I will use await in my main API or main service where I'm calling those functions. The main approach will be to use a distributed system, like different functions for connection and different functions for sending messages or any other functionality that I'm using. And in those, I will use async and await at the main function.