Tu Mejor Amigo del Frontend - Cómo Enviar Rápido en 2025

Hola, React Summit. Tengo una idea de proyecto paralelo realmente emocionante, genial y nueva, pero también estoy un poco asustado porque en realidad no tengo un buen historial cuando se trata de proyectos paralelos y la mayoría de ellos fracasaron. Y estoy bastante seguro de que no soy el único. Si revisas tu GitHub, estoy bastante seguro de que hay una lista muy larga de proyectos paralelos abandonados también. Y eso está bien, ¿verdad? Algunos de ellos son solo con fines de aprendizaje. Entonces fue genial, ¿verdad? De todos modos, tuviste éxito al aprender algo nuevo.

Pero a veces también tienes una idea realmente genial y realmente crees en ella, y luego aún así falla, ¿verdad? Y eso es simplemente porque la mayoría de los proyectos de software fallan. Pero si algo es realmente importante para ti, como este proyecto paralelo lo es para mí, realmente quieres preguntarte, ¿cómo puedes mejorar tus posibilidades de éxito? Y encontré este gran tweet aquí de Graeme, quien es el CEO y fundador de Vercel, quien dice que la velocidad de iteración y la observabilidad resuelven todos los problemas conocidos de ingeniería de software. Ningún desafío es demasiado grande, ningún error demasiado difícil cuando puedes lanzar rápido y obtener visibilidad.

Así que la observabilidad, obviamente muy importante. Quieres saber cuándo algo sale mal. Quieres tener trazas e informes de errores, pero también quieres tener análisis sobre cómo las personas están usando tu producto y obtener información de eso. Pero quiero centrarme ahora en la parte de la velocidad de iteración. Entonces, si lanzas rápido, eso significa que puedes lanzar más funciones y corregir más errores con los mismos recursos, ¿verdad? Así que puedes usar recursos como lo que sea que esté limitando tu proyecto. Para una startup, probablemente sea la financiación, y para un proyecto paralelo, eso podría ser el tiempo sobre motivación o una combinación de estos, ¿verdad? Así que si puedes lanzar más rápido, puedes aprovechar más estos recursos. Tienes un ciclo de retroalimentación más rápido, y generalmente eso significa que puedes aumentar las posibilidades de éxito.

Y mi nombre es Andrey. Soy un defensor de desarrolladores en Neon. Y estos días he construido muchas aplicaciones pequeñas, proyectos y ejemplos. Y quiero asegurarme de que siempre que construya algo, lo haga rápido y de la manera correcta. Y en general, me encanta pensar en arquitecturas de software y ver cómo evolucionan con el tiempo.

Hoy, el patrón del que quiero hablar se llama back-end para front-end o lo estamos llamando aquí el mejor amigo del front-end y cómo enviar rápido en 2025. En 2023, ya di una charla sobre que el momento de ir full stack es ahora y básicamente estaba motivando que deberías usar Remix en Next.js y abandonar tus aplicaciones de una sola página del lado del cliente y las APIs rest de propósito general.

Así que en lugar de tener aplicaciones de una sola página solo del lado del cliente, prueba un marco web full stack y aprovecha toda la plataforma web. Y creo que para ahora la mayoría de la gente entiende que los marcos web full stack vienen con una UX realmente genial. Quiero decir, mucha gente ya está usando Next.js y Remix, pero solo quiero resumir algunos de los puntos una vez más. Así que imaginemos que estás usando una aplicación de una sola página solo del lado del cliente, algo como create React app, y luego tal vez también tienes una o varias APIs que estás consumiendo, ¿verdad? Esos pueden ser diferentes equipos que las están construyendo, o tal vez solo tienes para tu proyecto paralelo una aplicación express, ¿verdad? Que está sirviendo algunos endpoints de API rest.

En su lugar, solo construyes endpoints personalizados para las rutas y páginas de tu sitio, y está mucho más estrechamente acoplado. Dado que todo está en una aplicación que despliegas en un solo lugar, en lugar de desplegar en CDN para los archivos estáticos de la SPA y luego en una función Lambda o algo similar para la API rest, sabes que tienes un despliegue tal vez en Vercel para la aplicación de Next.js para toda tu aplicación. Y además, eso hace que el intercambio de código sea obviamente mucho más fácil, ¿verdad? Como obviamente, puedes hacer configuraciones de monorepo y demás, pero al tener una aplicación full stack obtienes seguridad de tipos a través de la red de forma gratuita. Tienes una aplicación para ambos entornos. Así que eso ya debería hacerte más rápido. Pero lo más importante, en mi opinión, es que ahora posees el servidor, el servidor web que recibe solicitudes de documentos entrantes desde el navegador, ¿verdad? Así que hay muchas cosas que hemos hecho tradicionalmente en React que probablemente estén mejor ubicadas para hacerse en el entorno del servidor web. Un buen ejemplo de eso son las redirecciones, ¿verdad? Si quieres, si hay una solicitud get entrante, quieres ver si alguien se ha autenticado y luego redirigirlo para iniciar sesión, eso es algo que está realmente bien ubicado en tu servidor web o el entorno que maneja las solicitudes del navegador entrantes, ¿verdad? Así que ahora, puedes manejar la lógica del backend en un backend web dedicado.

