DX vs. UX: La falsa dicotomía de RSC

Mi nombre es Amy Dutton, como dijo Scott, y soy Ingeniera de Diseño Senior en G2I. Y hoy vamos a hablar sobre uno de los temas más debatidos en el ecosistema de React. Es una de mis cosas favoritas para hablar. Y eso son los componentes de servidor de React. Específicamente, por qué la conversación de la industria sobre RSC sigue cambiando.

Así que déjame contarte un poco sobre de dónde vengo. Durante los últimos dos años y medio, he trabajado en el equipo central de Redwood JS como una de las principales mantenedoras. Y dado que trabajé en un meta framework a tiempo completo, me propuse conocer lo que todos los demás frameworks estaban haciendo. Pensé que si iba a ir a conferencias como esta y decir, Redwood es genial, necesitaba saber por qué pensaba que Redwood era genial y cómo se comparaba con todos los demás frameworks.

En última instancia, todos estamos tratando de resolver los mismos problemas. Y creo que la marea creciente levanta todos los barcos. Así que quería poder explicar específicamente qué hacía diferente a Redwood y por qué podrías optar por él sobre otro framework. Así que en 2022, decidimos que íbamos a apostar todo por los componentes de servidor de React. Ahora, esto fue un gran problema. Si sabes algo sobre Redwood, sabes que originalmente se construyó sobre GraphQL.

Sorprendentemente, a muchos de ustedes no les gusta GraphQL. Esa fue una crítica que escuchamos a menudo. Y así, escuchándolos a ustedes, decidimos apostar todo por los componentes de servidor de React. Así que los ingenieros de mi equipo pasaron la mayor parte de dos años trabajando diligentemente. Entonces, ¿por qué fue tan difícil? Bueno, hay varios factores en juego. Primero, el código del framework no es lo mismo que el código a nivel de aplicación.

Los frameworks existen y resuelven un conjunto de problemas realmente difíciles para que el resto de nosotros no tengamos que hacerlo. Cuando se trata de implementar componentes de servidor de React, no es solo un interruptor que puedes encender o apagar. No puedes simplemente actualizar React. Y ahora mágicamente tienes componentes de servidor de React en tu proyecto. Desafortunadamente, es un poco más complicado que eso. Y así, una vez que tienes componentes de servidor de React, también debes tener renderizado del lado del servidor para asegurarte de que todo se renderice y se envíe correctamente desde el servidor. Y luego también debes pensar en la hidratación, el almacenamiento en caché y las acciones y funciones del servidor.

Así que React podría estar bien documentado, pero todas las piezas que debes configurar en el backend para que esta tecnología funcione no están documentadas. O al menos no lo estaban en 2022. Pero no es solo React. Así que con Redwood usamos Vite. Next.js para contexto usa TurboPack. Así que no es como si pudiéramos simplemente copiar y pegar las piezas y partes que necesitábamos de Vite tampoco estaban documentadas. Y así realmente estábamos resolviendo problemas que nunca se habían resuelto antes.

Permíteme añadir solo unas pocas capas más. Redwood.js se inició en 2020. Y uno de sus atractivos era que teníamos soporte de primera clase para Storybook, Prisma y Jest. Y así hicimos nuestro mejor esfuerzo para mantener todas esas integraciones. Y así puedes imaginar que fue difícil lograr esa compatibilidad hacia atrás. Luego, otra capa en 2024, hace casi un año exactamente, Tom, quien es el propietario original, entregó todo en el proyecto a Peter Pistorius. Y una de las cosas interesantes sobre Peter es que vive en Sudáfrica. Así que muchos de los problemas que está tratando de resolver en términos de rendimiento y entrega son muy diferentes de muchos de los problemas que estamos tratando de resolver viviendo en los Estados Unidos.

