Gaurav K

Yeah, so in terms of my background, I have been mostly in the web development area. I've worked on web, full stack web development throughout my career. And .NET has been something of a constant for me with C sharp being the language. I've worked on that pretty much throughout my career. And in terms of the front end, I have experience in Angular and React, React being the most recent one, along with HTML, CSS, and JavaScript, of course, which is included as a part of this. And in terms of a database side, I also have some experience in SQL server, as well as MySQL. This is basically the tech stack that I've worked on. Given my current experience as a senior engineer in Microsoft, I am also involved in a good amount of leadership activities, which includes things like code reviews and mentoring the junior folks, as well as involved in design and architectural discussions as well. So I contribute there, there as well. And at the same time, I'm also quite excited about web development in general. And even though I have a full stack web development experience so far, I'm fairly comfortable with the front end, as well as the back end aspects. So I'm more than happy to work on front end, given the current requirements.

So, in a microservice ecosystem, in terms of how I can handle distributed transactions, of course, one thing is we need to follow the asset properties in database development, database setup. So, either we could have some sort of a master-slave in terms of data, you know, data source. Let's take an example of SQL Server. If I say I have a master and slave, all the writes happen to one single database, and that is going to further be distributed across different nodes as well. And reads can be handled through all of them simultaneously. That is one thought I have in a microservice system, how we can go about it. Another thought would be that every time there is a write, the region closest to, or rather the distributed system closest to the user can have the write operation. And it can further replicate that data across all the other databases in time. And one other option would be to have some sort of an event system, event queuing system, which would enable, you know, the way, if any write happens and the queue will be filled up and the queue will be processed in time, given that if there is no requirement of an instant access to the written items. So that's basically three approaches that I have in mind. And given the exact scenario, we can definitely decide on which of these three options to go for.

So when it comes to optimizing the React application component tree, one of the best ways we can approach it is to have some sort of a, you know, a single responsibility component. So a component could be specifically, you know, specified for one single operation or rather one single render of a section in the web page. Given that, so because of how React works behind the scenes in terms of how the virtual DOM is updated and how the real DOM is updated based on that, it takes the basically the difference in terms of what changes. So given the, you know, lowest node component of the React application, the lowest node change will trigger only the lowest, you know, the HTML and CSS associated with that component alone. It will not, you know, it will not update anything from the tree above that, any of the components above that, the parents, I mean. So it's better to have that segregation and component inside of a component approach that will definitely improve the performance of rendering in React. And at the same time, some of the features that we can use when it comes to caching, like useMemo or useCallback, that can be used to prevent re-rendering of something when the inputs for any of the function can be the same. We don't need to fetch any other data or we don't need to refresh anything in the rendering. So we can save some rendering performance as well there. And at the same time, we can use useRef, one of the hooks available to access the elements directly. So in this case, we can use this to change values according to our business requirements without really re-rendering anything on the screen. And so using useRef is also one of the ways that can be, you know, applied for improving the rendering performance.

So in terms of NoSQL databases, one of the best things it can do in terms of scalability is that you can have a distributed system in a sharded manner where all the data need not reside in one of the node of the DB. That way, we have the power of those multiple nodes instead of one single node in case of RDBMS systems. So distributed systems can work very well in such a situation because of the sharding. And at the same time, we can also have a NoSchema defined in a NoSQL database, which also gives flexibility in terms of data handling. And of course, when it comes to speed, we also have the distributed systems where any query to the NoSQL DB, which is distributed in the method of sharding, we can access all the nodes at the same time, get all the data, whatever it needs to be done. And at the same, this can be achieved in a much faster way, considering that there are multiple nodes that can be processed or queried to parallelly. And given these two factors, I think NoSQL databases work very well in highly scalable systems where we require a highly scalable system. And this will also help in terms of handling better writes as well in terms of following the asset properties. So that way, not all the nodes are being, you know, you can say that not all the nodes are being used simultaneously for writes. And that helps as well.

Um, I haven't really worked on a Node. Js application in on the back end, uh, so I can't really provide an answer to this. So I'll skip this one.

In micro front ends, managing user sessions can be done by either having a global storage that can be used across, uh, or or maybe we could even use, uh, uh, the local storage or assistance storage. That way, um, considering that all the micro front ends will still use, uh, a similar or rather the same, uh, URL, uh, the host URL, considering that we can use local storage or session storage to store whatever information that we need to, uh, in the user session. And at the same time, of course, considering, uh, we would use rest APIs, all the user sessions can be, uh, internally managed on the server side no matter where which of the micro frontend application that the request is coming from, uh, given that we have a common storage. Uh, this is how I would design, uh

