Dheeraj Verma

Yeah. Sure. So, uh, I am Viraj Verma, and I have been graduated in computer application in the year 2015. After that, I have started my career from a company called Tech Edge in NIDA. And, uh, there I was working on, uh, some insurance based domain, and, uh, the project was, uh, in framework of PHP. There, I have learned jQuery JavaScript and also worked on MySQL database. After that, I have, uh, switched my company to TechSolutions, and there we were using SugarCRM that is based on PHP. We were responsible for creating plugins for SugarCRM. Uh, the plugins, uh, basically integrates calling channel and SMS and email channel through which, uh, the SugarCRM users can call someone, SMS to someone, or he can even email to them. So we we have used SendGrid for the emailing and SMS features and, uh, Twilio and plugins for, uh, using the calling system. After that, I have joined my IT systems, and this is my current company. Here I've worked for domain like health care, some ecommerce, uh, and few for media media related projects I have done. I worked on, uh, Laravel framework, VXGS, Node. Js, and, uh, Next. Js also. Uh, and in terms of database, we have used Postgres, MongoDB, my SQL, MSSQL. So that's, uh, pretty much about me.

In terms of, uh, Laravel queue system, like, uh, Laravel, uh, queue, we can basically create number of jobs and, uh, as there is a queue worker that runs in the background as soon as any And, uh, it is based on first in and first out. And talking about the AWS, uh, service that can complement it, we can use AWS SQS. That is simple queuing service. So it will also, uh, work on this functionality, this fundamental, like, creating jobs and assigning jobs to the Q and Q will automatically process these jobs 1 by 1. So, yeah, we can use them.

So in Laravel, we have AWS SDK. And using this AWS SDK, it has a function, uh, like port file. Uh, using that port file whenever we get any of the file, uh, upload from the front end, then we can process it along. And using the AWS SDK, we can put that file directly onto the, uh, s 3. For this, we have to configure the AWS, uh, secret key and the the client key and AWS region with the bucket name. As soon as we, uh, complete this configuration, then we are, uh, good to upload the files onto the s 3.

So to handle errors in Laravel, we have, uh, like, exception handlers. And, uh, before that, we can even use validations to cater all the common, uh, errors that we can get from the user side. And if something is not, uh, done in the validation or handling, then we can have exception handling That will cater all the exceptions that's coming on to the program and execution. And in terms of here, we can use uh, try and catch, and it it can basically, uh, handle any of the errors. And, uh, for a good practice, we can, uh, use null callers, uh, chaining operators with the objects react objects. That's how we can cater to error handling.

So when we are getting large dataset from the Laravel back end onto the React, so we can, uh, use lazy losing lazy loading techniques. In that lazy load, we can use pagination. For, uh, for 1st set, we can get 10 records or 15 records as per users need. And as this 15 records being retrieved by the, uh, user, they can scroll down. As soon as the scroll hit the last item. It will again throw, uh, API call, and the API call will fetch another set of records. That way we can, uh, moderate the large amount of records on the front end side. And, uh, for, uh, back end side, it will be more efficient and performance, uh, oriented when we are using pagination and lazy loading techniques.

So cohesive, uh, so I don't have any knowledge over the cohesive design system using Tailwind. So sorry for that.

Then constructor is being called and it is initially initializing the user state. I could not see the function definition for SaveUserData and it's not visible, it's not there in this code snippet. I won't be able to extend any issue over here but this much code is okay in my terms there's no issue with this

I don't think there is a need to use this, uh, async a bit over here. We can simply in next of the fetch, we can use then function. It will, uh, once the promise is resolved, we can simply get the response. And then response, we can set user data. One more thing. Uh, we are using useEffect. As soon as the u user ID is changed, this will cause a rerender issue over here. So it should not be the case as we can use to use effect.

So for any, uh, disaster recovery, one is that we can follow on the AWS site is, like, uh, we can have multiple e c two instances or other instance, basically, uh, to cater any of the disaster. Let's say if you have a single instance and if it is also happen over that instance and your live site or live web application will be down for hours until the disaster is properly recovered. So, uh, my ideal solution is to keep multiple instances, replica instances to handle the traffic as well. And if any of the, uh, instance get impacted by any disaster, then other another instance is there to provide the responses for the end user. And the end user experience will not get hampered due to the server that is impacted by disaster. So we can, uh, implement this, uh, strategy to keep multiple instances, and we can use, uh, scheduled backup of snapshot and, uh, EMI images. And for database side, we can use the snapshots to keep our data safe. And as in when there is any disaster happen, then we can, uh, re spin off our instance out of that and, uh, live the end user should not get hampered.

So for Docker, we can we can create a a Docker file with all the dependencies for the PHPUnit testing, like the PHPUnit package. So we can create create a Dockerfile with all the dependencies like PHP environment, web application, uh, server environment. So if we create this Docker file, then it will be, uh, isolated deployment of the unit, uh, PHP unit. It will handle all the unit, uh, cases, and it will test the application being on the Docker side. So once we, uh, develop this Docker file, then we don't have to again and again do the deployments for the PHP unit, and, uh, it can work isolatedly.

So to leverage AWS service to scale application architecture for increased load, we can, uh, do is create multiple instances and with auto scale functionality. Onto the one server, then we should configure it in in the fashion that if, let's say, the CPU the CPU utilization or the memory utilization crosses the 50% mark, then we can spin off another instance parallelly, uh, using the AWS services, and, uh, it will cater all the, uh, all the increases load and the traffic. So, uh, once that increases traffic has been, uh, cleared off or the website get back to its normal state when there is no load, then that particular new instance can automatically terminated. So we can do this for increases load.