Saurabh Agrawal

Hello. My name is Saurabh Agrawal, and I have 18 years of industry experience, out of which various are in software development. During this 12 years, I worked as a full-stack Java developer. But then, on the back-end side, I'm into Java and the Spring framework. On the front-end side, I have worked with React, JavaScript, and a bit of Vue.js. So, during this tenure, I played various roles, like an individual contributor and a technical lead.

To approach optimizing React application components for maximum rendering performance, we have multiple ways. One is to use a hook called useCallback. The second is to memorize the component using the use memo hook. And even we can memoize the return value of highly computational functions using the memo function. So, useCallback. What it does is that between renderings, it keeps the function definition in the cache. That's why, if the dependency list, or any of the variables in the dependency list, does not change, React will return the cached copy of the function definition. That way, it won't recreate the definition of the function. If it is defined under useCallback. Now, use memo. Use memo can be used to memorize the return value of computational functions. So, if you are doing a very heavy operation or computation in any of your functions, then that can be memoized using the use memo hook. The third way is to use memo. Memo means we can create pure components in a functional way. So, using memo, we can prevent unnecessary rerendering of child components. So, what happens in React is that when a parent component is rendered, a complete tree of components is tried to be rendered. So, if we optimize the child components and avoid unnecessary rerenderings, then we can optimize the application componentry for rendering performance.

Yes, we can effectively implement the continuous deployment process using Azure DevOps for a JavaScript-based application. For this, we can implement a CICD pipeline using any of the languages like Ansible or Terraform. And, we can build as soon as the developer pushes any new code to the git branch on the repository. So, it's going to trigger a CI pipeline, which is going to build the repository code. So, while building, it will execute all the inner test cases as well. And if 100% of unit test cases are passed, then the build will succeed. Ultimately, it will check for any passwords or security threats in the code using Fortify. And then, it will release a new package. Then that package can be deployed further using any of the live HTTP servers. Yeah. So, that way we can implement the continuous deployment process for any JavaScript-based application.

So one tackles the problem of database connection pulling in a Node JS application to improve performance and stability by following a rule of thumb. Once you've used a connection from your connection pool and are finished with your transaction, you should close that connection so it can be returned to the pool or at least commit your transaction. If you don't do this or don't gracefully close your resources, it may lead to connection link issues. If you take care of this connection link issue, close all open resources created during the database operation, and your connection or database transaction will be cleaned. The connection can be returned to the pool, improving the performance and stability of the application. There won't be any data connection leak. Otherwise, the memory usage of the Node application will increase if connection objects get piled up in memory, and the application may crash. That's all for me.

In microservices ecosystem, how do you handle the distributed transaction across the services to ensure the consistency? Okay, so there are various ways to handle this. I mean, one way is to have multiple databases which are replicated. I mean, one database would be the master and another would be the slave. And, the slave will have the exact replica of the master database. Whereas, the master database can only be used for write operations or write transactions, whereas the secondary database can only be used for reading. So that way, you know, you won't have all or a complete load of different user operations on a single database, so we can segregate them using dedicated write and read databases. That's

We can use sticky sessions on the load balancer to effectively manage user sessions across micro contents. The load balancer generates a unique session ID or token on the load balancer side. This single session ID or sticky session ID is then used to verify or achieve sessions across the distribution system. For different micro front-end applications, even though they are in different modules, they can use a simple or single session ID to achieve user session across the distributed platform effectively.

The data might not be displaying as expected on the web page because the fetch data method is asynchronous and only invoked once when the application mounts. This is due to the way the useEffect hook is used, without any dependencies, it will only run once, when the component mounts. If any updates happen to the data on the API side, it won't be reflected on the UI on the web page. To have the desired effect, the useEffect hook should be used with a dependency array, so that every time the value or dependency list changes, the effect will be called, new data will be fetched from the API, and it will be rendered on the web page. Additionally, the component should return JSX with code that iterates on the data list and displays it as a list on the web page. Without this implementation, the component will not render the data.

Review the JavaScript code block that is intended to implement the singleton pattern. Explain what is wrong with the implementation. How would it fix that? So let instance equal to null class Singleton constructor if instant if not instance, then instance equal to this return instance const singleton and new singleton I think, for the instance variable, late keyword is being used, which is a block scope, keyword. So we want to truly implement this singleton in this case, then we have to replace let with back so that it will be hoisted. And, that way we can have a single instance and, initially, it will be null but once the constructor is called and first time we won't find it Then it will assign, this, object to the instance and variable, and it will return. The 2nd time, it will find the instance to be valid reference with some object, and it will simply return it. It won't create or assign a new object again. So, basically, here, we need to replace let with the var.

Which architectural pattern would you use to build a scalable real-time bidding system, and how would you ensure its responsiveness under heavy load? K. Support bidding system. What I think is that, the user should see real-time data on its web page as well as whatever bid he is placing should also go in real time to the server. So one thought coming to mind is that we can use WebSockets, which is a full-duplex way of communicating between server and client. That way we can have a full-duplex connection, and there won't be any pulling for real-time data from the server. So through a WebSocket, the real-time data will be updated on the web page as well as whatever bid the user will place will also go to the server using a single WebSocket connection. So that way, we can achieve the real-time bidding system without any polling in place. That's all.

And strategies we recommend for React applications with a focus on user interface, consistency, and integration. Okay. So first one is user interface consistency. Consistency means there are multiple browsers in the market available. So the UI should be consistent across browsers. So it should be compatible with all browsers. For that, we can use physical different browsers to test on, or we can use a cloud platform like BrowserStack, wherein we can use our desktop application on multiple devices and multiple browsers. And that way we can ensure the consistency of the interface. What is the testing framework and strategy would you recommend? Okay. And I would recommend that whenever there has to be a CI/CD integration in place to run the automation suite for our UI, so that we can ensure that if any change happens to the code, there is zero regression happening on the existing functionality of the application. Third, in the developer's perspective, we should have 100% coverage for our unit test cases. So for React applications, we can use the testing library. React testing library is kind of a paradigm shift as compared to enzyme. So what the React Testing library does is that it actually renders the component and it tries to perform assertions on the rendered component DOM. Okay? So that way we can ensure that the user interface is consistent and well integrated. Yeah. That's all from me.

Can you imagine where technologies like WebAssembly could be integrated into an existing JavaScript application architecture to improve performance? Okay. So, as per my knowledge, WebAssembly's primary purpose was to run native code on the browser platform. So, basically C++-based code can be executed or hosted directly on a browser. Code written in C or C++ or a native language is highly efficient in nature. So, using WebAssembly, we can execute the same code in our browser. The UI rendered on the browser would be more efficient compared to Java or JavaScript-written applications. I think that's the information I know about WebAssembly. I need to check how it can be integrated into the existing JavaScript application. However, I know the concept that WebAssembly's use is and how it can benefit the user interface. That's all from me. Thank you.