RSCs En Producción: 1 Año Después

Hola, soy Theo. Probablemente me conozcas de YouTube, pero lo creas o no, también soy ingeniero. Sí, envío código. De hecho, lancé un proyecto realmente grande alrededor de esta época el año pasado. Puede que hayas oído hablar de él. Se llama UploadThing. Es una cosa para subir archivos. Esto es. Así es como se ve. Es, en mi opinión, la mejor manera de agregar carga de archivos a tu proyecto, pero eso no es de lo que estamos aquí para hablar hoy, tanto como me encantaría porque necesitamos profundizar en los componentes de servidor. Específicamente, ¿cómo ha sido enviar componentes de servidor en producción durante un poco más de un año ahora? Sí, nos lanzamos de lleno con AppRouter. Incluso nos lanzamos de lleno con Edge en este proyecto. Hay muchas cosas geniales que aprendimos, muchas cosas geniales que funcionaron muy bien, y por supuesto, un montón que funcionaron terriblemente. Quiero entrar en detalle sobre todas estas porque normalmente cuando haría esto en un video, nadie lo vería. Pero como los tengo a todos ustedes retenidos como rehenes en esta conferencia, podemos hablar de estas cosas con mucha más profundidad de lo que normalmente puedo. ¿No es emocionante? Un gran reconocimiento a React Summit por permitirme hacer esto, grabar el video, enviarlo con anticipación porque esto es un gran alivio de estrés. Ojalá pudiera haber estado allí en persona, pero con suerte, si todo va bien, el próximo año.

De todos modos, vamos a sumergirnos. Tengo toda una lista de lo bueno, lo malo y lo feo y quiero repasar todas estas partes.

Bien, lo primero es lo primero, ¿qué es esta aplicación y cómo se despliega? Bueno, UploadThing es una aplicación bastante tradicional de Next.js usando AppRouter. Podemos echar un vistazo en nuestra cuenta de Vercel PENG, ir a UploadThing y no verás nada demasiado emocionante aquí. Estábamos usando FileThing como nuestro nombre original, pero UploadThing es con lo que terminamos quedándonos. Está conectado a un repositorio de GitHub. Se despliega automáticamente. El repositorio de GitHub es donde las cosas empiezan a ponerse un poco más interesantes, porque el repositorio de GitHub es un monorepo.

Originalmente, teníamos los paquetes para UploadThing así como la infraestructura todo en un solo repositorio. Los separamos porque queríamos hacer open source todos los paquetes. Así que si tienes curiosidad sobre cómo funcionan los paquetes, no estamos hablando mucho de eso aquí. Todo eso es open source. Puedes sentirte libre de investigarlo. Así es como funciona nuestra infraestructura y hemos aprendido mucho al hacer esto y no puedo esperar para mostrar algunas de las cosas geniales que hemos aprendido.

Pero como dije, bastante tradicional, conectas esto a Vercel y se despliega automáticamente una vez que le dices en cuál de estos paquetes está el código, que está en infrared slash UploadThing server. Mira aquí, hemos estado probando otros lugares para desplegar más y más de nuestra infraestructura. Definitivamente hablaremos de eso a medida que avancemos porque aunque la mayoría de nuestras cosas todavía están completamente en Vercel, estamos usando otras piezas para otras cosas como gestionar nuestros buckets S3, gestionar nuestra capa de redirección sobre esos. Eso lo hemos estado haciendo por separado. Primero, vale la pena reconocer que esto no solo va a ser sobre Server Components porque también estamos usando AppRouter, que para ser franco, es la única forma real de usar Server Components de manera segura en producción ahora mismo. Así que sí, estamos en AppRouter más Server Components. Vamos a tener que hablar mucho sobre AppRouter para que esta sea una conversación justa. Si no estás ya familiarizado. Next.js reemplazó su enrutador, que era el enrutador de páginas, donde solo tenías archivos page.tsx aleatorios.

