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

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

La mayoría de los proyectos de software fallan, pero enviar rápido mejora tus posibilidades de éxito. Por eso es tan importante centrarse en la velocidad de iteración y debes diseñar la arquitectura de tu aplicación en consecuencia. Los frameworks de full stack como Next y Remix te dan control total sobre la experiencia web con acceso a un servidor web dedicado. Con Next y Remix, expones endpoints personalizados para tu UI (acciones del servidor, acciones y cargadores de Remix) y utilizas cargas útiles de propósito especial (por ejemplo, a través de RSC o turbo-stream) adaptadas para el frontend web. Pero, ¿qué pasa si necesitas agregar otro frontend a tu proyecto? Con las aplicaciones LLM ganando popularidad y el Model Context Protocol (MCP) ganando adopción, es cada vez más probable que necesites servir tanto aplicaciones LLM de terceros como tu aplicación frontend existente. ¿Cómo podemos servir mejor a las aplicaciones LLM con nuestra arquitectura de full stack existente? ¡Hablemos de Backend for Frontend, arquitecturas de aplicaciones de full stack y MCP!

This talk has been presented at React Summit 2025, check out the latest edition of this React Conference.

Andre Landgraf
Andre Landgraf
20 min
17 Jun, 2025

Comments

Sign in or register to post your comment.
Video Summary and Transcription
La charla profundiza en mejorar las tasas de éxito en proyectos de software al centrarse en la velocidad de iteración y la observabilidad. Las discusiones giran en torno a las ventajas de utilizar frameworks web de full stack como Next.js y Remix para un desarrollo de software eficiente y una mejor compartición de código. Se explora la integración de TurboStream, BFF y Model Context Protocol (MCP) en el desarrollo de full stack. Se destacan las soluciones innovadoras de Vercel y Cloudflare para integrar servidores MCP en aplicaciones Next.js, simplificando la compartición de código y permitiendo experiencias de frontend diversas.

1. Mejorando el Éxito en Proyectos de Software

Short description:

El orador discute los desafíos y la importancia de mejorar las tasas de éxito en proyectos de software al enfocarse en la velocidad de iteración y la observabilidad para resolver problemas de ingeniería.

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.

2. Streamlining Software Development

Short description:

Andrey, un defensor de desarrolladores en Neon, discute los beneficios de usar un marco web full stack como Next.js y Remix para agilizar el desarrollo de software y mejorar el intercambio de código.

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.

3. Efficient Frontend-Backend Integration

Short description:

Construcción de endpoints personalizados para un mejor intercambio de código y un despliegue más rápido en aplicaciones full stack. Utilización del servidor web para la lógica del backend y manejo eficiente de redirecciones. Exploración de la arquitectura de Remix y su enfoque en la carga y transporte de datos usando Turbostream para una mejor integración frontend-backend.

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.

4. Evolving Full Stack Development

Short description:

Integrando frontend y backend estrechamente con nuevos protocolos y patrones como TurboStream y BFF. Explorando el panorama en evolución de los frameworks web full stack y consideraciones para el desarrollo futuro de aplicaciones. Introducción al Model Context Protocol (MCP) para integrar modelos de lenguaje grandes con servicios y herramientas de terceros.

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.

5. Integrating MCP Server in Tech Stack

Short description:

Abordando la integración de un servidor MCP en una pila tecnológica para proyectos paralelos mientras se consideran varias opciones de comunicación y despliegue.

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?

6. Optimizing MCP Server Development

Short description:

Evitando la complejidad al considerar la especificidad requerida para los servidores MCP y la necesidad de herramientas personalizadas en el desarrollo de servidores MCP.

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.

7. Innovative MCP Server Integration

Short description:

Vercel y Cloudflare ofrecen soluciones para crear servidores MCP dentro de Next.js. El adaptador de servidor MCP se integra perfectamente en proyectos existentes, permitiendo que una sola aplicación Next.js sirva a múltiples front-ends sin la necesidad de un despliegue de servidor MCP separado. Este enfoque simplifica el intercambio de código y transforma Next.js en un backend versátil para diversas experiencias 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?

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Vue: Actualizaciones de Características
Vue.js London 2023Vue.js London 2023
44 min
Vue: Actualizaciones de Características
Top Content
The Talk discusses the recent feature updates in Vue 3.3, focusing on script setup and TypeScript support. It covers improvements in defining props using imported types and complex types support. The introduction of generic components and reworked signatures for defined components provides more flexibility and better type support. Other features include automatic inference of runtime props, improved define emits and defined slots, and experimental features like reactive props destructure and define model. The Talk also mentions future plans for Vue, including stabilizing suspense and enhancing computer invalidations.
Futuro de los Frameworks Frontend Charla Informal
React Summit 2024React Summit 2024
28 min
Futuro de los Frameworks Frontend Charla Informal
Fred K. Schott
Minko Gechev
Ryan Carniato
Daniel Afonso
Aakansha Doshi
Tim Neutkens
6 authors
Signals are being adopted by popular frameworks, enabling code reuse and improved tooling. While merging between frameworks is unlikely, they are learning from each other and adopting shared practices. It is important to embrace the diversity of frameworks and libraries. Instead of merging, focus on standardizing the principles behind frameworks. Consider tradeoffs and benefits when choosing a framework, and explore different technologies to learn new ideas.
Guía para desarrolladores frontend sobre Web3
React Summit 2022React Summit 2022
22 min
Guía para desarrolladores frontend sobre Web3
This talk covers an introduction to Web 3 and smart contracts, including deployment and bytecode compilation. It also discusses interacting with blockchain wallets, using RPC endpoints and block explorers, and accessing smart contract data. The talk emphasizes the use of ABIs and JavaScript libraries like ethers for interacting with smart contracts. It mentions the shift in mindset from HTTP requests to using ABI code and libraries for front-end development in Web 3. The talk concludes by mentioning Web3UI and tools like PolygonScan and Etherscan for building on the blockchain.
Monitorización de errores y ralentizaciones con un frontend de JS y un backend de Node
Node Congress 2022Node Congress 2022
8 min
Monitorización de errores y ralentizaciones con un frontend de JS y un backend de Node
Sentry is code monitoring for developers, specifically designed for the application layer. It helps identify error details, frequency, release, user information, and stack trace. Source maps can be uploaded to see the original source code and suspect commits can be identified. Performance monitoring helps identify slowdowns and determine the cause. Automating alerts and investigating errors helps gain instant context and trace errors across different projects.
Serverless para Frontends
DevOps.js Conf 2022DevOps.js Conf 2022
8 min
Serverless para Frontends
Premium
Welcome to my session on Serverless for Front-ends. Serverless functions eliminate the need for a runtime and handle orchestration for you. Microfrontends require a runtime and orchestration, but side-less UIs provide a runtime-free solution. In the demo, a new team adds functionality to an application and publishes it easily. Building and deploying applications is quick and easy with micro apps and PowerCLI, offering true loose coupling and instant availability without a runtime.
DevOps para Frontend: más allá de los navegadores de escritorio
DevOps.js Conf 2021DevOps.js Conf 2021
31 min
DevOps para Frontend: más allá de los navegadores de escritorio
Today's Talk discusses DevOps for frontend beyond desktop browsers, focusing on the challenges and journey to DevOps, the importance of abstractions, maximizing flow and enabling team autonomy, applying DevOps principles beyond web applications, running automated tests on consoles and TVs, investing in tooling for TV testing, and the challenges of TV testing in the lab.

Workshops on related topic

Seguimiento de errores y ralentizaciones en Node + JavaScript utilizando Sentry
Node Congress 2022Node Congress 2022
53 min
Seguimiento de errores y ralentizaciones en Node + JavaScript utilizando Sentry
Workshop
Neil Manvar
Neil Manvar
Repasaremos la configuración de Sentry paso a paso para obtener visibilidad en nuestro frontend y backend. Una vez integrado, rastrearemos y solucionaremos errores y transacciones que se muestren en Sentry desde nuestros servicios para comprender por qué/dónde/cómo ocurrieron errores y ralentizaciones en nuestro código de aplicación.