Así que Peter decidió empezar de nuevo por completo. Así que comenzó con React server components desde el principio y se volcó completamente en los servicios de Cloudflare. De hecho, en una conferencia de React el mes pasado, anunciaron la versión 1. Así que hasta que comencé a construir sobre la nueva versión de Redwood llamada Redwood SDK, nunca había experimentado realmente los React server components fuera de Next.js. Uno de mis proyectos en Redwood fue ayudar a escribir la documentación. No me di cuenta hasta que comencé a escribir la documentación de que muchas de las características que pensaba que eran específicas de Next.js eran en realidad características de React. Y toda esta experiencia me dio una comprensión y apreciación completamente diferente por los problemas que los React server components resuelven.

Por un lado, tenemos la experiencia del desarrollador. Y por otro lado, tenemos la experiencia del usuario. Y parece que estamos pidiendo a la gente que haga una elección. Pero yo argumentaría que eso es una falsa dicotomía. Entonces, ¿qué es una dicotomía? Es una palabra un poco elegante y extraña. Bueno, dicotomía es una división o contraste entre dos cosas que se representan como opuestas o completamente diferentes. Realmente lo que eso significa es que tienes una elección falsa. Así que en nuestro caso, con los React server components, no estamos realmente eligiendo entre la experiencia del usuario y la experiencia del desarrollador. Esa es una elección falsa. Y enmarcarlo de esa manera pierde el punto.

No estoy diciendo que no haya compensaciones. Siempre hay compensaciones. Con cada herramienta, cada patrón, cada cambio arquitectónico vienen con ellas. Lo que estoy diciendo es que con los React server components, estamos hablando de usar las compensaciones incorrectas. Hemos estado enmarcando la conversación de una manera que hace que los desarrolladores sientan que están eligiendo bandos, cuando en realidad, la mayoría de los equipos solo están tratando de construir buenos productos y elegir la herramienta adecuada para el trabajo adecuado. Y eso me lleva a ustedes, porque la mayoría de ustedes no están manteniendo un framework. Están construyendo características. Están entregando a los clientes. Están luchando contra los plazos. Están lidiando con código heredado.

Y estás tratando de averiguar, ¿es RSE algo de lo que necesitas preocuparte ahora mismo, o es algo que puedes ignorar de manera segura por otro año? Para responder eso honestamente, ampliemos un poco desde mi experiencia dentro del framework y veamos lo que realmente está sucediendo en todo el ecosistema más amplio de React.

Así que los React server components realmente se sitúan en este espacio interesante. Son poderosos. Resuelven problemas arquitectónicos reales. Simplifican las dependencias de datos. Reducen JavaScript. Mejoran el rendimiento de maneras que hemos estado tratando de lograr durante años. Entonces, si RSE es tan poderoso, ¿por qué la comunidad ha tenido dificultades para adoptarlo? ¿Y por qué provoca tantas conversaciones acaloradas?

No es porque RSE sea malo. No es porque la experiencia del desarrollador sea terrible. Y no es porque el modelo mental sea demasiado difícil. Es porque RSE es una de las únicas características de los frameworks de React en una década que no se lanzó a través de React. En realidad, se lanzó a través de un framework. Piénsalo. Esto es algo inusual. La mayoría de las características de React aterrizan dentro del proyecto React, el paquete. Obtienes la documentación. Obtienes ejemplos. Obtienes orientación agnóstica del ecosistema. Eso no sucedió con RSE.

En cambio, realmente llegó dentro de Next.js. Fue apoyado por Next.js Router, Next.js Bundler, Next.js Runtime. No por exclusión, sino porque RSE requería toda una pila de infraestructura que solo un framework adoptó temprano. Así que, ya sea que RSE se sintiera emocionante o intimidante, no tenía nada que ver con React y todo que ver con dónde realmente lo experimentaste.