Bueno, realmente no eran page.tsx. Cualquiera que fuera el nombre del archivo, eso se convertía en la URL. Así que si tenías Theo.tsx, lo que exportaras allí se convertiría en page slash Theo. Ahora, estamos en AppRouter, que es una forma diferente de hacer las cosas. No quiero profundizar demasiado en cómo solían funcionar las cosas. Así que si necesitas aprender sobre eso, tengo montones de videos en mi canal de YouTube sobre cómo funcionaba el enrutador de páginas, cómo se comparaba con esto. Estoy esperando algún nivel de conocimiento de Next.js a medida que avanzamos.

Esto es más para mostrar lo que hemos aprendido, no solo cómo funcionan realmente estas cosas. Así que aquí tenemos la página de inicio, page.tsx. Nota que el runtime es edge. Hablaremos de eso más tarde. No te preocupes. Pero todo esto es material bastante tradicional.

Tenemos nuestro home wrapper, que es un componente envoltorio que tiene un montón de contenido que queremos en la página de inicio y en páginas similares. Tenemos nuestros diseños flex y todo eso. Tenemos el hero. Tenemos el callout, que es la pequeña noticia en la página de inicio, todo material tradicional. Nada demasiado interesante aquí, excepto por el hecho de que nada de este código se envía en el JS, lo cual es realmente genial que esto solo esté enviando HTML.

Lo que estaba aquí para mostrar es el diseño, porque el diseño es el código que se ejecuta alrededor de cada página en el sitio. Dado que este es el diseño raíz, esto se aplicará en cada subpágina. Así que si quieres que tu subpágina haga algo diferente, necesitas enrutarla por separado de este diseño o encontrar formas de anular estos comportamientos porque esto es lo que envuelve todo. Generalmente, las cosas que pones aquí son cosas como tu proveedor de autenticación, tu componente de vista de página, tu proveedor para tu capa de autenticación, no autenticación, esto es analítica. Ese es mi proveedor post hoc. Tienes el proveedor trpc aquí para el poco de trpc que estamos usando en la aplicación, de lo cual también hablaremos. Tenemos el toaster aquí para gestionar publicaciones cuando haces clic en algo y aparece un pequeño toast. Todas las cosas que quieres en cada página. Esto es como la raíz de la aplicación, lo que rodea todos tus componentes en el app TSX.

Todos hemos tenido eso. Pero esto es solo el diseño raíz. Como mencioné antes, hay capas en esto. Así que si vamos al dashboard, verás que tenemos estas tres secciones. La que nos importa ahora es app ID. Y aquí tenemos un diseño, que es el dash layout, luego monta la navegación lateral, luego monta los hijos. Este diseño se aplica debajo del anterior. Y si una de estas páginas tuviera un diseño propio, ese se aplicaría también. La naturaleza anidada de los diseños y cómo se aplica contra la URL. Esa es la verdadera magia aquí.

Y honestamente, este patrón ha sido genial. Hay bordes como ves aquí. Aunque teníamos estas múltiples cosas bajo slash dashboard, queríamos que dashboard como la ruta fuera diferente de un ID dado dentro de ella. Porque cuando vamos a mi dashboard, queríamos que todas estas diferentes partes se comportaran de manera diferente desde el nivel superior aquí. Queríamos mostrar el selector para que pudieras cambiar organizaciones y cosas con una diferente navegación superior aquí. Queríamos que las cosas dentro fueran diferentes. Queríamos este componente aquí, queríamos otros comportamientos adicionales y demás.

Para hacer eso, tuvimos que tener dos diseños diferentes. Y necesitamos asegurarnos de que este no se aplicara cuando queríamos que este se aplicara. Para hacer eso, tienes que usar la sintaxis especial para extraer cosas de la ruta. Así que los paréntesis son invisibles. Significa que esto es efectivamente si solo hicieras el slash, y luego el que tiene los corchetes, eso es un valor que puedes tomar ahora. Así que si voy a page TSX aquí, puedes ver que tengo app ID como una propiedad que se pasa como un parámetro. Y ahora que tengo esto pasando aquí, puedo usarlo para cosas. En este caso, tengo un enlace para ello. Estoy seguro de que hay muchos otros lugares donde usamos esto más Oh, app outdated SDK es props que app ID.

