Desarrollo
7 mar 2024
El 26 de octubre de 2022, durante la Next.js Conf, Vercel presentó Next.js 13, introduciendo un montón de nuevas características y un cambio de paradigma completo para crear aplicaciones de Next.js.
Los Componentes del Servidor de React (RSC) han sido conocidos durante algún tiempo, pero aún no se habían implementado en un meta-framework de React. Ahora que Next.js los añade, el mundo de las aplicaciones de React renderizadas en el servidor estaba a punto de cambiar.
La promesa de los Componentes del Servidor de React
Descritos por Vercel como una herramienta para escribir UIs renderizadas o posiblemente en caché en el servidor, los RSC prometían integración directa con bases de datos y capacidades específicas del servidor, en un cambio respecto a los modelos típicos de React y SSR.
Esta característica apareció inicialmente como un cambio radical, prometiendo una obtención de datos y una enrutación más simples, gracias a los componentes de servidor asíncronos y el soporte adicional para diseños anidados.
Después de experimentar con ello durante aproximadamente seis meses en otros proyectos, llegué a la conclusión de que, aunque un poco áspero en los bordes, era de hecho un cambio de juego y algo que debía adoptarse en los proyectos de Next.js de ahora en adelante.
Un nuevo paradigma: Acciones del Servidor
Vercel no se detuvo en añadir Componentes del Servidor. Poco después del lanzamiento inicial de Next.js 13, introdujeron "Acciones del Servidor." Las Acciones del Servidor permiten la llamada a funciones del lado del servidor sin rutas de API, reduciendo la cantidad de formalidades requeridas para añadir una nueva mutación o evento a su aplicación.
Apostando por nueva tecnología
Tras el lanzamiento tanto de las Acciones del Servidor como de los Componentes del Servidor, nosotros en Documenso emprendimos una reescritura de la aplicación. Habíamos acumulado un poco de deuda técnica desde el MVP inicial, que era mejor eliminar a medida que también mejorábamos el diseño con la ayuda de nuestro nuevo diseñador.
Habiendo tenido mucho éxito con los Componentes del Servidor en otros proyectos, opté por apostar todo en los Componentes del Servidor y las Acciones del Servidor para la nueva versión de la aplicación. Estaba emocionado por ver cuánto más simple y eficiente sería la aplicación con estas nuevas tecnologías.
Después de nuestro relanzamiento, nos sentimos bastante felices con nuestras elecciones de acciones del servidor, que incluso nos permitieron combinar cierta lógica del lado del cliente y del servidor en un solo componente sin necesidad de mucho esfuerzo de nuestra parte.
Navegando desafíos con las Acciones del Servidor
Si bien inicialmente tuvimos éxito, pronto nos encontramos con problemas con las Acciones del Servidor, particularmente al monitorear la aplicación. Desafortunadamente, las acciones del servidor hacen que sea mucho más difícil monitorear las solicitudes de red e identificar acciones del servidor fallidas, ya que utilizan la ruta en la que se encuentran actualmente.
A pesar de este problema, las cosas eran manejables; sin embargo, surgió un problema crítico cuando el uso de acciones del servidor causó corrupción en el paquete, resultando en una inserción de espera de nivel superior que haría que las compilaciones y las pruebas fallaran.
Este último problema fue un motivo decisivo ya que destacó cuánta magia estábamos dependiendo de las acciones del servidor. Me gusta evitar añadir más magia cuando es posible, ya que, con los empaquetadores y los meta-frameworks, ya estamos delegando mucho trabajo pesado y obteniendo mucha magia a cambio.
Yendo a fondo con tRPC
Mi solución rápida y final a los problemas que enfrentábamos fue abrazar completamente tRPC, que ya utilizábamos en otras áreas de la aplicación. La migración tomó menos de un día y resolvió todos nuestros problemas mientras añadía mucha más visibilidad a las acciones fallidas, ya que ahora tenían una ruta de API dedicada.
Para aquellos que no están familiarizados con tRPC, es un marco para construir APIs seguras en tipos de extremo a extremo con TypeScript y Next.js. Es una biblioteca increíble que te permite llamar de manera segura a tu API definida dentro del cliente, causando errores en tiempo de construcción cuando las cosas inevitablemente se desvían.
He sido un gran fan de tRPC durante un tiempo, por lo que la decisión de dejar de lado las acciones del servidor y en su lugar utilizar más tRPC fue fácil para mí.
Lecciones aprendidas y el futuro
Si bien creo que las acciones del servidor son una gran idea, y estoy seguro de que se mejorarán en el futuro, he reaprendido la lección de que es mejor evitar la magia cuando es posible.
Esto no significa que no consideremos mover ciertas cosas de nuevo a las acciones del servidor en el futuro. Pero por ahora, esperaremos y observaremos cómo otros las utilizan y cómo evolucionan.