Reimagine Frontend in the Serverless Era

Hola a todos. Soy Evangelia. Soy la fundadora tecnológica y creadora de Fioromat Academy, una academia de mejora de habilidades para ingenieros de frontend. Hoy, hablaremos sobre cómo las tecnologías serverless están impactando los frontends. La chispa inicial para esta charla provino de mi antiguo empleador, Elastic, donde hubo muchos desarrollos para el nivel inferior de la arquitectura en el índice de búsqueda y la transformación del backend.

Sin embargo, ¿qué significa esto para nosotros, el frontend, la capa de consumo? Estas son algunas palabras sobre mí, mis hitos más recientes. He estado casi 20 años en la industria tecnológica. Bien. ¿Qué es serverless? ¿Significa que no hay servidor? No realmente. Es una palabra engañosa.

¿Significa que no hay backend? En realidad, el backend está cambiando. Se está volviendo más ligero. Se está convirtiendo en un backend sin estado. Esto es lo que significa. En pocas palabras, significa que el backend se divide en unidades efímeras y sin estado, pero ya no las gestionamos.

Veamos rápidamente cómo opera la arquitectura serverless para luego entender los impactos en el frontend. Seguimos siendo los clientes, los creadores, los constructores de la aplicación. Pero esta vez, nuestro código habla con un gateway de API, pero no es el mismo API como solía ser en las arquitecturas tradicionales. El gateway de API actúa como un enrutador hacia las funciones serverless más pequeñas, no hacia grandes endpoints que devuelven enormes archivos JSON como solían hacer. Se asegura de que lo haga de manera segura y escalable. Así que las funciones serverless y el código de esta arquitectura son unidades de negocio más pequeñas sin ningún estado que nosotros, los clientes, aún escribimos y poseemos, pero el proveedor de la nube se encarga de alojar y escalar las claves.

Sin embargo, les pagamos según el uso, solo cuando las usamos. Eso significa que si se vuelven inactivas por un tiempo, toma un tiempo reiniciarlas. Por eso terminamos en situaciones de arranque en frío, similar a cómo funciona el motor de un coche. Y lo último es la capa persistente, la base de datos. Todavía diseñamos el modelo de datos y las consultas para la aplicación. Sin embargo, el proveedor de la nube se encarga de gestionarlo y escalarlo. Muy bien. ¿Qué significa esto para nosotros en el frontend? El estado se está trasladando al frontend y a las capas de la base de datos, en realidad. Poseemos más estado, en realidad.

¿Qué significa esto? A veces tomamos la iniciativa de actualizar el estado en el navegador antes de esperar la confirmación final del backend. Estas son las actualizaciones optimistas. ¿Cuándo solemos actualizar el estado de manera optimista? Cuando queremos retroalimentación instantánea de la UI, como cuando hacemos likes, comentarios, iniciamos un mensaje, y puedes ver en el código aquí que establecemos el estado antes del try. Y si falla, podemos revertir en cualquier momento en el catch.

Otro impacto en la arquitectura frontend es que las estrategias de caché se vuelven críticas. Hasta ahora tenemos caché en los gestores de estado global, pero ahora es realmente crítico. Es importante, además de la memoria que hemos almacenado en caché hasta ahora en Redux y otras tecnologías. En esta arquitectura, lo almacenamos en caché en el almacenamiento local. De esta manera, reducimos las llamadas HTTP a la API porque, como vimos antes, podríamos encontrarnos con situaciones de arranque en frío, lo que significa que el backend podría retrasarse en responder al caché. Todavía almacenamos en caché los datos, pero no queremos asegurarnos de que se vuelvan obsoletos y desactualizados.

Por eso estamos usando hoy en día herramientas inteligentes como Tanks.Query y SWR que nos ayudan a configurar de manera inteligente cada cuánto queremos que los datos de caché sean revalidados. Y mientras esta revalidación tiene lugar, queremos mostrar al usuario aún los datos antiguos. Queremos asegurarnos generalmente en toda la arquitectura de que el usuario no perciba ninguna perturbación de la arquitectura subyacente. También podemos precargar los datos, por ejemplo, al pasar el ratón sobre los enlaces de navegación. Estas tecnologías nos permitieron hacer esto con una configuración bastante simple.

Podemos especificar por cuánto tiempo el tiempo de inactividad de los datos puede volverse inactivo y luego actualizarse. Una tercera implicación es que el manejo de conexiones, que es la llamada HTTP, la llamada real que hacemos, se vuelve y debería volverse resiliente. Hay una mayor probabilidad en esta arquitectura de que la llamada HTTP falle debido a solicitudes de red, debido al arranque en frío que mencionamos anteriormente. Es por eso que tenemos la opción de reintentar las llamadas a la API. Gracias a esa consulta, por ejemplo, nos permite definir el número de reintentos así como el retraso entre los reintentos. Y si algo falla después de los reintentos, aún podemos visualizar al usuario lo que sucederá si falla. Así que siempre recuerda visualizar al usuario lo que está sucediendo.

Estos reintentos son adecuados principalmente solo para llamadas GET y debemos evitar hacer reintentos en mutaciones. Vimos anteriormente que ahora no tenemos una ruta de API masiva, sino que tenemos funciones serverless más pequeñas. Eso significa que nuestro frontend, nuestros componentes de UI son más pequeños y están hablando de manera granular con las respectivas funciones serverless. Eso significa que cada componente puede fallar o cargarse en un momento diferente. Es por eso que los estados de carga se vuelven más granulares en esta arquitectura. Tenemos diferentes estados de carga para un componente de dashboard o para un componente de item. Sin embargo, no siempre deberíamos mostrar un spinner porque a veces tenemos estos umbrales de tres milisegundos por debajo de los cuales es un tiempo de carga exitoso.

Así que podemos especificar de manera granular cuándo mostramos cargadores, por ejemplo, solo después de que pase el tiempo de espera y podemos obtener actualizaciones silenciosamente y mantener la UI receptiva. Por último, los errores se vuelven bastante críticos en esta arquitectura porque en cualquier momento cualquier componente puede fallar. Por lo tanto, necesita ser manejado por separado e individualmente. Tenemos errores más frecuentes e impredecibles en estas arquitecturas. Es por eso que, comparado con las arquitecturas tradicionales, usamos un manejo de errores granular no solo a nivel de raíz y nivel de características, sino también a nivel de componente. Mostramos una UI de respaldo dirigida para aislar fallos y mantener la aplicación utilizable.