Y así de fácil es hacer la obtención de datos, lo cual honestamente, podemos entrar ahora en el hecho de que si necesito acceder a algo como una base de datos rápidamente, es tan simple que es hilarante. Así que este código app tiene SDK obsoleto, lo que está haciendo es verificar para ver qué versión del SDK usaste en tu carga de archivo más reciente para ver si está desactualizada. Dado que este es un tutorial antiguo, las cosas que estábamos usando obviamente están desactualizadas. Así que está recomendando que actualicemos a la última versión. Y lo hace ejecutando esta función donde obtenemos la versión del SDK para la app, que es solo una llamada directa a la base de datos, por cierto, luego obtenemos la última versión de upload thing que está verificando desde el registro npm, incluso podríamos almacenar esto en caché de manera bastante trivial para hacer las cosas aún más rápidas.

Y luego si la versión está desactualizada, lo cual sabemos después de comparar estos para asegurarnos de que la nueva versión que tienes está dentro de la más nueva. De lo contrario, devolvemos esta advertencia, incluso tenemos el simple return null aquí, esto es solo tu componente habitual. Pero dado que esto se ejecuta en el servidor, podemos llamar cosas del servidor como esta directamente. Y si esto devuelve null, entonces simplemente no obtienes nada de vuelta en el lado del cliente, no hay penalización aquí en absoluto. Este JavaScript no sobrecarga el cliente, el usuario obtiene esto efectivamente no existe, lo cual es mágico. Es tan genial que podrías escribir teóricamente, código súper complejo aquí que solo se monta si ese componente lo devuelve, y puedes simplemente ejecutar lógica para asegurarte de que no lo haga estos patrones de obtención de datos no se han vuelto obsoletos, todavía se siente mágico cada vez que puedes simplemente await y obtener información de la app, que es solo esta llamada a la base de datos. Es tan genial que en un componente, puedes simplemente await datos.

Y si no tienes lo que quieres, simplemente devuelve null, simplemente hace que todo sea mucho más simple. Y hemos encontrado que esta simplicidad absolutamente escala, no escala en el sentido de que nunca tendrás complejidad de nuevo.

Pero escala en el sentido de que es una ganancia de 10x. Y esa ganancia de 10x permite que las cosas se sientan mucho menos complejas a medida que continúas construyendo sobre ello. Puede que hayas notado que este get app info no es una llamada a la base de datos directamente en nuestro componente, nadie realmente recomienda que hagas eso. Es una demostración realmente agradable para mostrar como una llamada SQL dentro de un componente con el onclick porque muestra lo estrechamente unidas que están estas cosas, pero nadie debería realmente estar haciendo eso.

En su lugar, lo que estamos haciendo aquí es escribir realmente estamos usando drizzle en su mayor parte, pero incluso hacemos un volcado de SQL aquí para ciertas cosas alrededor de los certificados SSL. Todo esto está aquí simplemente porque nos gusta tenerlo centralizado en un solo lugar, hace mucho menos probable que dupliquemos lógica de maneras que no tienen sentido. Y de esta manera, si usamos get app info en 15 lugares, podemos actualizarlo en este único lugar y afectará todo lo demás. Y dado que estamos usando drizzle, que tiene un retorno seguro de tipo, obtendremos inmediatamente una advertencia como si elimino apt aquí, obtenemos inmediatamente un error de tipo, porque algo aquí espera conocer el nivel, no tuve que guardar esto, puedo simplemente no guardar. Así que si elimino esto, no he guardado y estamos obteniendo un error de tipo allí. Es tan genial que desde el backend hasta la interfaz de usuario, tenemos seguridad de tipo completa que nos impide cometer errores tontos. Y eso no desaparece sin importar cuán grande sea tu base de código. Y esta se ha vuelto muy grande con el tiempo. Y podemos tener lógica realmente compleja como bytes, el legible por humanos, bueno, este no es súper complejo, pero entiendes el punto, esta es una utilidad que simplemente se ejecuta en nuestro servidor. Y mientras no lo importes en el cliente, no tendrás que lidiar con ningún potencial o como aumentos en el tamaño del paquete.

