Dipta Biswas

So, yeah, my name is Ipto Visas. I am from a small village in West Bengal, India. I started my career in 2020 as a full stack developer intern, and then moved to a full-time role in the same company. I got to learn more about ReactJS, MongoDB, and Node in depth. I started building more applications with front-end, developing front-end applications using React and JavaScript, as well as learning the CSS part. After that, I built multiple projects on my own. As I continued building and developing applications as a full stack developer, my interest shifted more to the front-end. So, I call myself a front-end first developer, because I love working with the UI and seeing what's going on there. I also love front-end animations. In addition to front-end work, I've worked with the back-end using Node.js and MongoDB. I've experienced NoSQL databases, including DynamoDB and AWS databases. In my last company, I worked with serverless architecture, which involves Lambda functions and AWS frameworks, and so on. Recently, I completed a Google Drive clone application that simulates all of the major functionalities that Google Drive provides. This project was built by myself, and it's all about me.

React app performance has degraded significantly due to data volume. So, let's take a look at reactive tools. First of all, I'll check the front-end part to see what needs to be modified to improve performance. From the front-end part, I'll check React rendering to see how components are rendered, and how each component gets rendered. I'll also use the React profiler to check the rendering and other than that, I'll check the integration part to see if there are any lists being rendered without pagination or caching. I'll implement those to improve UI performance. If there's a large list, I'll introduce React virtualization to improve performance. Additionally, in the front-end, I'll keep monitoring web titles to maintain them according to Google standards. On the back-end part, I'll check and monitor API routing using dev tools like Grafana or other DevOps tools that can help me monitor API performance. On the API end, I'll introduce caching with Redis, and in MongoDB, I'll check how much connection it's making and how I can implement MongoDB pipelines to improve performance.

Roh, how do you ensure the smooth rendering options for large data sets? So, I'll first introduce browser pagination. If it needs to be rendered from the browser, I'll load the data from the backend and then divide it into chunks, like 10 or 20 data per attempt, and implement infinite scrolling. Moreover, to extend this approach, I'll add one performance improvement tool, React Virtualization, which will improve the rendering part and listing of that data set more performantly.

Look at the scenario as an atomic operation. I'm going to be critical within a no-depletion environment. How do you achieve it? So, for atomic operation, I'm getting that MongoDB provides the transactions that MongoDB handles to ensure that whenever the data is being passed to multiple collections, suppose there is a relationship with multiple collections and the data needs to be stored in multiple collections while maintaining multiple connections or there is a dependency between the collections depending on the data that comes from the front end that needs to be stored synchronously. So on that, the data cannot be modified between the collections because if that data gets modified, then the consistency of the data would be broken, right? So to maintain the consistency of the data, MongoDB introduced transactions and it gives us a session that can help to maintain the consistency. To break sometimes it is a bit difficult to maintain the consistency because of concurrency, multiple requests have been made to the backend and MongoDB tries to save all the data and retrieve at the same time. So at that point, MongoDB cannot retrieve the updated data. So we need to prioritize the read preference of the data that can be used with the MongoDB transaction function.

Examine this JavaScript function that is intended to return a new array with each element squared. Can you identify any logical issue in the program? So here the i goes to from 0 to array.length equals to array.length. It should not be equals to, so the condition would be i less than array.end because if it is equals to then the element would not be there because i starts from 0 not 1. If we go to up to length then it will be undefined on that case, the array of index will be undefined. In that case the square will be in n.

And then what method would you say is essential for unmounting the components that involve an API request? So we have the AbortController in the JavaScript API. So where we can pass the signal when a request gets made by the browser, and that signal we can pass to the abort controller when we're about to unmount. So that the abort controller can cancel the request at the same time.

To efficiently execute complex queries in MongoDB, we can maintain indexes in the database for read operations. However, for MongoDB, if we use it like a relational database with multiple lookups, it won't be efficient in the long term, especially for complex data. MongoDB suggests using replicas, or creating a duplicate set of data, if the data requires relations to another table. This allows for efficient read and write operations for complex queries. But we also need to maintain data integrity and prevent data duplication.

Given this rear component state management approach, can you explain what potential issues may arise? How could it be improved considering best practices? So, here I don't see any return, but I don't know if there is, this is the issue. Another one I would like to mention is to use the increment count, right, and to use this as a state and increment count to avail this dot set state. We need to bind the set state, bind this increment count method inside the constructor so that it's available to that method, that's the thing. But again, I am not sure about the return, why it is not present there. It would be better to have a look at the return, yeah.

To refactor a large React component that is difficult to maintain due to complex state and has side effects, we can split some of the components, divide a particular component into multiple components and maintain it as a separate component. So, suppose if there is a component that has multiple sections like a list, a search box, and a pagination, we can create separate components for each of these sections. We can maintain the state of each section in its respective component. Other than that, if the state of a component is not affected by the outside world, we can isolate that component's state using context and a reducer. The reducer will help us segregate between states. So, for a component that has multiple states, we can split the component into multiple sections and in separate files, and call those components in the parent component like one component that we are modifying. If the states are related, we can isolate the states that are not required for the outer layer, but if the states are required for the outer layer, we can use context hooks. We can create context and provide the state throughout the component layer, so that every other child of that particular component can have those listed states. This is the state logic and the side effects also we can maintain by different components, creating different components and we should avoid the prop drilling approach as well. That is the go-to approach to optimize the large component. So, first of all, we would be splitting the component, splitting the states and maintaining one singular state that can be overall managed by all of these components.

If you have a memory leak in your Node application, I would go about diagnosing and solving it by using the performance tab in Chrome DevTool to get the memory leak. So there is a graph in the performance tab which identifies which can increase if there is a memory leak, the heap storage also and other than that the CPU also. So I would look into that CPU and heap storage stats and based on the stats I will try to find which function of that, which is the function that caused the memory leak. So by using this I can, it is a bit time-consuming but yeah, I can, it is more helpful when we have the memory leak and we don't have any idea which functions are causing this memory leak.