Así que si trabajaste en Next.js, RSE se sintió como un siguiente paso natural. Si no lo hiciste, entonces RSE se sintió inaccesible y algo de lo que podías leer pero no realmente probar. Y así, esa asimetría ha creado algo de confusión. RSE no era confuso, pero el camino del ecosistema hacia él era muy estrecho. La gente no estaba debatiendo los React server components como tecnología. Estaban debatiendo los requisitos del sistema de construcción, las suposiciones de enrutamiento, los tiempos de ejecución del servidor, las convenciones del framework, los valores predeterminados de caché y el costo percibido de adoptar todo eso.

Confundimos un problema tecnológico con un problema de ecosistema, y por eso la conversación sobre RSE se siente tan cargada. Pero incluso después de separar la tecnología del ecosistema, hay otra capa que dio forma a cómo todos hablamos sobre RSE. Cómo se sintió RSE para los desarrolladores en la práctica. Porque en el momento en que pones RSE en flujos de trabajo reales, ya sea dentro de Next.js u otro entorno, la conversación cambió de lo que es RSE a cómo realmente se siente. Y de ahí es de donde vino toda esa narrativa de DX versus UX. Así que hablemos de eso. Los React server components hacen algo único. Pide pensar de manera diferente sobre dónde realmente se ejecuta tu código.

La mayoría de nosotros crecimos con la idea de que todo se ejecuta en el navegador. Con RSE, eso cambia. Algunos componentes se ejecutan en el servidor, algunos en el cliente, algunos en ambos, y todos colaboran. Este es un cambio de modelo mental, pero no es malo. Es simplemente diferente, y la diferencia se siente más agudamente cuando realmente estás desarrollando. Y aquí es donde esa percepción se distorsiona.

Los beneficios de experiencia de usuario de RSE, cosas como mejor rendimiento, menos JavaScript, carga inicial más rápida. Todos son reales, pero son en gran medida invisibles durante el desarrollo. Realmente no siento ese mejor rendimiento cuando estoy en mi computadora local. No los sientes en tu editor. Lo que sí sientes son las diferencias del día a día. Estás aprendiendo los límites del servidor y del cliente. Estás trabajando con directivas use server, use client, ajustando cómo funciona la obtención de datos, entendiendo la capa de caché, adaptándote al streaming y renderizado parcial.

Estas son todas tangibles. Estas son las cosas que notas cuando estás desarrollando, y esto aparece de inmediato. Así que nuestras conversaciones de DX estaban ocurriendo a través del lente de un solo framework, no del lente en sí mismo. No es que RSE perjudicara DX. La verdadera división, esta de la que estamos hablando, esta es la que realmente importa, es que RSE como una capacidad de React frente a RSE como una característica específica del framework. Todo lo demás fluye a partir de esta distinción.

Así que volvamos y hablemos sobre cuál fue realmente la promesa original de RSE. Así que la propuesta era bastante simple. Vamos a mover el trabajo al servidor. El servidor es mejor y más rápido en el procesamiento. Vamos a reducir la hidratación. Vamos a transmitir la UI. Vamos a evitar cascadas de datos. Vamos a simplificar el estado del lado del cliente, y vamos a enviar menos JavaScript. Y la mejor parte es que no teníamos que aprender algo nuevo. No tenías que hacerlo. Todo era React. Simplemente estás usando componentes. Como que obtienes todo esto gratis.

Ese era como el sueño. Pero el sueño no siempre fue tan simple como la implementación, porque bajo el capó, RSE no es solo una característica de React. Es todo un ecosistema de herramientas trabajando juntas. Para que RSE realmente funcione, necesitas un runtime de servidor, un enrutador que entienda los límites del servidor, un empaquetador que pueda clasificar componentes, un compilador, una canalización de transmisión, un protocolo de serialización. Y durante mucho tiempo, solo Next.js tenía toda esta infraestructura en su lugar. Creo que otros lo querían, pero RSE requiere una coordinación profunda entre React, el enrutador, el runtime y el sistema de construcción.