Como resultado, creo que eso es increíble. Una cosa más sobre los aumentos en el tamaño del paquete porque hay un par de estos momentos mágicos Oh mierda que suceden una vez que profundizas en los componentes del servidor. Y uno de mis favoritos por mucho, va a parecer tan simple y tonto, pero realmente hizo que estas cosas hicieran clic para mí ver todos estos patrones en esta página, donde tenemos un pequeño patrón elegante para todas las diferentes aplicaciones y un color de fondo diferente. Todos provienen de un archivo. Mira este archivo generate pattern, este archivo es bastante grande. Divulgué todos estos patrones. Y cada uno de estos es una línea para el patrón en sí. Pero son enormes. Este archivo es como megabytes. Te preguntas de dónde vinieron todos esos patrones? hero patterns. Genial. Literalmente los descargamos todos y los pusimos en un archivo porque no queríamos que aparecieran porque se están cargando desde un CDN y luego entrando. Queríamos que estuvieran en el marcado. Así que si miras aquí, verás en el marcado real, tenemos el SVG, tengo que profundizar un poco más para verlo. Pero entiendes la idea aquí. Es el estilo incrustado aquí data image SVG, sí, entiendes la idea.

Lo incrustamos como un elemento de estilo de fondo real. Así que está en el HTML, por lo que no hay aparición repentina. Obviamente no quiero enviar este archivo gigante, aunque la lógica aquí es realmente simple BG pattern FG color opacity, hacemos algunos reemplazos del fill para que sea el nuevo color de primer plano, luego los intercambiamos para que sea válido como un patrón de datos en lugar de solo ser un SVG. Entiendes la idea. Esto fue Mark arreglando algunas cosas tontas hace tiempo, pero el get random es súper simple.

Tenemos la seed, que es tu app ID, y generamos el patrón correcto que queremos usar para ello y lo devolvemos. Este código nunca toca el cliente. Incluso podríamos afirmar eso si realmente quisiéramos poniendo import server only en la parte superior. Y ahora si intentamos importar esto en algún lugar, no deberíamos, obtendremos un error de que este código se está importando en algún lugar que está en el cliente. Eso significa que todo este montón de cosas que tenemos aquí, estos SVGs gigantes, tenemos literalmente más de 100 de ellos, no afecta el rendimiento ni el tamaño del paquete en absoluto.

Esta forma realmente tonta y simple de hacer las cosas es totalmente segura y funciona bien. Ahora, aquí es donde la magia realmente comenzó a hacer clic para mí porque no era tanto que los RSCs son una alternativa a las APIs o simplemente lo que usas en el servidor. Así que los RSCs hacen que muchas de las cosas para las que tuvimos que construir estos patrones locos simplemente desaparezcan. Como piensa en todo el tiempo que hemos pasado haciendo lógica loca de carga de SVG y tratando de empaquetar SVGs de la mejor manera posible para permitir que nuestros usuarios tengan una buena experiencia. ¿Y si no tuviéramos que hacer nada de eso? ¿Y si eso simplemente fuera cómo funcionaba? ¿No sería genial?

Eso es lo que esto ha estado haciendo para mí en muchos lugares diferentes. Una cosa más que me encanta antes de que empecemos a entrar en las cosas dudosas, quiero encontrar un buen ejemplo de mi patrón favorito, suspense. Suspense es increíble porque te permite hacer ciertas cosas sin bloquear las otras cosas. Así que en este caso, suspense evita que el código que gestiona las vistas de página post-hoc, que es nuestro proveedor de analíticas, saludo a post hoc, ha sido genial trabajar con ellos. Y este proveedor de analíticas simplemente no es algo en lo que queramos bloquear la carga de la página porque tiene que cargar JS, tiene que cargar lógica y tiene que hacer algunas cosas.

