Raja Ravichandra Velichety

Hi, I'm Raja Ralchandra, and I'm a tool stack developer specializing in Zango for the backend. For the frontend, I work with React and Vue JS for the most part. I basically work with several technologies, including FQL and, for the database side, I am familiar with Postgres SQL. And then, yes, PostgreSQL. And I also developed several web applications using Cloud Native applications such as AWS and Azure.

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

To create a CICD pipeline for webinarsolving, appended testing, and then deployment on the result, I would follow these steps using Azure pipelines: Steps would I follow to create a CICD pipeline for webinarsolving, appended testing, and then deployment on the result. I would go with Azure pipelines. Using that, I would make a build process stop, which also includes testing, which takes all the automated tests. Once the testing is done, it goes on to deployment. However, deploying it directly to production wouldn't be a good fit. I think going through a staging process would help us find any bugs or if there's anything that needs to be checked before going to production. So after the staging is done and if we're okay with what we have on the staging, we'd have a step where we can proceed to building and deploying onto production from there if we're okay with what we have in the staging.

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. One thing is for the error handling, I can just use 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 error handling mechanism should help us in creating a robust application which will handle 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 in our case, I think as we are building the API, I think we are just good with having particular errors, and then catching them and then sending it back should do the job. That's all to it using exception handling. And another best thing would be if we are implementing site wide or the application wide error handling, then I think creating a middleware, which will handle all these errors, would free up 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 that's all the requirement.

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

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

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 to say, what it is doing is that it's taking 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 if we want to implement any further designs or functions that we want to add to the particular view set, because the view sets already provide us with the opportunity to create all the CRUD applications, that is, the create, read, update, and delete features. That is, create, update, and delete. And if you want any other functionality, such as creating, for example. But I think we'll be using the platform's 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 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 are updated. Okay. What's happening? Now I have a state and I have a function where I use a state, which is declared and then a constant add equals item dot push. Item dot push. That's the issue here because the thing is that React checks this functionality based on triple equals. Whether the item is changed or not, it just checks based on triple equals. And if we mutate any particular state variable, then React might not notice it as an update, and it will not rerender it. So for us to ensure that React 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 or filter because it does not change the particular state variable, but instead it just creates a new one and then adds them here. But in our case, we are mutating the items by using push, which is not a recommended practice, and that's why it's not re-rendered.

Incremental static regeneration would allow us to leverage its capabilities to improve the performance of content updates on the news portal. To do this, I would lower its incremental static regeneration to improve the documents. I mean, one thing I can think of is by using get static props to get the data and then updating each part, which would also be beneficial, but 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 a responsive React application. I think using web kits to have the CSS work on different browsers where it is not supported locally. And for device compatibility, I would prefer to use Bootstrap, which is a CSS framework because it handles all of that. And if not, if you want to use CSS directly, then I think we should consider using CSS media queries and write several media queries. But I think going with CSS frameworks, like Bootstrap or Tailwind CSS, is good because we already have all of that functionality written into them. So why 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 for our Sango application? I think it's a good idea. For me, the thing that I can think of is if we have several articles which are being received in a JSON format, and if we are storing it in our database, then we can implement this by checking several factors. So if you consider it like a blog application, we can have filters to check if any particular words are in any particular tags that we have attached to an article. And if so, then we will return it. Or else, the filters that do not return anything, then I think having a union of both the filters which are checking for tags and the search should be done on the whole content part with full text capability should be a good thing. Basically, if you miss something in the content, then we would get it by the tags and vice versa. So, that's pretty much it.