Ravindra Kumar Meena

Hello. My name is Ravinakumar Amina. I graduated in 2019 from ISM, Dhanbad. It's an IT college, one of the prestigious colleges in India. I did my project in conversational AI from over there. Currently, I'm working at Nielsen as a senior software engineer. I hold an experience of close to 5 years as a full stack developer. And, talking about the technologies, I have worked on React Js, Node Js, TypeScript, and JavaScript. I also have an intermediate level of experience in DevOps. Talking about other frameworks, I have worked on Django, HTML, CSS, and I also have sound knowledge in AI as well. Apart from this, I have also done open source contributions via Google Summer of Code in RTMS organization. So that's a bit about me. And, talking about my hobbies and interests, I like to play cricket, and I also like to do hiking as well.

To enable the feature flag in a React application, we can design a configuration file in our React application. This configuration file will have features corresponding to their values, true or false. If a feature's value is true, that means the flag is enabled. If the value is 4, it means the flag is not enabled. We have to import this configuration file in the React component where the enabling of this component will be done, so we have to import this configuration file in their React hook. From there, the state of this component will be maintained. Once this is done, we can directly have a toggle button in the UI. Based on the feature flag, it will be turned on or off based on the requirement.

So, I have faced this risk condition when multiple user accesses are possible concurrently. In fact, I have experienced this situation in the past. So for this type of thing, we have to use the transaction. So that in a transaction, what happens is that only at the moment, concurrently, a few processes will be executed. Okay? But it will also be isolated as well. Okay? It will be isolated because we will be using the transaction mechanism as serializable. Using the serializable and the transaction, we can achieve this very easily. And this will avoid the risk condition. By avoiding the risk condition, only one block of the one row of the table will be accessed by one process because of the transaction. Another process that wants to execute on that row has to wait, it will be queued. And once the previous one gets successful or its completed data execution, the next process will get a chance to try to execute on that particular row. So via using transactions and locking mechanisms, we can achieve this very easily.

So, okay. Large monolithic Next.js application, this can be done very easily if you have a monolithic Next.js application, which is large. You have five endpoints, let's say, slash a slash b slash c, and so on. Ten routes. Okay? So, what we can do using micro front-end architecture is create different repositories. Okay? Based on that, slash a will be one micro front-end service. B will be another micro front-end service. And C will be another micro front-end service. So, that is how, like, based on the route slash a, if the request comes with the route slash a, then it will be directed to the slash a micro-service that is handling the slash a route. If the request comes through the slash b, then it will be handled by the slash b micro front-end service. So, that is how the large monolithic Next.js application can be divided into micro front-end architecture. And I have used this and currently, I'm also using this micro front-end architecture in my project. And what I've experienced is that it has also improved the performance of the application very drastically.

The strategy that I used to decide if I am supposed to create a new component or expand the existing one is as follows. So, let's say I'm trying to develop some feature and I try to import the component. If I see that this component can be extended, which will fulfill my requirement, then I will definitely extend that component. I will also make sure that the existing functionality that was handled by the component does not break. If I feel that the existing component will not at all be able to fulfill the requirement that I need, then I will create a new component. To make sure that everything goes well, we have the existing test cases and unit test cases. We need to run those test cases against the refactored component if we are building the existing one. We need to check if everything goes well, and then only we will be able to commit the new version of the updated component. So, that is how I would make sure that the updated component does not break the entire functionalities.

Yes, I have previously worked on serverless architecture. So serverless functions are generally used in serverless or microservices architecture. So using serverless functions, we have a function on AWS, which is called Lambda. They are called serverless functions. The key point behind serverless functions is that they are very easy to code and easy to maintain. This is all deployed on AWS. So that's how it's done. And let's say, in one of the applications I was working on, an ecommerce application where the user was supposed to download the file of past orders. Okay. So downloading a file is a very heavy process. Like, you need to compute orders in the last 2, 1 month, 2 months based on the requirement. So it was a little heavy. Based on that, the serverless function was used where it triggers that this is the user trying to get the order, the download history of the previous order. So this is how it was done. Using the serverless function, it automatically sends the file to the user as well.

So here, what I see here, we have directly checked out the master first before actually pulling the repository. Okay? So here, this is the one issue that I see here. 1st, we should pull the repository. Okay? Then only we should check out the master. Once we have done this, then we will ensure that we always have the latest code available in this CICD pipeline. So for this step, we would first clone the repository, check out the master, and try to pull again, just to make sure that we have the latest version of the code. So that is how we can improve this CICD pipeline.

Okay. So, there is one issue that I see here. So if the role is admin, then it will please print the welcome admin. If the role is moderator or the role is user, then it will print the welcome team member. Or else if it is not anything, then it will bring the welcome guest. And after that, once this is all done, after that, we have also set it as end. Yes. So end means that this is the stop of the execution. That is causing the script to end at one particular line. So this will prevent the print welcome message function from being called.

To implement a custom Lua model that efficiently handles concurrent data rights and reads, so what we can do here is utilize the basic fundamentals of the transaction. So, okay, in a transaction, a transaction follows the property of ACID. It is atomicity, consistency, isolation, and durability. So, with this, what happens at one particular time, one process is allowed to execute while other processes are queued. So, in this way, we are making sure that the process that is trying to update a row or data logs it by one process so that other processes do not execute on it. So, that is how we make sure that the data we are writing is not dirty, and the data that we are reading is not dirty. So, that is how we make sure by using the transaction mechanism that the rights and reads are good and not dirty.

Process SQL adhere to the asset properties. The asset properties mean here a means. Like, all steps should compute or none should complete. Consistency, like, we have the database consistent, and isolation, like, the database query should run in isolation. And durability means the client data change that we are trying to make is durable and actually gets reflected in the database as well. Okay. So using a transaction with this is very basic syntax for the transaction is, like, begin transaction. And after that, just try to write the code, whatever you want to do in the transaction. After that, we have to use the commit. So this is a commit. We are trying to do, we are committing the transaction. Okay? So that is how this Postgres SQL adheres to the asset properties, and this is generally seen in relational databases only. But there are few other non-relational databases like MongoDB that also adhere to the ACID properties. But relational databases definitely follow the ACID properties.

Okay, in the next, how do we prioritize the SEO performance in a Next.js application? Okay, so here, there are other frameworks similar to Next.js, like Gatsby.js, but if you want to do SEO, then Next.js would be the preferred option because it gets rendered on the server itself. So that's why it's very efficient and very powerful. Another advantage is that server-side rendering for SEO optimization is very effective, but there are trade-offs as well. If you want to do SEO and you're doing, let's say, a few pages that need to be rendered on the client side, then SEO might start breaking. In that case, it's possible to render only the necessary components on the server, while using client-side rendering for the rest. However, the trade-off is that if we have to render a component or page on the client side, it might be slow because server-side rendering is much faster than client-side rendering.