Si podemos simplemente transmitir ese resultado cuando esté listo sin hacer que tome más tiempo, pero al final hacemos que todo lo demás tome menos, ¿por qué no haríamos eso? Ese es un ejemplo bastante simple, pero también tenemos más complejos donde tenemos cosas como miembros de la organización, que es un componente que tiene que obtener datos de múltiples lugares. ¿No sería agradable no tener que bloquear toda la página en eso? O algo como la página de archivos. Así que esta es la tabla de archivos y la tabla de archivos tiene que obtener una tonelada de datos. Así que la tabla de archivos no tener que bloquear el resto de la carga de la página significa que cuando navegas a ella en el dashboard, se carga inmediatamente. Y si solo quieres obtener algunos datos de tu base de datos, toma un poco más de tiempo que todo lo demás. Pon eso en un componente con un suspense arriba, simplemente se transmite directamente. Suspense ha sido una experiencia realmente agradable en general, y he estado súper contento con ello. Cuando lo combinas con algunas de las habilidades locas que proporcionan los componentes del servidor, como la capacidad de pasar un componente del servidor como una prop a un componente del cliente para que esté anidado así. Esto ha sido muy, muy agradable de trabajar y nos ha permitido simplificar cantidades significativas de nuestra lógica. Dicho todo esto, podrías notar que a pesar del tamaño de esta base de código, no tenemos demasiados límites de suspense.

Eso es porque tendemos a ponerlos en el nivel superior con algo simple y obvio como un layout. Y luego dejamos que las páginas carguen todo de una vez. De lo contrario, si abusas del suspense, terminarás de nuevo en el mismo infierno de cargadores del que hemos estado tratando de salir. Hemos encontrado que poner un buen suspense en el límite de carga más pesado y luego dejar que todo lo demás espere su camino al infierno nos ha permitido tener aplicaciones que se sienten realmente rápidas en general. Y Dios, se sienten rápidas.

Como mostré antes con cosas como el SVG simplemente no cargando. El rendimiento del sitio es increíble, especialmente si estás en entornos de internet extraños y no muy buenos. Recuerdo que estaba en otra conferencia, GraphQL Conf, y alguien estaba hablando sobre cómo las aplicaciones modernas de React y Next.js simplemente no son tan eficientes como incluso algo en Rails o PHP. Y cuando estaba en el avión, estaba tratando de navegar por alguna aplicación Next aleatoria y defectuosa. Spoiler, esa aplicación Next aleatoria y defectuosa era el dashboard de Vercel. Y estaba teniendo un muy mal momento porque cuando estás en el aire con un Wi-Fi realmente irregular con cantidades insanas de latencia, la experiencia no era buena. Y honestamente, estoy de acuerdo. El dashboard de Vercel es uno de los mejores ejemplos de una aplicación Next.js no muy buena de usar. Han estado haciendo progresos desde entonces, pero es complicado.

Dicho esto, te reto a que hagas dos aplicaciones y subas cosas y juegues con ellas cuando estés en el Wi-Fi del avión, porque te prometo que vuela. Estoy en un Wi-Fi realmente bueno ahora mismo y todavía se mueve así de rápido, pero te prometo que lo ralentices. Puedo bajar el ancho de banda si quiero aquí, pero un ancho de banda más bajo no va a representar adecuadamente el caos de lo bien que se siente esto. Su capacidad para manejar la latencia es una de las cosas más geniales. La razón de eso es un montón de pequeñas cosas. No hay una gran cosa. Es el hecho de que puedes simplemente cargar el payload desde el servidor en lugar de tener que navegar, luego cargar el nuevo JS, luego buscar en el servidor para cargar el nuevo JSON, luego renderizar ese nuevo JSON, darte cuenta de que necesitas otras cosas, ir a buscarlas. Es que el número de viajes de ida y vuelta ha disminuido tanto y esa reducción de viajes de ida y vuelta no ha cambiado con el tiempo. Todavía tenemos tres o menos viajes de ida y vuelta para obtener el contenido completo de la página. Eso es una locura. Y eso muestra que la experiencia que los usuarios tienen en esta aplicación es increíble. Sin embargo, tuvimos que hacer algunos compromisos para llegar allí. Y aquí es donde empezamos a entrar en lo malo por un momento. Por mucho que me encanten los componentes del servidor, podrías haber notado algunos lugares a lo largo de la aplicación donde tenemos este pequeño export const runtime equals edge bit. Hay una razón para eso. Cuando te mueves a componentes del servidor inicialmente, todas tus páginas web tienen que pasar por el servidor de React y Next.js.