Así que por necesidad, RSE realmente solo vivía en un framework, si no estabas en ese ecosistema. Si estabas en ese ecosistema, RSE se sentía normal. Si no lo estabas, se sentía fuera de alcance. Así que este cuello de botella dio forma a la adopción, la percepción e incluso las narrativas sobre la experiencia del desarrollador porque el ecosistema aún no había crecido a su alrededor. Así que cuando eliminas toda esa historia del ecosistema y la historia de la percepción, te queda una pregunta que cada equipo eventualmente hace. ¿Qué hace realmente difícil adoptar RSE? Así que durante casi una década, las aplicaciones de React crecieron alrededor de una arquitectura particular. Todo vivía en el navegador. El enrutamiento era del lado del cliente. La obtención de datos ocurría después del renderizado.

El estado global manejaba los vacíos. Y la canalización de construcción no necesitaba preocuparse por los límites del servidor. Y funcionaba muy bien para la web en ese momento. Así que cuando React server components entraron en escena, la mayoría de los equipos no estaban respondiendo a RSE en sí. Estaban respondiendo a lo que RNC implicaba.

Así que RSE cambia el centro de gravedad de tu aplicación del navegador de vuelta al servidor. Y cuando ese centro se mueve, todo lo demás tiene que moverse junto con él. Los datos, el enrutamiento, el almacenamiento en caché, las convenciones de archivos, la semántica de renderizado. Puedes ver esto incluso en Next.js, donde básicamente tuvieron que crear un framework dentro de un framework, el enrutador de aplicaciones, para hacer posible RSE.

No hicieron el enrutador de aplicaciones solo para, creo que reorganizaremos los archivos. Lo hicieron porque la antigua arquitectura no estaba construida alrededor de las suposiciones de RSE. Y honestamente, tuvimos que tomar un camino similar en Redwood también. Durante dos años intentamos averiguar cómo adaptar RSE a nuestra arquitectura. Realmente nunca fue diseñado para ello. Seguíamos chocando con paredes. Y en algún momento, nos dimos cuenta de que la forma más fácil de avanzar era simplemente empezar de nuevo.

Para reconstruir el framework con React server components en el centro, en lugar de intentar añadirlo en los bordes. Y eso es lo que significa adoptar RSE. No cambiar una bandera de característica, sino reorganizar una aplicación. O en nuestro caso, un framework alrededor de una fuente de verdad. Así que, RSE funciona mejor cuando tu framework lo adopta completamente.

Los desarrolladores no deberían necesitar pensar en todas estas piezas. Porque los desarrolladores dependen de los pasos que ese framework ha tomado o no. Ahí es, creo, donde los desarrolladores y los equipos se sienten atrapados. Les gusta RSE, lo ven, pero el framework que están usando no necesariamente ha evolucionado aún.

O adoptar RSE significaría una pila completamente diferente a la que ya están invertidos. Así que, las barreras no son realmente sobre React. Son sobre arquitectura, tiempo e impulso. Pero yo argumentaría que la fricción no es un fracaso. Es el efecto secundario natural de cambiar un ecosistema hacia algo fundamentalmente diferente.

Algo fundamentalmente mejor. Así que, esa fricción solo importa si hay algo significativo al otro lado. Entonces, la siguiente pregunta es, una vez que integras RSE en tu stack, ¿qué es lo que realmente desbloquea? La respuesta corta es que RSE hace que las aplicaciones de React se comporten de la manera que siempre deseamos que lo hicieran.

Los server components de React silenciosamente trasladaron la responsabilidad del trabajo pesado de nuevo al servidor. El lugar para el que realmente fue diseñado. De repente, el cliente no necesita hidratar todo. No necesita orquestar tanto estado. No necesita buscar en una docena de lugares diferentes solo para renderizar en la página. La UI se vuelve más ligera. Los paquetes de Java se vuelven más pequeños.

Y tu aplicación comienza a sentirse menos como una aplicación de una sola página luchando contra el navegador. Y más como una aplicación web que funciona dentro del navegador. RSE simplifica el modelo mental de dónde vive el código. Tienes código solo del servidor que permanece en el servidor de manera segura. No tienes que preocuparte por tus claves API. Tienes código del lado del cliente. Es solo para la interacción. Y debido a que ese límite es más explícito, la aplicación naturalmente evita enviar información sensible y lógica innecesaria al navegador.

