Dheeraj Verma

Yeah. So, I am Viraj Verma, and I have graduated in computer application in the year 2015. After that, I started my career at a company called Tech Edge in Noida. And there, I was working on an insurance-based domain, and the project was in the framework of PHP. There, I learned jQuery JavaScript and also worked on the MySQL database. After that, I switched my company to TechSolutions, and there we used SugarCRM, which is based on PHP. We were responsible for creating plugins for SugarCRM. The plugins basically integrated calling channels and SMS and email channels through which SugarCRM users could call someone, send an SMS to someone, or email them. So, we used SendGrid for emailing and SMS features and Twilio and plugins for using the calling system. After that, I joined my current company, IT systems. Here, I've worked on domains like healthcare, ecommerce, and a few media-related projects. I worked on the Laravel framework, VxGS, Node.js, and Next.js also. And in terms of databases, we used Postgres, MongoDB, MySQL, and MSSQL. So, that's pretty much about me.

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

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

So to handle errors in Laravel, we have like exception handlers. And before that, we can even use validations to cater all the common errors that we can get from the user side. And if something is not done in the validation or handling, then we can have exception handling, which will cater all the exceptions that come into the program and execution. And in terms of here, we can use try and catch, and it can basically handle any of the errors. And for good practice, we can use null coalescing operators with the object's properties.

So when we're getting a large dataset from the Laravel backend onto the React app, we can use lazy loading techniques. In that lazy load, we can use pagination. For the first set, we can get 10 records or 15 records as per user need. And as the user scrolls down, as soon as the scroll hits the last item, it will again throw an API call, and the API call will fetch another set of records. That way we can moderate the large amount of records on the frontend side. And for the backend side, it will be more efficient and performance-oriented when we're using pagination and lazy loading techniques.

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

Then the 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 address any issues here, but this much code is okay in my terms; there's no issue with this.

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

So for any disaster recovery, one is that we can follow on the AWS site is, like, we can have multiple EC2 instances or other instances, basically, to cater any disaster. Let's say if you have a single instance and it is also affected by that instance and your live site or live web application will be down for hours until the disaster is properly recovered. So, my ideal solution is to keep multiple instances, replica instances to handle the traffic as well. And if any of the instances gets impacted by any disaster, then 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 implement this strategy to keep multiple instances, and we can use scheduled backups of snapshots and EBS images. And for database side, we can use snapshots to keep our data safe. And as when there is any disaster that happens, then we can re-spin off our instance out of that and live the end user should not get hampered.

So for Docker, we can create a Docker file with all the dependencies for the PHPUnit testing, like the PHPUnit package. We can create a Dockerfile with all the dependencies, such as a PHP environment, a web application, and server environment. If we create this Docker file, it will be an isolated deployment of the unit PHP unit. It will handle all the unit cases, and it will test the application on the Docker side. Once we develop this Docker file, we don't have to again and again do the deployments for the PHP unit, and it can work independently.

To leverage AWS services to scale application architecture for increased load, we can do is create multiple instances and configure them with auto scale functionality. Onto one server, we should configure it in such a fashion that if the CPU utilization or the memory utilization crosses the 50% mark, then we can spin off another instance parallelly using the AWS services, and it will cater to all the increased load and traffic. Once the increased traffic has been cleared off or the website gets back to its normal state when there is no load, then that particular new instance can be automatically terminated. We can do this for increased loads.