Para que eso funcione, el usuario ya no recibe una respuesta del CDN. Tienen que obtener la respuesta de tu servidor. Así que si envío una solicitud a un servidor de Next.js, no recibo una respuesta de caché del CDN inmediatamente. Tengo que esperar a que ese servidor se inicie, reconozca mi solicitud, procese la solicitud, genere una respuesta HTML y luego me la envíe finalmente, lo cual simplemente toma mucho más tiempo que acceder a una caché de un CDN.

Dado que esto también estaba en Lambda, estábamos sufriendo inicios en frío todo el tiempo y los inicios en frío, especialmente si estás usando algo complejo de base de datos, como Drizzle no es tan malo, pero Prisma podría añadir segundos, segundos literales, como de 1.0 a 2.0 segundos, 2000 milisegundos a tus inicios en frío. Miserable. No queríamos lidiar con eso porque no queríamos que la página de inicio tardara hasta dos segundos en cargar. Queríamos que la página de inicio fuera instantánea. Como no teníamos el beneficio de algunas cosas nuevas de las que hablaremos en un segundo, fuimos completamente a Edge, y fuimos la primera aplicación en producción desplegando app router y componentes del servidor en edge. Y lo sé porque estaban haciendo muchos cambios para nosotros en el último minuto durante nuestro lanzamiento. Y eso tuvo muchos puntos problemáticos. Tener dos entornos de ejecución en tu aplicación, tengo expectativas completamente diferentes de cómo funciona el mundo resultó en muchas cosas molestas como que no usamos CUID y usamos UUID porque no pude hacer que el paquete CUID 2 funcionara en edge y en normal como Lambda al mismo tiempo. Pero al menos ponerlo en edge, permitió que nuestros tiempos de renderizado inicial fueran más rápidos. Y todavía lo son. Si vas a nuestra página de inicio, todavía no está accediendo a un CDN hasta el día de hoy. Cerraré sesión para mostrar la página de inicio correctamente. Estoy actualizando con comando shift r actualizando. Es simplemente inmediato. Como que realmente no puedes hacer que cargue. Es tan rápido porque puede generar una respuesta en el edge que es súper simple en casi nada de tiempo.

Pero, ¿no sería genial si literalmente no tomara tiempo? ¿Qué pasaría si usando las mismas cosas de suspense que acabo de mostrar, pudiéramos cargar el shell instantáneamente desde un CDN y transmitir el resto? Lo que quería en la forma en que solía describir esto es que quiero simplemente cachar el primer fragmento que se envía a través del stream, poner eso en un CDN, enviarlo inmediatamente y luego enviar el resto más tarde. He estado pidiendo esto durante más de un año, posiblemente incluso dos en este punto. Afortunadamente, Vercell escuchó. Y durante NextConf el año pasado, anunciaron el pre-renderizado parcial, que es literalmente justo esto. Te permite tomar la parte estática que no es diferente para ningún otro usuario. Eso es solo el shell o lo que decidas. Y mientras haya un límite de suspense antes de que haya los primeros datos específicos del usuario, puede simplemente cachar esa capa superior. No lo hemos configurado aquí todavía porque estamos contentos con el rendimiento de nuestra solución actual. Y eso introduce todo tipo de cambios que tendremos que hacer porque construimos muchas cosas personalizadas aquí. Pero en un futuro muy cercano, estoy emocionado de adoptar el pre-renderizado parcial y finalmente poder dejar Edge porque ejecutar tanto Edge como Lambda al mismo tiempo ha sido complicado, especialmente para nosotros, ya que estamos usando el AWS SDK bastante.