RSE empuja a los equipos de vuelta hacia los fundamentos de la web. No es que React se esté volviendo más complicado. Es React redescubriendo las fortalezas de la plataforma en la que se ejecuta. Así que, estas recompensas son reales. Y si la recompensa es real, entonces el cambio arquitectónico vale la pena. Y entonces la pregunta se convierte en, ¿cómo llevamos al resto del ecosistema allí? Porque para que RSE alcance su máximo potencial, React no puede hacerlo solo. Y Next.js no puede llevarlo solo.

Lo que ha quedado claro en los últimos dos años es que RSE prospera cuando está rodeado de un ecosistema de frameworks que lo entiende. No solo el qué de la característica, sino el por qué de la arquitectura detrás de ella. Las historias de éxito que hemos visto comparten el mismo patrón. Tratan a RSE no como una optimización adicional, sino como una idea fundamental. Así que, para llegar allí, los frameworks necesitan abrazar RSE a nivel arquitectónico. Necesitan alinear su enrutamiento, sus pipelines de renderizado, sus tiempos de ejecución del servidor y sus sistemas de construcción alrededor del contrato que React espera.

Esto no significa duplicar Next.js. Significa tomar sus propias decisiones sobre cómo RSE encaja en su historia en sus términos con sus fortalezas. Y creo que estamos llegando allí. Esta es una captura de pantalla tomada de un sitio llamado Can I Use RSE Today? Recorre todos los frameworks y te da el estado actual. Así que, el código QR en la parte inferior de la pantalla te llevará directamente a ese sitio. Otros frameworks que no se mencionan aquí, TanStack, Start, hay un ejemplo básico de RSE dentro de su candidato de lanzamiento. Remix, también, ha cambiado todas sus características a React Router 7 donde hay soporte experimental para RSE.

Y mi punto es que cuando los frameworks apoyan bien a RSE, sucede algo bastante notable. Los desarrolladores dejan de pensar en RSE como una característica y comienzan a pensar en ello como simplemente así es como funciona React. La abstracción hace su trabajo, pero los frameworks no pueden ser la única pieza. Tenemos que tener herramientas, documentación, bibliotecas de pruebas, flujos de trabajo de depuración y plataformas de alojamiento. Todos necesitan evolucionar junto a este nuevo modelo. Los desarrolladores necesitan ver ejemplos fuera de un solo framework. Necesitan patrones que funcionen sin importar dónde construyan, y necesitan un vocabulario compartido, no un vocabulario de framework.

Estamos hablando de RSE. También necesitamos algo que no ha existido hasta hace poco. Necesitamos esa variedad de ecosistemas. Necesitamos múltiples frameworks implementando RSEs de diferentes maneras para diferentes tipos de usuarios en diferentes tiempos de ejecución y usando diferentes herramientas de construcción. No para que podamos compararlos, sino para que la comunidad pueda realmente entender qué es RSE independientemente de cualquier implementación única. Y finalmente, esa conversación necesita cambiar. Pasamos dos años hablando de RSE a través del lente de la fricción, pero a medida que los frameworks adoptan RSE de manera nativa, esos bordes se vuelven más claros, las trampas se vuelven más raras, y la DX deja de sentirse experimental.

RSE no necesita un mejor argumento. Necesita una base más amplia, y así cuando esa base esté en su lugar, el debate DX versus UX no solo desaparece. Realmente se vuelve irrelevante porque los desarrolladores no estarán eligiendo entre rendimiento y experiencia. Estarán eligiendo entre frameworks que todos entienden esa misma idea central, que React puede ser rápido, expresivo, consciente del servidor, inteligente en el cliente, todo al mismo tiempo. Y ese es el futuro hacia el que RSE se está moviendo, y es uno que finalmente estamos comenzando a ver tomar forma. Así que eso realmente nos lleva de vuelta al principio. Así que después de mirar la historia, la percepción, la arquitectura y la realidad de RSE, aquí está la verdadera conclusión. Los componentes del servidor de React nunca se trataron de elegir entre la experiencia del desarrollador y la experiencia del usuario.

