¿Está lista mi aplicación web de React para su lanzamiento?

Hola a todos. Soy Aditi. Soy una ingeniera senior en Mckenzie & Company Vietnam, y el tema del que estaremos hablando hoy es si tu aplicación web de React está lista para producción.

Como parte de mi trabajo, tuve la oportunidad de trabajar con el stack de JavaScript, y trabajé con Angular durante un año, y he estado trabajando con React desde entonces. Entonces, primero, necesitamos entender por qué necesitamos que nuestra aplicación esté lista para producción. Antes de sumergirnos en desglosar la lista de verificación de preparación para la producción, necesitamos entender cuáles son las razones para hacerlo.

Lo primero que viene a la mente es la experiencia del usuario. La experiencia del usuario puede variar según tu público objetivo. Puede ser alguien mayor, o alguien joven, o alguien de una generación diferente, pero en última instancia, se trata de mantenerlo simple e intuitivo. También está involucrada la reputación cuando hablamos de sitios web, ¿verdad? El sitio web de la empresa es el rostro de la empresa. Todos dependemos mucho de las reseñas de la aplicación, y como una generación tecnológica, necesitamos asegurarnos de que la aplicación sea receptiva. Además, la experiencia del sitio web no debe ser lenta, de lo contrario puede llevar a una mala reputación, y también desalentar a futuros usuarios potenciales. La seguridad es definitivamente siempre una parte crucial de una aplicación bien probada, y debemos asegurarnos de que los datos del usuario nunca estén en riesgo. El costo, bueno, solucionar errores o problemas en un entorno de producción siempre es más caro y más lleva más tiempo. Por lo tanto, hacerlo con anticipación realmente nos ahorraría tiempo y dinero.

Pasando a otro tema, estamos trabajando en un sector muy competitivo, ¿verdad? Entonces siempre hay ventajas de entregar algo muy rápido, pero también hay desventajas de hacer un desarrollo muy rápido. Por eso necesitamos usar una lista de verificación de preparación para la producción para asegurarnos de que nuestra aplicación esté lista para el lanzamiento o no. También he recomendado algunas herramientas y mejores prácticas que puedes seguir. Así que antes de sumergirnos, imaginemos que estamos en una carrera de autos y tenemos un punto de partida, tenemos una línea de meta que debemos alcanzar. Y la pista de carreras es en realidad nuestra preparación para la producción. Y los elementos de la lista de verificación son los puntos de control.

Entonces, el primer elemento de la lista de verificación serían los recorridos clave. Por recorridos clave, me refiero a que todas las características y funcionalidades deben estar en su lugar y funcionar como se espera. Primero, necesitamos identificar los recorridos clave. Pueden ser procesos de inicio de sesión, pueden ser completar una compra o enviar un formulario. Primero, escribiremos casos de prueba. Ahora, los casos de prueba deben simular todo el recorrido, el recorrido clave completo, incluyendo los pasos y también indicar los resultados esperados. Hoy en día hay muchas herramientas de automatización que podemos usar para probar nuestros recorridos clave como Cypress, Jest y Enzyme. Quisiera destacar especialmente la importancia de las pruebas de regresión. Al escribir pruebas de regresión, siempre podemos eliminar el error humano del proceso de pruebas y ahorrar tiempo en las pruebas nuevamente.

Necesitamos asegurarnos de que nuestra aplicación sea probada y optimizada para el rendimiento. Primero, necesitamos identificar el proceso de identificación de las métricas de rendimiento. Estas se llaman web vitals. Pueden ser cosas como el tiempo de carga de la página, el tiempo hasta el primer byte, el mayor contenido visible, el primer contenido visible, el primer retraso de entrada, el cambio de diseño acumulativo. Todas estas son matrices que podemos evaluar. Una vez que las hayamos identificado, podemos utilizar una herramienta de pruebas para rastrear la velocidad y capacidad de respuesta de nuestra aplicación. Algunos problemas comunes que surgen suelen ser debido a imágenes grandes o activos grandes que estamos utilizando. Es posible que estemos utilizando algunas bibliotecas de JavaScript que no son necesarias o simplemente debido a un código ineficiente. Entonces, lo que necesitamos hacer es ejecutar estas pruebas. Necesitamos analizar el informe e identificar áreas de preocupación. Podemos utilizar herramientas como Lighthouse, webpagetest, loadimpact y el react profiler. Estas nos ayudan a encontrar los cuellos de botella de rendimiento o las vulnerabilidades relacionadas con eso. Ahora necesitamos trabajar en estas áreas de preocupación. Entonces, una cosa que podemos hacer para optimizar las imágenes es utilizar paquetes como tinypng, imageoptim para comprimir estas imágenes, reducir el tamaño para que se carguen más rápido. También podemos implementar la división de código, como la carga perezosa, y no solo podemos hacer carga perezosa en las rutas, sino también en los componentes internos. También podemos utilizar algo llamado webpack bundle analyzer que nos ayuda a encontrar los archivos y bibliotecas de JavaScript innecesarios, y podemos eliminarlos de nuestro código.

