Rakesh Kumar

Myself, Rakesh, I have around 15 years of experience. I'm a full stack developer. I mostly work on one stack. I use React as a frontend technology and Node as a backend technology. I have worked with both service-based companies as well as broad-based companies. Out of the 10 years, I have worked as an engineering manager in multiple companies. For around eight years, I have been an engineering manager at OLX, FreeCharge, and Domino's. I have experience in managing teams, hiring, cross-functional collaboration, like with product design, UX, marketing, and stakeholder management. I have experience in designing the frontend, backend architecture, and automation. I have exposure to SQL and NoSQL databases like MySQL, Postgres, and MongoDB. I have worked with most cloud technologies like AWS, Azure, GCP, and even with OCI. I have done multiple projects with multiple companies from scratch, and I have contributed to growth in most of the companies. For example, in OLX, I was responsible for growing the user base and also the number of posts on the platform. I created a lot of initiatives. For example, I reduced the posting funnel steps from 15 to 20 steps to 4 or 5 steps and did a lot of automation in that flow, which resulted in growth of around 15% on the platform. That's all about me.

Asset principles are usually associated with the RDBMS. As per my understanding, IndexedDB is a browser API, and it supports NoSQL. I'm not sure if asset properties are even applicable to IndexedDB. Even if there are, of course, there can be methods to mimic that. And I can also think about mimicking those behaviors of asset properties. But I'm not really sure that this is the right approach because IndexedDB is supposed to be a NoSQL database. And creating asset properties on the browser side is something wrong with the architecture because it's supposed to be for smaller use cases like supporting offline use cases. If you're making RDBMS when you say asset, I'm not sure if that's a good idea for having such a storage or database behavior on the front-end side, that too on the browser.

Access is cross-site scripting. So basically, when you inject script on the frontend, maybe through input or directly through URL, and that gets injected. And then it's sent back to the server and then returned as is, and it gets executed. This behavior is called XSS because then the browser will consider that particular script as part of the page, and it will execute that script. And that script could contain anything, like extracting user session information and sending it to any remote server, and so on. There could be a number of things that can be done with that. So to stop access, the first thing is to do validation. You do first of all, front-end validation. You validate the input, whatever, and look for special characters. And you either encode them or filter them, and then you send to the server. And the server should do the same. It should validate the request data received from the frontend and again do the filtration and encode the data while sending it to the client. So that's what is needed to prevent access. Validation is the simple answer. Though there are other various tools nowadays, you can use various NPM packages available, which can do this for you. But they also do the same thing. It's the validation that prevents access to the attack.

So the question really emphasizes using index.db to store the shopping cart across multiple sessions. Local session storage does not work on multiple tabs, and local storage can work on multiple tabs. Local storage can be one option, but index.db can also be one option to store card information. It can also be stored in Redux or any other global state management, unless the card information is huge, then storing it in index.db might make sense. Efficiently managing a shopping cart state across multiple sessions using index.db is key. I'm not sure what exactly is needed here, because the approach remains the same, whether you store it in index.db, whether you store it in a global state manager, or even in local storage for that matter. The methods for storing and extracting the data remain the same, we have to ensure that it is available across any tab even if the user has ended the session, closed the browser and reopened it, then it should be available. If that's a use case, then of course, if you go with local storage or index.db, in that case, a global state manager may not persist. But if you want to only persist the cart information as long as the browser remains open, then you can use the global state manager as well. And in that case, you can also send that data back to the backend and store it, and when the user reopens it, then you can load the data from the backend API. In that case, a global state manager will work just fine. So I'm not exactly sure how to answer what you want me to answer here, like efficiently using index.db because the approach will remain the same.

Okay, error handling. There are various ways to do error handling in both the front end and the back end. So on the front end, especially in React, you can use error boundaries. You can have a global error handler with which you can attach to the document or the window object, which will capture all the errors and send them to a custom logger on the back end. Or you can use tools like Sentry, which can capture front end errors and monitor them on the UI of tools like Sentry. Then, of course, I talked about React boundaries and having a custom window error handler on the front end to check if there are any errors. Then you can have try catch blocks to handle errors out of the front end gracefully. So that's about the front end. On the back end side, again, the same thing applies. You do try catch. You do global error handling, like in a router, you can have a middleware for error handling that will act as a global error handler for various ports. So that's there. Other than that, you can have a logger like NPM logger integrated on the back end. Like Winston is another library. You can log errors, or you can have other tools like ELK Stack, or New Relic, which supports Node as well. And even New Relic Browser is also there, which supports the captioning of JavaScript errors. So there are many ways to handle and capture errors on both the front end and the back end. Like I said, on the back end, you do try catch. You have a global error handler, and you should log errors on any error handling tools, like NPM or Splunk or any other tools of your choice, so that you can debug them in production because the number of errors can be multiple.

