Alak Modak

Hi, I'm Alek, 25 years old from North Central India. I have around 3 years of experience in master development. Apart from my technologies, I'm also proficient with its relevant tech stack, such as React Native for mobile application development, Next.js for service and rendering, Nest.js for creating scalable API endpoints, and Postgres as a relational DB. Apart from that, I have experience with cloud-based infrastructure, with Google Cloud Platform, and also some expertise with AWS, including S3, EC2, and Cognito. Currently, I'm leading the development of SpringHill at Straging Market Private Limited, where I'm using Next.js for the frontend, and for servers at the frontend, and Nest.js for creating scalable API endpoints. To manage the data, I use Postgres as a relational DB. The front end, backend, and database are hosted on GCP App Engine and Cloud SQL respectively.

Yeah. The main show, there is, you are just iterating, like, till the length of this array. Since we know the in error end is thing is a 0 base, so it starts from 0, till the length minus 1, but you are including that length 2, which is basically undefined. So you will have some error at that particular instance. Whenever I equals error dot length, you'll have nothing for error of error dot length.

With including type 1 in my backend application on top of Node.js, we can have some atomic operations in MongoDB with these. We can achieve that with this type of volume. And also, we can achieve that with a bit of query as per our requirement. We can deal with such scenarios.

In the front end side, we definitely go with lazy loading, and also the observer pattern. Whenever the component or the stuff is needed, we need to render that particular component, and let's say implement some scrollable functionality. Whenever we hit the very end, only then we would call some more data and append to the previous data, and we'll do that again and again. So we need to send data in terms of pages whenever the user hits the bottom of that container, which is a portable component, basically. We would send some particular section of data to the back end to the front end, and we'll show it accordingly, as we would append the new data with the existing one. This basically helps with performance while working with a large or significant data volume.

We need to follow the lifecycle hooks there, like a component will mount, component data update, and component will unmount. So, we need to cancel out all the stuff that have been used or that have been created in the component data update stuff. We need to unmount or resolve all the functionalities whenever our component is unmounting so that there would be no chaos. We can basically achieve that with useEffect, like after implementing our record functionality in the callback function of useEffect. We can dissolve or unmount all the stuff we made whenever the component unmounts. We can achieve that by using some cleanup with a callback function. And within the callback function, we can dissolve or unmount all the stuff or let's say any external API call or set timeout, set interval. We can clear that and remove the garbage there whenever the component is unmounted.

To manage or efficiently execute the complex queries in Node, it's write and read. We can go with some indexing to read data or execute a query as first as we like with good indexing if we can optimize the performance of fetching the data. But while writing on that query, we definitely need to find that particular ID and then update that – it's a port request, so an auto-patch request. We definitely need to do it on the convention, as in, whenever we are updating something, we should update those particular columns or those particular keys in the memory object that are getting updated rather than updating the whole dictionary, which basically takes some time. That's why.

It confirms date management approach. Can you explain the credential issues? Never the less, how it can be improved concerning best practices. Well, we should not call any function independently before returning our component in a React component before returning the HTML tags in a particular component. So whenever the component gets rendered, like, it basically gets rendered whenever any state changes, so it would automatically call that particular function again and again. So it would generally cause some performance issue. So we should definitely call those particular functions or update in state on with some event trigger. Also, if we want to update in the state or put some default value whenever component renders. We can pull that within the useEffect to manage this stuff, but we should not put any function independently there in the component.

V-dash dashboard that needs to display a large dataset. Then show smooth rendering and efficient performance in data. So, we need to fetch our data in chunks rather than fetching the 10,000 rows at once. Fetching data in chunks is 22 times faster as it would fetch around 25 or 50 rows at a time, and we'll put a limit there. We'll put pagination on the page, such as page 1 would consist of 50 rows only. And whenever the user scrolls down to, say, the 45th row, we would call the next page data, which is 200, and so on. We need to divide our whole data into multiple chunks, and we need to assign it with some page numbers so we can manage the 10,000 rows smoothly with an array application. Rather than calling all the data at once, it would stop our application at that particular instance. Also, if we are getting 10,000 rows at once from the API endpoint, it would take lots of time. The execution time will get increased a lot, which definitely causes a performance issue. So, definitely divide it into multiple chunks and get it one at a time, such as infinite scrolling.