Raja Ravichandra Velichety

Hi. I'm, uh, I'm Raja Ralchandra, and I'm a tool stack developer specializing in Zango in the back end. And for different end part, I work with React and, uh, Vue JS for the most part. And I basically work with several technologies, including but not only to to the FQL and, uh, for the database side, I am familiar with postless SQL. And then, um, yeah, PostgreSQL. And I also developed several web applications using, uh, Cloud Native applications such as AWS and Azure. Yeah. That's

For a multi language support, when you're in something like that, how do you design this to work in advance? Maybe in the local specific? One thing. I will design wishful endpoints, um, created by using internationalization, which gives you response based on the location that you guys are there. And for the endpoints to work, I would take where am I now? All the credit up current, uh, endpoints, and then apply internal rationalization on top of it for us to support. And I think splitting it into different locations based on where they are served should, uh, bring out efficiency because it would be easy to connect with the people. If it's in a particular location, then serving it through the nearest, um, server would be a good fit. So I think based on that, if we split, then it would be a good thing.

Steps would you follow to create a CICD pipeline for webinarsolving, appended testing, and then deployment on the result. The CICD pipeline, I think I would go with the Azure pipelines. And then using that, uh, Azure pipelines, I will, uh, uh, make a build process stop, and which also includes testing, which takes for the all the automated tests. And once the testing is done, then it goes on to deployment. But I think, uh, deploying it to directly production wouldn't be a big fit. I think going through a staging process should help us, uh, to find any bugs or if there is anything that needs to be checked before going to production. So after once the staging is done and if we are okay with what we have on the staging, then, uh, we'd have a step where we can, uh, proceed to, uh, building and deploying onto production from there if we are okay with what we are having in the staging. So yeah. That's how I do it.

How would you incorporate just to look at error handling in single app to provide detailed feedback to the client side written in the BI? So there are two ways that I can do it. Um, one thing is for the error handling, I can just, um, use, uh, try and catch, and then find the error, and then send those errors back to the client based on what the error is. And I think having a centralized, uh, error handling mechanism should help us, uh, in creating a robust application which will handle, uh, all the errors. And if it's any particular part of the application that we are concerned about, then I think error boundaries would be good. But, uh, in our case, I think as we are building the API, I think, uh, we are just good with having, uh, particular errors, and then, uh, catching them and then sending it back should do the job. Yeah. That's all to it using, uh, exception handling. And other best thing would be if we are implementing, uh, site wide or the application wide, uh, error handling, then I think creating a middleware, which will handle all these errors would free up, uh, the error handling process as it will handle the rest. So I think it will be helpful to have a centralized one by using the middleware. But if it's only requirement, that's all.

Next series, what techniques would you use to dynamically generate static pages for our product backlog updates daily? I think, uh, I would use get static bot, uh, get static props. And based on that, I will build pages. Each page will act as, uh, also the product catalog that uploads data. Yeah. I think having, uh, yeah, I think, uh, using get static props and then building tables using it or just by incorporating GraphQL, uh, into what are the changes made and then deploying each save once a day. And because it uploads once a day, so that should make all the pages fast and should be savable.

We apply solid design principles in these types of changes, I think, for this or, uh, Xandr project to implement and build things further. So I'm just solving, uh, solid design principles of variation studio for, uh, improving the angle project, which I would prefer, uh, single responsibility. That is, uh, each model and views will all be separated based on what their responsibility is and then structure them accordingly. And, uh, I think structuring them based on the responsibility of the functionality that they work, uh, is very crucial. And, uh, I think we should have a proper, uh, uh, structure through it. Uh, basically, uh, dividing it it into, uh, all the views and models, and then the templates based on what their functionality is rather than, uh, providing or having all of them at once and then being clumsy. So I think splitting it, uh, into based on the responsibilities, uh, should be a good fit, and isolating each of them would work great. And if even if we want to scale, uh, it would help us. And I think removing any redundant or, uh, repeating principles, uh, repeating code that is do not repeat to yourselves because all the code which is just laying there, and if we are we use the writing it, then I think we should write code once and better to reuse it than to have code in several places because they will make, uh, maintaining and scalability of our project will be hard. So