Nunca se trató de reescribir todo lo que sabes o de estar encerrado en un solo framework o de aprender una forma completamente nueva de construir. RSE siempre se trata de React, una forma de alinearse más estrechamente con la plataforma, de compartir el trabajo entre el cliente y el servidor sin obligarte a reinventar toda la aplicación, de hacer que la web se sienta rápida nuevamente sin pedirte que revises kilobytes de código de hidratación.

Y a medida que desbloqueamos ese futuro, cuando dejamos de enmarcar DX y UX como objetivos en competencia y comenzamos a tratar RSE como lo que realmente es, es un esfuerzo del ecosistema. Cuanto más el ecosistema adopta RSE, más natural y poderoso se vuelve, no porque RSE cambie, sino porque todo a su alrededor finalmente puede ponerse al día. Estamos llegando allí. Esto está al alcance, y hagámoslo juntos. Gracias.

Una pregunta ahora mismo, que es, ¿cuál es el experimento RSE menos arriesgado que llevarías a cabo en una aplicación React empresarial heredada? Esa es una pregunta un poco capciosa porque depende. Supongo que si es una empresa, estás usando Next.js porque ese es realmente el framework más listo para producción, aunque más han comenzado a adoptarlo. Y entonces, lo que pasa con Next.js y RSE es que puedes ejecutarlo dentro del directorio de páginas y del directorio de la aplicación. Puedes tener ambos dentro de tu aplicación, y así puedes comenzar a mover piezas lentamente a medida que deseas esos beneficios. Y me centraría en las páginas donde deseas los aspectos más del lado del servidor de eso. Así que ya sea manejando la obtención de datos complejos, mutaciones, cosas así, o es algo que deseas para ese SEO, las etiquetas OG, todas esas piezas.

Sí, bien. OK, he pasado mucho tiempo tratando de inclinarme hacia RSE, pero no me ha gustado tener que pensar en dónde se están consultando los datos y cómo gestionar el estado de la aplicación entre el cliente y el servidor.

¿Cómo maneja esto el Redwood SDK? Además, ¿por qué Cloudflare? ¿Por qué Cloudflare?

Entonces, lo que es interesante, veamos, estabas hablando sobre los datos, cómo gestionar entre el cliente y el servidor. Así que creo que parte de esto es una vez que te das cuenta de lo que debería suceder en el cliente frente a lo que debería suceder en el servidor. Si estás obteniendo datos, mi recomendación sería que eso suceda en el servidor. Obtienes los beneficios de seguridad. No tienes que preocuparte por los tokens de API o cosas que se filtren.

Así que Redwood SDK maneja esto, en realidad similar a Next.js, principalmente porque es más una característica de React donde puedes simplemente consultar dentro del código de tu página. También puedes hacer eso dentro del cliente si deseas usar un factor de usuario, pasar algo.

Pero la tercera parte de tu pregunta, ¿por qué Cloudflare? Una de las razones por las que creo que Next ha tenido éxito y lo ha hecho tan bien es porque está muy vinculado a Vercel. Obtienes todos estos beneficios donde tienes una plataforma de alojamiento que está realmente diseñada para hacer que Next.js funcione rápido. Y han construido todo un ecosistema alrededor de eso.

Y así, mientras trabajábamos en Redwood, la primera versión de Redwood, intentamos ser lo más agnósticos posible. Y así teníamos montones y montones de pruebas para asegurarnos de que funcionara en cada servidor, framework y plataforma posible. Y al elegir uno, pudimos avanzar más rápido, pero también pudimos garantizar que ciertas cosas estuvieran disponibles y que ciertas cosas funcionaran.

