React es un framework full-stack (o se está convirtiendo en uno)
(robinwieruch.de)- React, al añadir Server Components y Server Actions, está evolucionando hacia un framework full-stack
La guerra de frameworks comenzó en 2010
- La guerra de frameworks que comenzó en 2010 con Backbone, Knockout y Ember fue seguida rápidamente por Angular y React, y nadie podía predecir su resultado
- Durante mucho tiempo dominaron las aplicaciones JavaScript con renderizado del lado del cliente (CSR)
- A estas aplicaciones también se les conoce como aplicaciones de una sola página (SPA) y por lo general estaban compuestas por un archivo HTML pequeño y un archivo JavaScript grande
- Así era antes de que se introdujera la división de código
La separación entre frontend y backend
- Durante este período, el desarrollo frontend estuvo dominado por diversos frameworks y librerías de JavaScript
- El backend por lo general no estaba atado a un lenguaje específico, y REST se convirtió en el estándar para la comunicación por API
- Como desarrollador web freelance, trabajé principalmente con backends en .NET, Java, Python y PHP
- Solo veía TypeScript/JavaScript en el backend en proyectos greenfield o en proyectos pequeños donde podía controlar el backend
- Pero esto podría cambiar con el auge de React full-stack
- Es interesante que la percepción de los desarrolladores sobre el período entre 2010 y 2020 varíe según cuándo comenzaron su carrera
- Los desarrolladores que empezaron antes de 2010 venían de entornos con renderizado del lado del servidor (SSR) y parecen sentirse más cómodos con el reciente regreso a tecnologías del lado del servidor
- En cambio, muchos otros trabajaron casi una década únicamente con aplicaciones con renderizado del lado del cliente (CSR) y APIs REST
- Ahora no saben bien cómo recibir este nuevo mundo de React full-stack
TypeScript aparece como estándar de la industria
- En los últimos años, TypeScript ha surgido como estándar de la industria
- TypeScript ofrece a los desarrolladores frontend un lenguaje de programación tipado y potente
- A medida que los desarrolladores adoptaron TypeScript, llegaron a un punto sin retorno
- Es interesante cómo un pequeño cambio en el código puede tener un gran impacto en las personas y en toda la industria
Las dificultades de TypeScript y REST
- El impacto de TypeScript sobre REST ha estado lleno de soluciones improvisadas
- OpenAPI (antes Swagger) existía para documentar APIs REST, pero ahora se usa principalmente para generar interfaces de API tipadas
- Aunque en una arquitectura cliente-servidor es posible crear interfaces tipadas perfectas, muchos proyectos fracasan al implementarlas bien desde el inicio
-
Nota personal: "Puede que haya desarrolladores que hayan tenido una buena experiencia con arquitecturas basadas en OpenAPI, pero lamentablemente ese no ha sido mi caso"
TypeScript cambió el ambiente
- Es bastante interesante ver cómo TypeScript cambió el ambiente aquí
- Por un lado, una SPA sin tipos que usaba REST (con OpenAPI para documentación) parecía "aceptable"
- Pero cuando TypeScript se volvió el estándar y empezó a verse como la norma, las interfaces tipadas generadas empezaron a resultar desagradables de manejar, porque los equipos frontend ya estaban acostumbrados a un estándar más alto en su base de código
- Las desventajas de las interfaces tipadas generadas son claras:
- Siempre incluyen una etapa de generación
- La salida generada es compleja
- Dependiendo de la configuración inicial, el código generado no siempre es correcto
La llegada de RPC y tRPC
- RPC no es un concepto nuevo, pero ganó popularidad en el ecosistema React gracias a tRPC
- Según mi experiencia como desarrollador en solitario durante 6 meses en una aplicación de 80 mil líneas de código, llamar funciones en el backend para leer y escribir datos fue casi una revelación
- Nunca me había sentido más productivo que con ambos lados del stack usando TypeScript
- Personalmente, solo me había sentido igual de productivo hace algunos años con una arquitectura GraphQL tipada (generada)
- Durante todo 2023 no podía imaginar nada mejor que tRPC
- Poder llamar funciones en el backend para leer y escribir datos se sentía revolucionario
- Pero ¿era eso todo lo que necesitaba? No
La innovación de Server Components y Server Actions
- Para mí, el verdadero gran avance llegó en 2024 con Server Components y Server Actions
- Estos no solo llaman al servidor, sino que cierran la brecha con él al permitir implementar y ejecutar código del otro lado
- Server Components permiten ejecutar componentes de React en el servidor, lo que da acceso directo a fuentes de datos (por ejemplo, bases de datos) antes de devolver la UI en JSX
- Server Actions pueden llamarse para ejecutar funciones, como en una llamada a procedimiento remoto, generando endpoints HTTP API por debajo
- Server Components y Server Actions están transformando a React en un framework full-stack
- Es una etapa emocionante de transición del frontend hacia un entorno full-stack
El soporte de React para Server Components y Server Actions
- React en sí solo proporciona los elementos base y la especificación para Server Components y Server Actions
- Los meta-frameworks construidos sobre React pueden cerrar esa brecha con bundlers que interpretan directivas entre cliente y servidor
- Next.js está liderando la implementación de Server Components y Server Actions
- Next.js antes ya ofrecía soporte para renderizado del lado del servidor (SSR), pero ahora, a través de Server Components y Server Actions, los desarrolladores pueden acceder a recursos del lado del servidor como bases de datos y colas de mensajes
El comienzo del desarrollo full-stack
- El desarrollo full-stack con React apenas está comenzando
- A medida que los desarrolladores empiecen a acceder directamente a bases de datos mediante Server Components y Server Actions, habrá un proceso de domesticar la complejidad que va más allá de aplicaciones CRUD simples
- Con una formación rigurosa, los desarrolladores frontend pronto dominarán la implementación de arquitecturas backend usando capas, patrones de diseño y buenas prácticas
- Porque, siendo sinceros, nadie quiere ver llamadas a funciones de ORM dentro de componentes React
Expectativa ante el cambio de paradigma
- Estoy muy entusiasmado con este cambio de paradigma
- Se viene una nueva era en la que los desarrolladores de React implementarán funcionalidades verticales desde la UI hasta la base de datos
8 comentarios
Ya hacía todo el full-stack, ¿no?
Si consideras la compatibilidad con otros lenguajes, como en el desarrollo de apps, no creo que tRPC sea una muy buena opción. 😅
Yo pienso que GraphQL es lo mejor.
Creo que las server actions de Next.js tienen el problema de exponer públicamente endpoints de API aleatorios que el desarrollador no puede controlar, y me parece que es una parte muy vulnerable.
¿Podrías decirme a cuál vulnerabilidad te referías? Cuando busco, me aparece una vulnerabilidad SSRF, pero no estoy seguro de si es esa. Justo estoy estudiando Next.js, así que me dio curiosidad y por eso te pregunto.
¿Cuál era, para empezar, la intención de quienes impulsaban las SPA? Sin duda es mucho mejor que en la época en que se manipulaba el DOM con jquery, pero parece que los conceptos necesarios para el diseño y desarrollo de backend y frontend no desaparecen, sino que solo cambian de lugar. Incluso el routing se pasó del servidor al cliente, y ahora, por la moda del server-side rendering, se está intentando llevar de nuevo al servidor.
También me pregunto si dentro de 3 años en verdad seguirán enseñando React estilo SPA en academias o cursos de programación.
¿No era que la mayor ventaja era lo fluido de la navegación entre páginas? (en ese entonces)
El final del artículo original termina promocionando el curso de formación en desarrollo web full stack The Road to Next, que el autor planea abrir próximamente ^^;