So, I'm just going through the code to understand what it's supposed to do. Given that fetch data is a method that fetches data from an API, which will have some latency associated with it, and given that we are setting the state using set data for the response coming from the promise and fetch data. So it's possible that the API, because we are using use effect here, there could be a possibility that there are multiple API calls that can be associated with one. Or rather, I do observe that the dependency array does not have anything in there. So in this case, mostly the data will be updated once on load, but it will never be called again because it doesn't really have a dependency array filled up. So in this case, any update needed will not go through the fetch data method and we won't really have an update at the state. And at the same time, even if the dependency array is filled up and there is fetching of the data happening multiple times based on the change on the screen, here each API can take different times. Maybe the first call can take five seconds, but the second call could take only two seconds. So the second call will have the response first and the first call will have the response next. So given that, the set data will be done only after the API call is finished. So given that, we will definitely not have a consistent display of the response data on the screen. So that is another possible issue on this code.

Just going through the CSS code, we have a class container, and the closing arrow brackets defines that the box should contain dot box, which is the element with the class box should contain inside of the container. One of the reasons this might not work as expected is that either the element of the box class does not have height or width, or it's possible that the box class item is present not immediately inside of the container, but it could have been nested inside. That's also a possibility that the background color might not be applied. And other problems possibly would be, we need a box to be a block element, ideally. I think I'll cancel that statement, or even an inline element would work in this case. Thinking of other possibilities why box element might not be styled, I think that should cover it. Either it's in nested form, it's not the immediate child of container, or it's possible that it doesn't have a height or a width, or it may not be displayed on the screen given the situation of what box element is about.

So, given a microservice system, one of the ways to ensure fault tolerance is to have some sort of a retry mechanism. The retry mechanism can be used in case an API fails and we want to retry that a couple of times. So, maybe a maximum of three or four times can be the API call can be retried to ensure that the API is successful. If it is not successful, even in that case, it's very possible that some of the systems might be down. And given that, if we are pointing to the same node, which is down, all the four retries would obviously fail. But one of the logic that can be used is we can have this API call done to a different node on every single retry, which can definitely be handled by a load balancer of sorts, which decides which node the request should go to. That way, even if one of them fails on the next try, or even the third try for that matter, it is sure to work because not all the nodes in the given system can fail at the same time. That possibility is very low. So this would be one of the ways I would go about it. I am thinking about another approach. One of the other ways we can use is, especially in write scenarios, we could use some sort of a queuing mechanism to have that in a queue instead of having that done live. So that way, whatever writes need to happen can happen asynchronously behind the scenes. And even if there's a failure, the retry mechanism can be used again in this case. This is another approach that I am thinking about.

So, given that JavaScript, especially on the later versions, have a lot of new features added in, a lot of support from the web browsers as well, given that it is better to use native web components in terms of, let's say, for example, let's say we have an email field that the user needs to fill up, there are some basic or rather built-in error checks happening on an email for HTML5 component, for HTML5 input box. That's just one example that we can use the native web components, but at the same time, given that it will be, if we do not use any of the external libraries, there is a lot of savings that we can do in terms of the learning curve. At the same time, we also have the benefit of being able to control our code, and one of the main benefits would be that it can help us customize the way we want it, which is one of the primary factors of any web development team where they would like to control how things look on the web page. Given these factors, I think, yes, we can definitely use the native web components to build a JavaScript application.

So given my experience, I have utilized the Jest test framework. Using Jest, we can definitely capture a good amount of scenarios on the UI. So we have the options to, you know, test a snapshot testing, which basically renders a component and checks with the snapshot if the snapshot is valid or not. And Jest also provides features where we can focus on the user interface in terms of how the screen changes based on user clicks or entering of an information from the user. So all of these features, the clicks and entering data, all of these are available as a part of Jest framework. So this is the ones I could use in terms of having a unit testing in terms of component level testing. And at the same time, Selenium would be a good approach in terms of testing, functional testing on the whole web page as such. So this will definitely help with the integration testing aspects of it. And coming back to Jest for unit testing, we do have a good amount of mocking features available. Using the mocking features available, we can basically test individual components without really depending on any of the other components that might be used within a web page. So given this, I would say Jest and Selenium is a good approach to go about with the unit testing and integration testing respectively.