Así que aquí está el ejemplo OG del sitio web de Remix. Así que si vas a Remix.run, este ejemplo creo que no ha cambiado desde que Remix fue lanzado por primera vez. Además, el modo Framework de React Router todavía hoy se ve muy similar. Así que lo que vemos aquí es una ruta de Remix con una función loader, función action, y un componente de ruta. Y así es como se ve la convención de enrutamiento de Remix. El loader obtiene datos en el servidor, y luego tienes acceso a eso en el componente de React con el hook use loader data. Y luego en ese componente, puedes enviar acciones. Esas van a la función action que maneja mutaciones post get delete de esa ruta. Y esa acción puede luego redirigir o devolver datos. Así que esta es la arquitectura de Remix. Y lo que es muy interesante sobre esto es que obviamente no tenemos un endpoint de proyecto post, endpoint REST, y un endpoint de objeto delete y un endpoint REST de proyectos get. En su lugar, tenemos un loader que devuelve todos los datos necesarios para esta ruta.

Esto puede incluir proyectos, pero también podría devolver adicionalmente el usuario, ¿verdad? Así que ya está agregando datos. Pero más importante, lo que ha cambiado desde que Remix salió por primera vez, el loader no está realmente devolviendo datos JSON más. Ahora está devolviendo un formato diferente usando un transporte llamado Turbostream. Y Turbostream fue desarrollado para poder serializar promesas, pero también objetos de fecha y otros primitivos de JavaScript, y luego deserializarlos nuevamente en el cliente. Así que con JSON, obviamente, si pasas un objeto de fecha, en realidad se convierte en una cadena en JSON porque JSON no puede manejar objetos de datos, pero se convierte en una cadena. Y luego tienes que deserializarlo nuevamente en el cliente si quieres transformarlo de nuevo en un objeto de fecha. Y obviamente, no hay concepto de promesas en JSON. Y eso es algo que Remix y ahora construido para realmente como incluso acoplar más estrechamente el lado del cliente y el lado del backend.