Uh, other. This is model view set. I mean, this will self sales noise. Serializer and run perform a pivot and then get file. And then what it is doing is item dot object dot filter. Where is it being used? I know all these are arranged. I explained what to do for scalability and maintainable performance. And so and to say, what it is doing is that it's taking, uh, serializer and sale. I use it. Users, I'll put a password user. Yes. And I think for the view sets, we need to use actions, uh, if we want to implement any further um, any further designs, uh, any further functions that we want to add to the particular view set, because the view sets already provide us with the opportunity of create all the CRUD applications, uh, that is the all the CRUD features. That is create, uh, we update and delete. And if you want any other functionality such as, uh, creating it. But I think, uh, we'll be using oh, so the platform create, I think it's better to do this creation in the serializer part rather than doing it in the item view set because it's not a good practice. And in the, uh, serializer part, we can just call the default create method and then overwrite it and save it over there rather than doing it here. And if you want some other method to be implemented in the view set, then I think using actions and the decorator actions should be the way to go for this.

React has its words when it comes to rendering. The following codes in text explained by the component might not do rendering when items is updated. Okay. What's happening? Now I have a state and I have a function where I use a state, uh, is declared and then constant add equals to item item dot push. Item dot push. That's the issue here because the thing is the React checks this functionality based on triple equals. Whether the, uh, item is changed or not, it just checks based on triple equals. And if we mutate any particular state variable, then React might not, um, uh, notice it as a update, and it will not, uh, rerender it. So for us to ensure that React, uh, rerenders, we need to keep that immutability alive. So for anything that we want to change or do anything, we should use immutable features such as map filter because it does not change the particular state variable, but instead it just creates a new one and then adds them here. But, uh, in our case, we are mutating the items by using push, which is not a recommended practice, and that's why it's not reinvented.

And the next day's application, how would you leverage incremental static regeneration to improve the performance of content updates on the news portal? Incremental static regeneration. Would you lower its incremental static read generation to improve the documents? Uh, I'm not sure. I mean, one thing I can think of it is by using that get static props, I'll get the data and then, uh, updating each part of would be also, but, uh, I'm not exactly sure about this.

How do we ensure cross browser and cross device compatibility? The complex layouts in a responsive React application. Yeah. How do we ensure cross browser and cross device compatibility for a complex CSS layout? And I have responsive React application. I think using web kits for, um, having the CSS work on different, uh, browsers where, uh, but it is not supported, uh, locally. And, uh, but the cost device compatibility, I would prefer to use Bootstrap, uh, which is the CSS framework because it just handles all of that. And, uh, if not, if you want to use the CSS directly, then I think we should consider a CSS media queries and then go about it by writing several, uh, media queries. But I think going with, uh, CSS frameworks, like, uh, Bootstrap or Tailwind CSS should be good because we already have all of those functionality written into them. So why to reinvent the wheel than to use the existing ones?

Can you revise on a strategy to implement advanced search functionality with filters and full text search capabilities? And our Sango application. Uh, Yeah. I think, uh, it's a good yeah. For me, uh, the thing that I can think of is if we have several articles which are being get that we are getting as in a JSON format, and if we are storing it in our database, then I think we can implement this, uh, by checking, uh, several factors. So if you consider it like a blog application, we can have filters to check if any particular words are in, uh, any particular tags that we have attached to article. And if so, then we will return it or else, uh, then they will check, uh, if the filters does not return anything, then I think going yeah. I think having a union of both the filters which are checking for tags and the, uh, search should be done on the whole content part with the, um, met, uh, with the full text capability should be a good thing, I guess. Basically, uh, if you miss something in the um, content, then we would get by the tags and vice versa. So, yeah, that's pretty much it.