Espero que estés entendiendo la idea aquí. No estábamos contentos con el rendimiento de los componentes del servidor sin pre-renderizado parcial y fuimos a Edge por esa razón. Si estás usando estas cosas y esperas una página de inicio rápida, por favor encuentra alguna manera de renderizar la mayor parte de ella estáticamente. Si no lo haces, funcionará mal y te sentirás mal. Esto es efectivamente necesario, ya sea Edge routing y runtime o caché alguna parte de ello a través de CDN. De lo contrario, verás esa temida página blanca en blanco, que no es cómo deberíamos esperar que nuestras aplicaciones funcionen y se comporten.

Hablando de cosas aleatorias que podrías haber notado mientras desplazaba, mencioné brevemente TRPC. Simplemente no estábamos contentos con las acciones del servidor cuando intentamos consumirlas. Tienen muchos efectos secundarios de seguridad extraños e inesperados, en su mayoría han sido abordados desde entonces. Eran molestos de implementar, gestionar, vincular. Se han vuelto mucho más simples en general, pero no queríamos morir en esa colina demasiado temprano. Así que rápidamente eliminamos las cosas que habíamos construido alrededor de las acciones del servidor y volvimos a nuestro amado TRPC, que ha seguido comportándose genial para nosotros. Si no conoces TRPC, es la capa RPC segura para TypeScript. Te permite escribir una función para el backend y luego llamarla prácticamente directamente desde tu frontend. Cosas realmente útiles. Parte del stack T3. Si no has oído hablar de eso, ve a ver mis videos de YouTube. Si tienes curiosidad, TRPC ha seguido siendo increíblemente útil y valioso para nosotros. Todavía nos apoyamos en él para gran parte de nuestro comportamiento de acciones, así como para algunas de nuestras cargas de datos suspensivas para cosas como nuestras tablas de desplazamiento infinito. Ha sido genial trabajar con él. Todavía amo TRPC. Sigue siendo mi opción confiable y de respaldo. No tienes que sentir que pierdes algo como TRPC. Solo porque estás adoptando componentes del servidor, puedes usarlos juntos e intercambiablemente. Totalmente bien. Sin embargo, no todo podría ser reemplazado tan fácilmente.

Una de las cosas más dolorosas con las que hemos estado lidiando es el rendimiento del servidor de desarrollo al usar webpack. Hemos estado un poco atascados en webpack por un tiempo porque hemos estado esperando pacientemente a TRPC, la prometida maravillosa reescritura de webpack y Rust que ha sido contada y predicha en el legado durante no sé cuánto tiempo. TRPC aún no está listo. Se está acercando.

Se está acercando mucho. Con suerte, incluso para la próxima semana, veremos TRPC completamente 100% compat, entre comillas. Listo para ir para cosas de desarrollo. No estamos allí. Y especialmente en personas con máquinas más antiguas, la experiencia de desarrollo para Next fue miserable por un tiempo. El App router simplemente no es particularmente rápido para generar nuevas páginas. Ahora con TRPC, es mucho mejor.

El hecho de que Vercel esperara un poco a TRPC cuando el rendimiento de webpack era tan atroz como era, hubiera sido bueno hacer más correcciones y encontrar formas de mejorarlo en el ínterin. Hicieron un poco, pero no lo suficiente. Y definitivamente hemos estado sufriendo con un rendimiento atroz del servidor de desarrollo hasta el punto en que, si no estamos usando un MacBook más nuevo, ni siquiera un M1 parece que lo logrará ahora mismo. Estoy en mis Macs M2 y aquí se ha sentido mayormente bien. Pero Dios, la única vez que intenté ejecutar ese código en mi máquina con Windows, fue doloroso.