A continuación, estaría la seguridad. Entonces, la seguridad, necesitamos asegurarnos de que los certificados SSL estén en su lugar, los flujos de autenticación sean seguros y los datos estén encriptados. Una cosa que podemos hacer es realizar una revisión exhaustiva del código de estos flujos, específicamente la autenticación autorización, validación de datos, manejo de entrada, manejo de salida, todos estos deben ser revisados nuevamente, ¿verdad? Otra cosa que podemos hacer es el análisis estático del código, por lo que herramientas como SonarQube y ESLint son muy útiles en esto, y nos ayudan a encontrar cualquier vulnerabilidad relacionada con la inserción de código o cualquier práctica de código insegura que pueda haber en nuestro código en este momento. Las pruebas de penetración, básicamente, los atacantes pueden explotar la infraestructura de red, pueden explotar el mecanismo de autenticación, o cómo almacenamos nuestros datos, o la lógica general de la aplicación, por lo que necesitamos asegurarnos de pasar por pruebas de pruebas antes de entrar en producción. Las pruebas de seguridad avanzadas se pueden realizar utilizando el escaneo de vulnerabilidades y una de las herramientas que puedo recomendar es Nessus.

Continuando, el siguiente punto de control es la escalabilidad. Cuando digo escalabilidad, me refiero a que la aplicación debe estar lista para manejar un gran tráfico y una gran base de usuarios. Identificar los requisitos de escalabilidad básicamente habla de dos cosas, ¿verdad?

Entonces, debemos asegurarnos de que los NFR se enumeren al comienzo de nuestro ciclo de desarrollo. También debemos asegurarnos de conocer el número esperado de usuarios y el número concurrente de solicitudes que esperamos. Una vez que tengamos esa información, podemos establecer estos como puntos de referencia de rendimiento y realizar pruebas de carga en ello.

Para las pruebas de carga, podemos utilizar herramientas automatizadas como Apache Jmeter o Gatling. Estas herramientas nos ayudan a simular el tráfico de usuarios que esperamos. Aumentamos gradualmente la carga que llega a nuestra aplicación hasta alcanzar el nivel de rendimiento deseado. De esta manera, podemos comprender cuáles son los problemas o cuellos de botella de rendimiento y trabajar en ellos.

Otro mecanismo de prueba utilizado recientemente es la prueba basada en la nube, donde implementamos una aplicación en la nube y realizamos pruebas de carga en ella. La diferencia es que estamos probando en la nube y no en la infraestructura real. Esto se puede hacer sin tener la infraestructura real configurada. La tarea consiste en probar bajo diferentes condiciones de red. Imagina que tienes un usuario en una ubicación diferente con una red inestable. En esa situación, debemos probar todas esas condiciones de antemano.

El último punto de control es el monitoreo. Cuando hablamos de monitoreo, nos referimos a que las herramientas de monitoreo deben estar configuradas y también debe haber sistemas de alerta en su lugar. Estos sistemas se aseguran de que, a través de los canales correctos y las personas adecuadas, se transmita el mensaje de que hay algún problema de monitoreo o bloqueo. Ahora debemos identificar estos requisitos de monitoreo, que se llaman KPI o Indicadores Clave de Rendimiento. Al monitorearlos, pueden ser cosas como el tiempo de respuesta del servidor, la tasa de error, el tiempo de carga de la página, y establecemos un umbral donde se activará una alerta si lo cruzamos. Podemos utilizar herramientas como Neural Network Browser, DataDog, Browser Monitoring. Todas estas herramientas nos ayudan a configurar un sistema de monitoreo y un sistema de alerta. También debemos asegurarnos de que el informe generado sea intuitivo, fácil de entender y fácil de identificar de dónde proviene el problema. La generación de informes también es una parte clave del monitoreo.

Lo que nos lleva al final de esta carrera hacia el lanzamiento de nuestra aplicación. Hemos llegado al final y estamos listos para el lanzamiento. Solo quiero enfatizar un punto, a menudo sucede que dudamos en tomar una decisión difícil sobre si es el momento adecuado para lanzar o no. Pero debo decirte que ningún sistema es perfecto, es un proceso iterativo, siempre hay compensaciones y siempre se basa en los requisitos comerciales. Siempre puedes tener un lanzamiento basado en producción, puedes tener un lanzamiento de MVP, puedes tener una versión 1 y luego puedes implementar la aplicación por fases y ver el efecto que tiene en el público objetivo. Y eso nos lleva al final. Espero que les haya gustado. Muchas gracias.