Is My React Web App Ready for Launch?

Hello, everybody. I'm Aditi. I'm a senior engineer at Mckenzie & Company Vietnam, and the topic that we will be talking about today is if your React web application is ready for production.

So, as part of my work, I got a chance to work with JavaScript stack, and I worked with Angular for a year, and I have been working with React since then. So, first, we need to understand that why do we need our application to be production-ready. So, before we dive into dissecting the production readiness checklist, we need to understand what are the reasons we do so.

So, the first thing that comes to mind is user experience. So, user experience can vary based on your target audience. It can be someone old, or someone young, or someone from a different generation, but ultimately, it's all about keeping it simple and intuitive. Also, reputation is involved when we talk about websites, right? So, the company's website is the face of the company. So, we all depend a lot on the application reviews, and as a tech-savvy generation, we need to make sure that the application is responsive. Also, the website experience should not be laggy, otherwise it can lead to a bad reputation, and also discourage future potential users. Security is definitely always a crucial part of a well-tested application, and we should make sure that the user data is never at risk. Cost, well, fixing bugs or issues on a production environment is always more expensive and more time-consuming. So having done that beforehand would actually save us time and money.

Moving on, we are working in a very competitive sector, right, so there is always advantage of delivering something really fast, but there are also downsides of doing very quick development. So that is why we need to use a production readiness checklist to make sure that is our application ready for launch or not. I've also recommended some tools and best practices that you can follow. So before we dive in, let's imagine that we are in a car race and we have a start point, we have a finish line that we need to reach. And the racetrack is actually our production readiness. And the checklist items are the checkpoints.

So the first checklist item would be key journeys. So key journeys by key journeys, I mean that all the features and functionality should be in place and work as expected. First, we need to identify the key journeys. They can be log in processes, they can be completing a purchase or submitting a form. First that we will write test cases. Now, test cases should simulate the entire journey, the entire key journey including the steps and also state the expected outcomes. There are a lot of automation tools these days that we can use to test our key journeys such as Cypress, Jest and Enzyme. I would specifically want to highlight the importance of regression tests. By writing regression tests, we can always eliminate the human error from the testing process and save time on the retesting.

If we find any burning issues, we can address these before the launch. Moving on, I think the next checklist item would be optimized performance. Performance means that your application should load well, it should run smoothly, it should meet all acceptance performance standards. We often define NFRs or non-functional requirements in the beginning of our development process. These usually indicate to functionalities such as, which refer to scalability, availability, reliability, security, usability, and all these things, which are not really key features but they impact the overall quality of our application.

We need to make sure that our application is tested and optimized for performance. First, we need to identify the identification process for the performance metrics. These are called web vitals. These can be things like page load time, time to first byte, largest contentful paint, first contentful paint, first input delay, cumulative layout shift. All these are matrices that we can evaluate on. Once we've figured them out, we can go and use a testing tool to track the speed and responsiveness of our application. Some common issues that arise are usually due to large images or large assets that we are using. We might be using some JavaScript libraries which are not required or just generally due to inefficient code. So what we need to do is we need to run these tests. We need to analyze the report and identify areas of concern. We can use tools like Lighthouse, webpagetest, loadimpact and react profiler. These help us find the performance throttlenecks or vulnerabilities around that. So now we need to work on these concern areas. So one thing that we can do to optimize images is use packages like tinypng, imageoptim to compress these images, reduce the size so that they load faster. We can also implement code splitting such as lazyloading, and we can not only just do lazyloading on the routes, but also on the internal components. We can also use something called a webpack bundle analyzer which helps us find the unnecessary JavaScript files and libraries, and we can remove those from our code.

Next would be security. So security, we need to make sure that the SSL certificates are placed, authentication flows are secure, and data is encrypted. So one thing that we can do is, we can do a thorough code review of these flows, specifically authentication authorization, data validation, input handling, output handling, all these have to be reviewed again, right. So another thing we can do is static code analysis, so tools like SonarQube and ESLint come really handy in this, and the help is find any vulnerability around cross-site scripting or any insecure code practice that might be in our code right now. Penetration testing, basically attackers can exploit network infrastructure, they can exploit the authentication mechanism, or how we store our data, or overall application logic, so we need to make sure we go through append testing before we go into production. Advanced security testing, we can do using vulnerability scanning and one of the tools that I can recommend is Nessus.

Moving on, the next checkpoint is scalability. So when I say scalability, I mean that the application should be ready to handle large traffic and a big user base. Identifying scalability requirements basically talks about two things, right.

So we need to make sure that NFRs are listed down in the beginning of our development cycle. So we need to make sure that we need to know that what is the expected number of users. What are the concurrent number of concurrent requests that we are expecting. Once we have that, we can set these as performance benchmarks and also perform load testing on it.

So load testing, we can use automated tools like Apache Jmeter or Gatling. These tools actually help us simulate the user traffic that we are expecting. So we gradually increase the load that is reaching our application until we reach the desired level of performance. And that is how we can understand what are the performance issues or bottleneck. Once we have them, we can work on them.

Another recently used, you know, popular testing mechanism is cloud-based testing, where we deploy an application on cloud and then do this kind of a load testing. So the difference is that we are testing on cloud and not on the real infrastructure. So it can be done without having the real infrastructure set up. The task is that we should test under different network conditions. Imagine you have a user sitting somewhere in a different location having unstable or unstable network, right? So in that situation we need to test all those conditions beforehand.

So the last checkpoint that we have is monitoring. So when we say monitoring, we mean that the monitoring tools should be set up, configured, and also there should be alert systems already in place, which make sure that, through the right paths and to the right people, this message is reached that there is some monitoring issue, there is some blockage. Now we need to identify these monitoring requirements, which are called KPIs or Key Performance Indicators. When we monitor them, they can be something like a server response time, error rate, page load time and we set a threshold where there would be an alert that will be triggered if we cross the threshold. Now we can use tools like Neural Network Browser, DataDog, Browser Monitoring. All these tools help us set up a monitoring system and an alerting system as well. We also need to make sure that the report that is generated is intuitive, easy to understand, easy to figure out where the issue is from. The reporting is also a key part of monitoring.

Which brings us to the end of this entire race that we were running towards launching our application. Well we have reached the end of the line and we are ready for launch. I just want to iterate on one point, often it happens that we are reluctant in making a hard decision if this is the right time to launch or not. But I need to tell you that no system is perfect, it is an iterative process, there are always trade-offs and it is always based on your business requirements. So you can always have a production based on, you know, you can have an MVP launch, you can have a version 1 launch and then you can roll out the application phase by phase and see the effect of the application on the target audience. And that brings us to the end. I hope you liked it.