Acabo de darme cuenta de que estoy cerca del tiempo. Así que voy a apresurarme a través de un par de puntos de dolor más. Uno, la hidratación. Siempre apesta. Y hubo un par de lugares donde la hidratación apestaba particularmente fuerte. Ni siquiera aquí, sino específicamente cuando queríamos crear componentes en el paquete que instalas. Cuando usas UploadThing, obtienes un componente de botón de carga que ejecuta el código de UploadThing para cargar un archivo que el usuario está subiendo, pero valida y autentica todo en tu servidor, no en nuestros servidores, en los tuyos. Porque creemos que es muy importante que autentiques a cada usuario antes de que tengan permiso para hacer una carga. También, en tu servidor, eliges qué tipos de contenido están permitidos. ¿Pueden subir imágenes? ¿Qué tamaño de imagen pueden subir? ¿Cuántas pueden subir? Y mostramos todo eso en un pequeño botón debajo porque es realmente agradable ver imágenes de hasta cuatro megabytes debajo de tu botón de carga.

Queríamos que esto no tuviera un estado de carga y apareciera. Cada vez que intentábamos usar cosas como el hook Use que pasaría una promesa, simplemente renderizaría infinitamente y se rompería terriblemente en el cliente. Así que necesitábamos una manera de hacer un componente de cliente que pudiera renderizarse en el servidor y en el cliente y tener el estado incorporado. Así que hicimos lo que llamamos el plugin NextSSR. Y lo que hace esto es literalmente volcar todos los datos de configuración para UploadThing como un blob JSON dentro de una etiqueta de script en tu página para asegurarnos de que tenemos los datos que necesitamos tanto en el servidor como en el cliente para renderizar esto correctamente, para prevenir errores de hidratación. En realidad funciona maravillosamente, pero el hecho de que tuviéramos que idear un truco ingenioso como este para hacerlo funcionar es molesto.

Y ese es el otro mayor punto problemático que he tenido en general. Y esto es más bien un punto problemático, más una súplica. Esto necesita una mejor manera de interconectar el cliente y el servidor. Ha sido increíblemente doloroso. No al construir aplicaciones. Al construir aplicaciones, es literalmente pura magia. Pero una vez que empiezas a construir paquetes para ello, donde quieres entrelazar el servidor y el cliente en un paquete que luego se consume, no funciona ni de cerca tan bien.

Hay muchos cambios, tanto grandes como pequeños, que podrían hacerse en el lado de React y Next para facilitar la creación de un paquete full stack. Pero todavía estamos llegando allí. Y la cantidad de trabajo que empresas como la nuestra, empresas como Payload, empresas como Clark han puesto para hacer que el código funcione idealmente en ambos entornos ha sido realmente doloroso. Imagina si un paquete no pudiera proporcionar componentes y hooks, y trataras de tener un paquete que usara hooks en sus componentes o, Dios no lo quiera, componentes dentro de sus hooks que React simplemente levantaría las manos y diría lo siento. Así es como se siente construir paquetes que usarán react-server y react-client ahora mismo. Esto debería cambiar en el futuro, pero ahora mismo ha sido doloroso. Si quieres ver ese dolor, ve a mirar el código de upload thing de código abierto. Está lleno de ello.

Dicho esto, nunca volveremos atrás. Esto es lo mejor que ha habido. Estoy más feliz que nunca escribiendo react. Y realmente recomiendo mucho que revises los server components si aún no lo has hecho. Están cambiando cómo pienso sobre escribir software. Obviamente no hay garantías. Y cuando inviertes en algo tan futurista, podrías terminar perdiendo y podríamos no terminar yendo con esto a largo plazo. Pero ahora mismo, simplemente se siente genial trabajar con ello. Y si quieres aprender algo nuevo, y no tienes miedo de que posiblemente no sea la próxima gran cosa, no podría recomendar Server Components lo suficiente. Y honestamente, me sorprendería mucho si estos no son cómo terminamos escribiendo software en el futuro. Hasta la próxima, ¡paz nerds!