Y eso es algo que Remix y ahora construido para realmente como incluso acoplar el lado del cliente y el lado del backend más estrechamente juntos. Así que con Turbostream, que es HTTP en streaming, ahora puedes pasar promesas y evadir las promesas o diferir las promesas en el cliente y mostrar un suspense, algún tipo de cargador mientras todavía se está obteniendo en el servidor, ¿verdad? Puedes ver cómo Remix y también Next.js, en ese sentido, los componentes de React.js, realmente dan un paso más allá en la construcción de transportes y protocolos sobre React para realmente acoplar estrechamente el frontend y el backend, ¿verdad? Así que como los frameworks full stack se están volviendo incluso más adaptados de esa manera. Mencioné React Server Components, ¿verdad? React Server Components es su propio protocolo que tiene sus propias cargas útiles que está enviando al cliente que tampoco es solo JSON regular, sino algo que React en el cliente entiende para entender cómo manejar diferentes casos de uso cuando se trata de React Server Components. Y aquí tengo que mencionar BFF. BFF obviamente es un patrón muy antiguo que no tiene nada que ver con React Server Components o Remix, pero es un patrón donde dices que un frontend debería tener un servidor dedicado que tome todas sus solicitudes y las maneje de una manera muy específica para ese frontend y abstrae todo el otro backend y bases de datos downstream, microservicios, y cualquier locura que haya dentro de tu corporación y empresa. Así que el patrón BFF proviene de este panorama de microservicios, pero definitivamente podemos decir que Next.js y Remix están implementando el patrón BFF, ¿verdad? Así que si estás desplegando una aplicación Next.js, es una aplicación full stack que sirve a un cliente, y luego para ese cliente, el backend de Next.js está implementando o es un backend específico para el frontend de Next.js. Eso lo convierte en el mejor amigo del frontend. Genial. Así que todo esto es, supongo, lo básico. Quiero decir, React Server Components todavía es muy nuevo y todos estamos tratando de entenderlo. Y obviamente, Remix, también conocido como React Router y Next.js todavía están cambiando, ¿verdad? Así que como TurboStream es un cambio bastante nuevo en Remix. Era JSON antes, pero aún creo que la mayoría de la gente ha aceptado que la DX, o frameworks web full stack, es increíble, y es una forma realmente genial de lanzar rápido cuando quieres construir para la web. Pero eso también es solo donde las cosas comienzan, ¿verdad? Como incluso si tienes un gran framework web full stack ya en producción, digamos que tengo un nuevo proyecto paralelo, estoy comenzando con Remix, ¿verdad? Entonces mucha de la aventura todavía solo comienza, ¿verdad? Todavía tenemos que pensar en los requisitos de nuestra aplicación, lo que realmente queremos jugar, ¿queremos tener soporte offline, características multijugador, verdad? ¿Debería sentirse nativo? Hay muchas expectativas para las aplicaciones en 2025, ¿verdad? Así que nuestro trabajo no está terminado. Si acaso, solo está comenzando. Y este es el estado en el que estaba con mi proyecto paralelo. Esta vez decidí ir con Next.js. Generé el primer prototipo con V0, y V0 es tan bueno para construir sitios Next.js, y quería probar React Server Components. Y luego Chatsy, y Tavern, ¿verdad? Así que tengo esta pila realmente genial, y estoy iterando en mi proyecto. Todo es solo crud al final del día. Realmente feliz, sin embargo. Y luego MCP aparece en la esquina, y me confundo. ¿Todavía estoy construyendo lo correcto? Entonces, ¿qué es MCP? MCP es el Model Context Protocol, y permite a los modelos de lenguaje grandes, LLMs, integrarse con servicios y herramientas de terceros. Así que si tienes algún tipo de interfaz de chat que está conectada con un modelo de lenguaje grande, llamamos a eso un cliente MCP en el protocolo MCP. Así que digamos que Cloud Desktop o Cursor pueden ser nuestro cliente MCP. Y luego estamos conectando, o queremos conectar esa interfaz de chat con muchos diferentes servicios de terceros. Y esos servicios pueden proporcionar al LLM este contexto, pero también proporcionar herramientas que el LLM puede ejecutar. Así que digamos, por ejemplo, que tenemos un servidor MCP de tareas, ¿verdad? Así que en el chat, podemos decir, estoy trabajando en refactorizar la cosa, por favor escríbeme una tarea. O como, oye, cursor, ¿cuáles son mis tareas para el día, verdad? Inmediatamente ves cómo integrar todos estos servicios hace que la interfaz de chat sea más poderosa, ¿verdad? Como al final del día, quieres conectarlo con todas tus herramientas. Lo que estoy mostrando aquí es solo como algunos ejemplos, ¿verdad? Como digamos que hay un Slack MCP, un email MCP. Lo que quiero decir con eso es que cada servicio que quieras utilizar debería exponer su propio servidor MCP.

Así que para mi proyecto paralelo, si tengo algunas capacidades de multitud, ¿verdad?, también podría querer crear y alojar un servidor MCP para poder conectarlo con los clientes MCP de mi elección y utilizar mi proyecto paralelo de esa manera. Pero también significa que tengo que desplegar una cosa más. Así que la cosa naranja aquí, por cierto, son los transportes. Así que tu MCP puede comunicarse con las aplicaciones de diferentes maneras. Puedes tener tu servidor MCP ejecutándose localmente, luego se comunica a través de I.O. estándar. Pero también puedes desplegar tu servidor MCP de forma remota.

Y luego las capas de transporte son ya sea servicio y eventos o HTTP transmisible. Y todo esto también es muy nuevo y está cambiando mucho. Así que si eres nuevo en el protocolo MCP, puedo recomendarte que revises los sitios de Kenzie Dot. Él está haciendo mucho contenido sobre MCP en este momento. Y creo que MCP está aquí para quedarse. Y tenemos que entenderlo. Así que solo puedo recomendarte que lo hagas. ¿Cuál es mi problema, sin embargo? Así que para mi proyecto paralelo, estaba realmente feliz con mi pequeña pila tecnológica. ¿Verdad? Dije que estaba usando Next.js y Chatsie y Tailwind. Así que tengo esta aplicación en funcionamiento. La estoy conectando a mi base de datos NEON. Y ahora también quiero tener un servidor MCP. ¿Cómo encaja eso en esta arquitectura? Acabo de decirle a todos que se deshagan de sus APIs REST, las APIs REST de propósito general. Y es realmente genial tener este backend adaptado para tu frontend. Pero con aplicaciones LLM, tenemos un nuevo tipo de frontend, ¿verdad?