Y luego Cloudflare tiene tantas cosas listas para usar. No sé si ustedes están al tanto de eso. Deberían ir a hablar con los chicos en el stand de Cloudflare. Pero tienen D1, que es una base de datos integrada, por lo que ni siquiera tienes que preocuparte por unir eso. Obtienes eso. R2, tienes almacenamiento. Listo. Tienes trabajos cron. Listo. Tienes trabajos en segundo plano y programación. Todo eso. Listo. Tienes alojamiento. Listo.

Y así, cuando estás construyendo en tu entorno local, funciona tal como lo haría en el servidor. No tienes que resolver eso. Y así, hace que unir las cosas sea mucho más fácil. Previene la fatiga de decisiones.

No tienes que decidir, ¿qué voy a usar? Está todo ahí y todo disponible. Genial. ¿Cuáles son los principales beneficios de usar Redwood en lugar de Next.js? Sí, así que creo que una de las cosas que desafiaría a la gente a hacer es simplemente probarlo.

Mucho de esto se reduce a la experiencia del desarrollador y lo que más te gusta y cómo te gusta desarrollar.

Así que algunas de las cosas que Redwood ha hecho que son un poco diferentes es que su enrutador es muy diferente. Tienen un enrutador de configuración. Si te gustó React Router 7, probablemente te gustará el enrutador de Redwood. Son muy similares. Han tomado muchos de los mismos patrones, mientras que Next.js es un sistema de enrutamiento basado en archivos. Así que si quieres una nueva página, simplemente creas la página, creas el archivo, y ahí está. Así que es un poco diferente.

En mi opinión, hay algunos beneficios al tener ese sistema de enrutamiento basado en páginas, como el basado en configuración. Puedes cambiar rutas sin tener que mover tus archivos. Pero una de las diferencias clave, diría yo, que la mayoría de la gente aprecia con el sistema de Redwood es cómo manejan el middleware. Así que si miras esa configuración del enrutador, y por eso lo mencioné, es que es esencialmente un arreglo de parámetros que estás pasando para decir si vas a esta ruta, entrega este componente. Pero manejan middleware e interruptores.

Son más o menos lo mismo. El middleware se ejecuta antes de cada página. Los interruptores puedes decir, solo quiero que se ejecute en ciertas páginas. Pero obtienes una imagen clara de cuándo se está ejecutando el middleware y cuándo se están ejecutando estos interruptores y luego cuándo está cargando la página. Mientras que con Next, eso se hace a través de un archivo de middleware.

Y así, a veces, al menos cuando he construido proyectos de Next.js, a veces me he olvidado del middleware. Estoy como, ¿por qué esto no está funcionando? Y es porque está oculto en este archivo lateral. Están como, oh sí, existe aquí. Gracias por el muy genial encuadre de RSC. Una cosa que extraño de las APIs ahora que estoy empezando a usar RSC y Next.js es ver cargas útiles JSON de solicitud-respuesta limpias en la pestaña de Redes de Chrome DevTools. ¿Algún consejo sobre herramientas de depuración de RSC?

Sí, no tengo nada específico, pero diré que el truco ahí cuando estás tratando de depurar es como, ¿de dónde viene esto? Vas a registrar algo y no está en la consola del navegador. ¿Dónde está? Está en la terminal. Es porque se ejecutó en la terminal y no en el navegador. Pero una cosa que diría, si te gusta la carga útil JSON de solicitud-respuesta limpia, mira Redwood porque han tratado de dejar muy claro que esta es la solicitud que estamos poniendo y esta es la respuesta. Así que puedes hacer que responda con un componente de React.

Puedes tener simplemente una respuesta HTTP normal. Puedes simplemente poner eso de nuevo en el navegador. Puedes enviar texto. Y así, lo hace muy claro y fácil para los principiantes entender esta es la solicitud y esta es la respuesta que vas a obtener de vuelta. Genial. Bueno, muchas gracias, Amy. Gracias.