When managing state in a React application using Tailwind CSS for styling without compromising performance, you have to consider the global state and component-level state separately. Global state refers to the entire state of the application, which is managed using a global state manager. Tailwind CSS styling is applied to components or the entire application before the state is processed. However, if you're concerned about switching between different styles when the state changes, such as changing the color of a button or theme, you should ensure batch processing of the state. The latest version of React, 18.2, provides this feature, preventing flickering or performance issues related to style switching. Another approach is to manage state on a component level rather than globally, especially for smaller components. This can be faster and more efficient. To optimize performance, you can use the React profiler and React Dev Tools to identify and address any performance issues. To answer the question more directly: You can manage state in a React application using Tailwind CSS without compromising performance by ensuring batch processing of the state, using component-level state management for smaller components, and monitoring performance with React Dev Tools.

Okay, so solid has, see, so far solid principle is a single responsibility principle. This class, drone control, has fly, gather data, process data, render data. It seems this particular line is doing everything. The first thing it's violating is the single responsibility principle. This class is handling everything. You can segregate these responsibilities into multiple classes. For example, gathering and processing data could be done in a separate class. Rendering could be in a separate class, and things related to flying could be in a different class. That's one thing that's violating. Yeah, that's the first thing this class is violating. Another thing is I stands for interface segregation, which is similar to what I've said here. So, it's all validating this principle. But to answer this question, the first principle is definitely being violated, so that should suffice.

There are multiple things that I can identify. One thing is that it's handling promise, this test data and update function. It's handling promise and it has not used async. So that's one thing which is there. Second thing, it's dot then is being used, which is different and is usually associated with fetch and also promises. I'm not sure if it needs to be converted into JSON first before the actual data can be assigned to update data. So that could be another problem, but it's not handling promise properly. That's very evident. It's not using async. It's also not handling any kind of error. It does not have any cache flow. That's another thing which is there.

That offline functionality is usually achieved through web workers and especially with service workers because we need to check whether the user is offline or not. And so on. Web workers work, and service workers is one of the types of web workers. So web workers work in the background, so they can check things like whether the particular user is offline or not. You can help build offline-related functionalities. You can design an offline user interface. For example, you can gray out the background color and disable a few things, and so forth. It depends on the design, what kind of design you want to show to the user when the user is offline. The end design can be used, and for that, you can probably have and design components which give you the look and feel of online and offline differently and load them based on the current state of the user, whether the user is offline or online, which can be achieved through a web worker. You can cache certain things. For example, you can cache certain assets, certain classes, certain styles, when the user is offline. And you can use browser caching to populate that minimalistic content and styles to showcase the offline user interface. And once the user is back online, then you can switch these and make API calls and load the dynamic data. So, the offline handling is one of the properties of PWA, progressive web app. Of course, there are many other features, like full screen and having an icon for opening the website, which is another property of a PWA. But for offline, like I said, service workers and caching certain styles and assets on the browser should be sufficient.

So GraphQL is more or less data aggregation, kind of a middleware between the actual service and the front end. So it's a kind of buffer layer. And GRPC is a remote procedure call. GRPC was developed by Google as an alternative to other testing protocols. So for real-time collaboration using this, it can be trivial. But using this, if I have to answer that, so basically, the front end, which will be there on the drone, will send capture some data and send it to the back end. And also consume some data. So GraphQL, like I said, is a key player. It can give you exactly what you need and send exactly what needs to be sent without worrying about what changes are made on the back end and without making too many API calls. Yeah. Because that's the purpose of GraphQL. So in real-time design collaboration, I assume that a lot of data will flow to and fro. And using GraphQL will minimize the number of API calls. So that's one benefit which I can clearly see here. And remote procedure calls, again, you can make remote procedure calls to process the data on various services. That's what I can answer with this limited context. Around that, I'm not sure what else is needed. If I had gone through with a real person, then I could have answered any follow-up question. But that's all I can think of right now.

I'm familiar with using gRPC within a Node.js context to manage inter-service communication in a microservice architecture. So when you talk about talking between two microservices, there are various ways. One is, of course, normal HTTP request and response. Another one is asynchronous, in which you can use messaging queues. I guess gRPC could be a third alternative, probably to HTTP. So gRPC is a remote procedure protocol, so basically you're following the procedure of the remote service which you want to update without using the HTTP protocol. And you're using the remote procedure, or a procedure is nothing but a function directly. So one microservice is calling the procedure of another microservice to communicate. So yeah, that's what will happen in that case. So basically you're communicating using a remote procedure call. I'm not really sure, probably one thing which could be a benefit here is that with gRPC, if I can recall correctly, is that probably there is backward compatibility because you're making a procedure call, and if something changes in that procedure, probably you don't have to make any changes with HTTP API call. You must know the data format that you need to send. If I can recall correctly, I could be wrong, because like I said, I haven't worked with gRPC before. But yeah, I can work with that if there's a need to use gRPC only for communication.