Lo que quiero evitar es tener demasiados entornos diferentes. No quiero tener una API REST dedicada, y luego mi aplicación Remix o Next.js antes de eso. Y luego un servidor MCP, y ambos consumen la API REST. Quiero mantenerlo simple. Así que más complejidad. El problema también es que MCP es con estado. Así que si dices, está bien, hagamos esto, tengamos una API REST, y luego simplemente expongamos como un servidor MCP, el problema es que, nuevamente, MCP espera que tu servidor sea muy específico. Tiene que ser con estado, tiene que soportar HTML transmisible o servidores y eventos, y las cosas que quieres exponer no deberían ser tan atómicas como los endpoints CRUD. Como si tienes un servidor MCP de tareas, probablemente puedas exponer un crear tarea, listar tareas, y eliminar tareas endpoints. Pero si tu servidor MCP se vuelve más complicado, realmente tienes que pensar en flujos de trabajo y conceptos de nivel más alto.

Así que solo para dar un ejemplo, el servidor MCP de NEON, y NEON es un servicio de oferta de base de datos que expone una arquitectura Postgres sin servidor. Y obviamente, cuando tienes un servicio Postgres ejecutándose en algún lugar, quieres exponer herramientas como queryMyDatabase o listMyDatabases. Pero algunas de estas herramientas que estamos exponiendo también son de un nivel mucho más alto. Por ejemplo, tenemos una herramienta de preparación de migración de base de datos que hace varias cosas en una llamada de herramienta. Así que creamos una nueva rama, devolvemos las instrucciones LLM, qué hacer con esta rama y cómo recomendamos que el agente haga la migración real de la base de datos. Y luego recomendamos al agente que una vez que el agente confirme que todo está bien en la rama, llame a la herramienta de migración completa de la base de datos. Así que estas dos llamadas de herramientas tienen que estar encadenadas, ¿verdad? Así que hay algún tipo de proceso aquí. Así que es con estado.

Así que lo que estoy tratando de comunicar aquí es que si estás construyendo un servidor MCP, realmente tienes que pensar profundamente sobre el extremo consumidor, que es un modelo de lenguaje grande. Así que tienes que proporcionar herramientas que no sean genéricas en APIs REST nuevamente, sino algo que esté muy personalizado hacia ese LLM, lo que ese LLM espera y puede manejar y desempeñarse bien con. Y eso es muy similar a lo que acabamos de hablar sobre este próximo año como un remix, ¿verdad? Como turbo stream y componentes de servidor rect son protocolos específicos y transporte para nuestra experiencia de front-end. Y de manera muy similar aquí, tenemos un protocolo MCP y herramientas y casos de uso muy personalizados específicamente adaptados hacia este nuevo tipo de front-end.

Y afortunadamente no soy el único que está pensando en esto. Hace solo tres días, grabé esto, esta captura de pantalla es de hoy. Así que el, este adaptador tiene en realidad tres años, tres días ahora. Vercel ha lanzado ahora un adaptador para crear servidores MCP como parte de una aplicación Next.js existente. Y obviamente, Vercel no es el único, Cloudflare también tiene una forma genial de desplegar servidores MCP ya. Así que hay diferentes soluciones, soluciones que vienen en nuestro camino. Pero lo que realmente me gusta de este adaptador de servidor MCP de Vercel es que simplemente se adapta a la arquitectura de mi proyecto paralelo existente.

Así que ahora puedo convertir mi aplicación Next.js en un sistema que sirve a dos front-ends diferentes, ¿verdad? Como tengo una nueva ruta ahora usando ese adaptador llamado slash API slash MCP donde puedo enrutar agentes LM hacia. Y luego esa ruta o esa lista de rutas ahora está manejando solicitudes MCP. Y luego tengo todas las otras rutas tradicionales de mi aplicación Next.js que sirven al front-end de Next.js. Lo que obviamente es realmente genial de este enfoque es que en realidad no tengo un servidor MCP dedicado que tenga que desplegar o publicar en otro lugar. Sigue siendo una aplicación Next.js que puedo desplegar en un solo lugar.

Y como es un solo proyecto, ni siquiera tengo que preocuparme por configuraciones de repositorio múltiple. Todo está dentro de un solo proyecto. Así que compartir código es súper fácil. Y luego lo curioso aquí, y dime si te gusta este enfoque, MCP se convierte en otro backend para un front-end específico, ¿verdad? Así que si piensas en Next.js ahora siendo un backend para nuestra aplicación React, ahora también es un backend para nuestras diferentes aplicaciones de modelos de lenguaje grande. Así que se convierte en un sistema de múltiples backends. Así que de todos modos, así es como lo pienso, en lo que terminé. Y creo que es muy interesante cómo se está desarrollando todo esto ahora mismo. Nuevamente, todo esto puede cambiar mañana, ¿verdad?