Eliminando BFFs con GraphQL y Next.js

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Las aplicaciones de Frontend se están volviendo cada vez más complicadas, a menudo entregando mucho más que solo una interfaz de usuario. Con esta creciente complejidad surge una creciente necesidad de conocimiento por parte de los desarrolladores que la crean, ya que tienen que lidiar con asuntos como la gestión de estados, autorización, enrutamiento y más. En esta charla, te mostraré cómo usar GraphQL en tu aplicación Next.js para crear una capa de datos para tu aplicación, que existe entre tu frontend y tu backend. En esta capa de datos, puedes manejar asuntos complejos para ayudarte a mantener tu aplicación de frontend limpia y "estúpida".

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

FAQ

Un backend para frontend (BFF) es una arquitectura diseñada para separar las preocupaciones entre los diferentes frontends de una aplicación (como web y móvil) y el backend. Es importante porque permite adaptar los servicios backend de manera específica para cada tipo de cliente, mejorando la experiencia del usuario y optimizando el rendimiento y mantenimiento de las interfaces.

Los microservicios pueden complicar el desarrollo al requerir que se manejen múltiples servicios pequeños y separados. Esto puede llevar a confusiones sobre quién es responsable de cada microservicio y aumentar la carga de trabajo en cuanto a la coordinación y mantenimiento de los mismos.

Next.js facilita la creación de un backend para frontend unificado que puede manejar todos los microservicios, lo que simplifica la implementación y el mantenimiento. Además, con las rutas API de Next.js, los desarrolladores pueden crear endpoints de manera sencilla, lo que ayuda a organizar mejor y centralizar la gestión de las llamadas a estos servicios.

Utilizar un BFF ayuda a resolver problemas de integración entre el frontend y el backend, especialmente en escenarios donde diferentes plataformas frontales necesitan interactuar con el mismo sistema backend. Esto es crítico para asegurar que cada cliente tenga la información y las funcionalidades adaptadas a sus necesidades específicas sin interferir con otros clientes.

La autonomía en el uso de BFFs permite que diferentes equipos trabajen de manera más independiente, cada uno enfocado en su propio cliente (web o móvil). Esto reduce las dependencias cruzadas entre equipos, facilitando la escalabilidad y agilidad en el desarrollo y despliegue de nuevas funcionalidades.

Tener múltiples servicios puede incrementar la complejidad en el mantenimiento y la implementación, así como en la innovación, ya que cambios en un servicio pueden requerir coordinación con varios equipos. Además, puede aumentar la carga de trabajo relacionada con la gestión de varios BFFs y microservicios.

Roy Derks
Roy Derks
21 min
25 Oct, 2021

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Esta charla discute los desafíos y beneficios de usar Backend para Frontends (BFFs) y microservicios en el desarrollo de software. Destaca cómo Next.js puede simplificar la creación de BFFs y unificar la puerta de enlace para microservicios. La charla también enfatiza las ventajas de las rutas API de Next.js en la simplificación del desarrollo, despliegue y mantenimiento de APIs. Muestra la implementación de un BFF utilizando Next.js y rutas API, y la extensión de rutas API de una manera ejecutable. El orador también menciona el lanzamiento de un curso sobre el uso de rutas API de Next.js para construir una API GraphQL sin servidor.

1. Introducción a Matar BFFs con Next.js

Short description:

Hola a todos y bienvenidos a mi charla, Matar BFFs con Next.js. Esta charla es sobre microservicios, BFFs y monolitos, y el trabajo extra que pueden implicar para tu equipo. Discutiremos cómo abordar este problema. Disfruten de la charla y estén atentos para la sesión de preguntas y respuestas.

Hola a todos, y bienvenidos a mi charla, Matar BFFs con Next.js. Supongo que casi es Halloween, así que es una excelente manera de empezar con una apertura de Halloween. Entonces, Matar BFFs con Next.js, pero no es una charla de Halloween, pero es algo que probablemente sea interesante para la mayoría de ustedes. Entonces, ¿de qué trata esta charla? Empecemos por... Probablemente ya saben sobre microservicios o tal vez todavía están usando un monolito. También tienen BFFs y monolitos, pero esos son un poco diferentes. Así que imagina que tienes microservicios y luego tienes un backend para frontend para tu cliente web, tal vez tienes un backend para frontend separado para tu cliente móvil. Así que esto probablemente esté perfectamente bien, pero es algo que requiere mucho trabajo extra para tu equipo y tal vez también para tus desarrolladores de backend porque necesitan asegurarse de que los microservicios estén adaptados a dos diferentes backend para frontends. Así que eso es algo que estamos discutiendo hoy en esta charla. Así que espero que todos disfruten y si tienen alguna pregunta después,

2. Backend para Frontends y Microservicios

Short description:

Backend para frontends (BFFs) puede ser tanto beneficioso como complicado. Permite que diferentes clientes tengan experiencias personalizadas, pero también puede llevar a inconsistencias. Los monolitos, que son una API para gobernarlos a todos, se utilizan comúnmente. Por otro lado, los microservicios ofrecen servicios separados para diferentes objetivos. Sin embargo, coordinar estos servicios puede ser un desafío. Incluso si no usas BFFs, esta charla te mostrará cómo Next.js puede proporcionar una puerta de enlace unificada para los microservicios.

hay tiempo para preguntas y respuestas. Así que el backend para frontends es... Bueno, también podría ser esto, cuando tú y tu backend para frontend saben algo que nadie más sabe. Así que esto es en realidad un problema porque tu cliente móvil puede estar haciendo algo con su backend móvil para frontend mientras que el cliente web quiere hacer lo mismo, pero tal vez la lógica no está implementada allí. Así que los backend para frontends no son solo una forma de facilitar las cosas para el cliente. También pueden llevar a complicaciones adicionales porque tal vez un cliente sabe algo que otro cliente no sabe.

Entonces, un poco sobre mí. Mi nombre es Roy. Puedes encontrarme en Twitter con mi nombre de usuario en GetHackTeam. Soy un emprendedor, un ingeniero de software, pero también he escrito algunos libros y hablo regularmente en conferencias. Así que si aún no me conoces, por favor búscame en Twitter. Actualmente también trabajo con una empresa llamada Stepsen. Lo que están haciendo es crear una única API GraphQL unificada para todas tus fuentes de data. Así que eso es bastante genial si quieres empezar con GraphQL. También doy masterclasses y formaciones a través de mi propia empresa, Hack Team, así que asegúrate de visitar la página web también si tienes preguntas al respecto. Pero también asegúrate de disfrutar de esta charla e intenta aprender algo nuevo.

Entonces, ¿cómo llegamos al backend para frontend? Así que el backend para frontend o BFFs, como ya dije, ¿cómo llegamos realmente allí? Creo que la primera vez que la mayoría de ustedes entró en contacto con la API por primera vez fue con los monolitos. Así que los monolitos son, como dicen, una API para gobernarlos a todos. Y los monolitos pueden ser APIs REST, también pueden ser APIs GraphQL, tal vez incluso SOAP si empezaste con el web development o el desarrollo en general hace mucho tiempo. Así que los monolitos son básicamente una API para gobernarlos a todos. Y si estás trabajando con diferentes clientes desde nuestro monolito, normalmente tendrías separados los endpoints REST o si estás usando GraphQL, que puede ser una gran manera de tener diferentes clientes para un monolito. Probablemente tendrás diferentes consultas que están adaptadas a diferentes clientes que están consumiendo tu API GraphQL o REST. Así que básicamente son monolitos, una API para gobernarlos a todos, lo cual está perfectamente bien porque la mayoría de las empresas ni siquiera llegan a un tamaño en el que necesiten tener microservices, pero si llegas allí, entonces los microservices también son algo muy interesante para los desarrolladores de API. Pero para los desarrolladores de front-end o los desarrolladores de React, conducirá a algunas dificultades adicionales, porque siempre me gusta este meme sobre los microservices. Así que cuando tu jefe te dice que estamos convirtiendo a microservices, esto realmente puede suceder. Así que los microservices son servicios pequeños, de ahí lo de micro, y es un servicio para un objetivo separado. Así que tal vez tienes un servicio para tu authentication, tienes un servicio para obtener tus usuarios, un servicio para obtener tal vez información sobre productos, otro servicio para obtener tus pedidos de check-out, todas estas cosas estarán divididas en diferentes microservices. Y estos microservices por supuesto necesitan ser unificados en algún lugar, tal vez en una pasarela de API, tal vez tu front-end está llamando a todos los microservices por separado, lo cual es algo que deberías tratar de evitar. Así que incluso si no estás usando backend para front-ends, puede ser un resultado interesante de esta charla, aprender sobre cómo puedes usar Next.js para tener una pasarela unificada para todos tus microservices. Entonces, ¿para qué sirven los backend para front-ends? Así que ahora más o menos sabemos por qué tenemos backend para front-ends, así que teníamos APIs de monolito, lo cual es agradable, pero puede ser confuso si tienes varios clientes usando el mismo monolito. También vimos ya los microservices, que también están perfectamente bien, pero también pueden ser muy confusos si no tienes una pasarela de API en su lugar o la división sobre quién es responsable de qué microservices

3. Beneficios y Desafíos de Back-end para Front-ends

Short description:

Los Back-end para front-ends (BFFs) son buenos para separar preocupaciones y proporcionar diferentes experiencias para los clientes web y móviles. La autonomía es otra ventaja, permitiendo a diferentes equipos trabajar de forma independiente. Sin embargo, tener más servicios puede llevar a desafíos en la implementación y el mantenimiento. Las rutas API de NextJS simplifican este proceso.

muy, muy extraño. También podría ser, dependiendo de tu empresa. Entonces, ¿para qué son buenos los back-end para front-ends? Así que ya vi esta imagen, así que podrías tener un conjunto de microservices, o también podría ser un monolito. Eso es algo que también veo sucediendo. Así que la gente tiene un back-end para front-end que está conectado al monolito. Y desde el monolito, simplemente tienen APIs REST separadas que están utilizando y APIs que no están utilizando. Pero los back-end para front-ends, o back-end para los extremos móviles, me gusta llamarlos, simplemente se llaman cliente móvil y back-end para front-end también. Así que tenemos un back-end front-end para un cliente web, tenemos uno para un cliente móvil. Y la razón por la que estos back-end front-ends están ahí es probablemente porque tienes experiencias muy diferentes. Así que tal vez tienes un cliente web que es una gran interfaz de panel de control mientras que tu móvil el cliente es solo una versión muy simple de eso. Así que para ese caso de uso, los back-end para front-ends son geniales porque realmente puedes separar las preocupaciones, puedes asegurarte de que no tienes ninguna interacción entre diferentes clientes. Y también si una cosa se rompe, la otra cosa no necesariamente también se rompe a menos que, por supuesto, uno de tus microservices subyacentes o monolito se rompa. Así que una experiencia muy diferente es una forma de tener una razón para tener un back-end para front-end. Y también como dije la separación de preocupaciones. Así que tal vez estás haciendo cosas muy diferentes en tu cliente móvil y no quieres que tu cliente web esté al tanto de estos cambios. Así que entonces la separación de preocupaciones para esto es perfecta porque tal vez también tienes más separaciones de preocupaciones incluso con tus servicios. Así que tal vez tus microservices o parte de tu los monolitos están específicamente adaptados para móviles, entonces puede ser un buen caso de uso para tener este back-end para front-end mejor. Y entonces el que más me gusta es en realidad la autonomía. Así que si tienes una gran empresa scale o tal vez incluso una empresa más pequeña con un chico o chica haciendo el cliente web, otra persona haciendo el cliente móvil, y luego una persona haciendo back-end, para esta autonomía ya funciona porque las personas de back-end no tienen que preocuparse por cómo el front-end consume el producto. Mientras que la persona web puede hacer un BFF para su cliente web que es utilizado específicamente por el cliente web, y él o ella es la única persona que realmente usa esto. Y lo mismo ocurre con el móvil. Así que tal vez tienes una persona haciendo móvil, pueden construir su propio BFF, no tienen que preocuparse por romper nada en un cliente web. Así que la autonomía es una muy buena razón para empezar a usar back-end BFFs.

Pero más servicios también tiene una desventaja, por supuesto, y esto es algo de lo que quiero hablar hoy. Así que tener más servicios siempre tiene una desventaja porque si volvemos a este ejemplo, así que tienes la parte de autonomía pero tienes los servicios que necesitan ser implementados, tienes un BFF que necesita ser implementado, y tienes un cliente web que necesita ser implementado. Así que si estás trabajando en un cliente web tienes tres cosas que son importantes para ti que necesitan ser implementadas para que tu servicio funcione. Así que esto es algo de preocuparse porque tienes 1, 2, 3 servicios y luego la persona móvil también tiene tres servicios y luego ya hay gente trabajando juntos tal vez en sus microservices en la parte de atrás porque tal vez la persona web ya está ayudando a la persona de back-end, entonces la otra cosa va alrededor y es para la startup. Así que si eres una gran empresa tal vez tienes varios equipos trabajando en un cliente web, varios equipos trabajando con el back-end para front-end y varios equipos trabajando en tus microservices. Así que esto es algo de lo que preocuparse porque los servicios extra también significan trabajo extra. Así que esta desventaja es para el mantenimiento, para la implementación, pero también para innovation porque si quieres hacer cambios en algún lugar necesitas hablar con esta cadena entera de personas para asegurarte de que puedes hacer los cambios que quieres hacer. Así que las rutas API de NextJS hacen esto muy simple, así que creo que empezaron esto no hace mucho

4. Simplificando las rutas API con NextJS

Short description:

Las rutas API en NextJS simplifican la creación de rutas API, permitiendo a los desarrolladores crear fácilmente páginas separadas para web y API. Esto elimina la necesidad de múltiples backends y simplifica las preocupaciones de implementación e infraestructura. Con NextJS, los desarrolladores de frontend pueden concentrarse en construir un único BFF dentro de la aplicación.

hace un tiempo. Así que con las rutas API puedes realmente crear, bueno, las palabras lo dicen, puedes crear rutas API desde NextJS. Así que NextJS es el sistema de enrutamiento interno basado en los archivos, así que tal vez tienes páginas slash bienvenida, entonces tendrías realmente una página slash bienvenida en tu sitio web a la que la gente puede ir para ver un mensaje de bienvenida. Para la API es lo mismo, puedes simplemente tener páginas slash API slash bienvenida y entonces tienes una API para obtener tal vez un bloque de JSON que quieres mostrar en la página de bienvenida de la API. Así que las rutas API de NextJS hacen esto muy simple y antes de que realmente vayamos bajo el capó por qué las rutas API son buenas, vamos a mostrar lo que hará a nuestra arquitectura. Así que antes teníamos un backend para la web que era utilizado por nuestro cliente web y luego teníamos uno separado para el móvil y luego el cliente móvil lo utilizaba y por supuesto todos los servicios pero ahora en realidad para los desarrolladores de frontend o los desarrolladores web ya se vuelve mucho más fácil porque ahora les encanta tener un único BFF que está construido dentro de la aplicación NextJS que pueden hacer todas las cosas. Así que no tienen que preocuparse por la implementación, no tienen que preocuparse por DNS, no tienen que preocuparse por tal vez dónde viven las cosas dentro de una infraestructura Kubernetes, así que hace las cosas para

5. Construyendo un BFF con NextJS y Rutas API

Short description:

NextJS es un excelente marco para construir un BFF para tu aplicación web. Permite la normalización de datos, limpieza y llamadas a la API desde una única aplicación Next. El uso de rutas API elimina la sobrecarga de múltiples implementaciones y garantiza un directorio o repositorio unificado. Exploremos este patrón con una implementación utilizando SendGrid para enviar correos electrónicos. Al manejar la solicitud a través de una ruta API de backend, podemos ocultar la información subyacente y las credenciales del usuario, proporcionando una experiencia más segura.

un cliente web mucho más fácil. Pero también el BFF móvil, por supuesto, podría ser capaz de usar este BFF también, así que tal vez si no tienes un BFF separado para web o móvil puede ser una solución agradable que incluso como dije antes si estás llamando a todos tus microservices directamente desde tu cliente web sin un BFF, el BFF todavía puede estar allí para ayudarte a hacer esto de manera más eficiente porque entonces siempre tienes una forma muy agradable de ver dónde se juntan las cosas, tienes una forma de normalizar, de limpiar tus data. Así que NextJS es muy bueno con esto, especialmente con las rutas API para construir un BFF para tu aplicación web y por supuesto entonces nosotros todavía tendríamos las separaciones de preocupaciones, porque si estás planeando tener múltiples BFFs o múltiples backend para frontends, entonces todavía tienes separación de preocupaciones porque la gente de la web son responsables de lo que sucede en un BFF web y la gente móvil no tiene que preocuparse por ello, siempre y cuando no estén construyendo su aplicación móvil con NextJS por supuesto, que es de hecho posible con React Native, pero es una discusión completamente diferente.

Y también todavía tenemos autonomía. Así que todavía tenemos autonomía allí, porque la gente de la web todavía son responsables de lo que está pasando en una aplicación NextJS, son responsables de lo que está pasando allí en términos de normalización de data, limpieza de data, en términos de qué APIs serán llamadas, así que todo se hará desde una sola aplicación Next, convirtiéndola en una especie de framework que es más full stack de lo que vimos antes. Así que los frameworks full stack se están volviendo más populares en el React ecosystem, así que tenemos como un Remix, o BlitzJS, tal vez incluso Redroot para Node.js. Así que las cosas están volviéndose cada vez más autónomas en términos de consideraciones full stack para aplicaciones React. Y NextJS también está siguiendo esto con las rutas API. Y lo más importante, lo que veo es lo más importante es que no tienes la sobrecarga adicional de las implementaciones, de asegurarte de que las cosas están allí, o de asegurarte de que las cosas están arriba, tener DNS, ser responsable de otros servicios, necesitar aplicar cambios en otros servicios, necesitar alinear tal vez lo que está pasando en términos de implementación en tu cliente web, tu cliente móvil y todos los otros pasos de BFF por ahí. Así que la sobrecarga adicional realmente se va cuando empiezas a usar rutas API. Y hay muchas más beneficios, que podría mostrarte en un momento, pero lo más importante para mí es tener todas tus implementaciones en un solo directorio o tal vez un solo repositorio es un gran logro. Así que hará que Next.js sea mucho más accesible para las personas que están haciendo cosas full stack y tal vez ahora tienen algo funcionando con Express. Así que vamos a verlo. Así que veamos cómo se ve esto. Así que permíteme cambiar a mi code aquí.

Así que hay varias formas de usar este patrón con las rutas API. Y antes de que realmente entremos en el backend para front-ends, vamos a algo como esto. Es en realidad algo así como un backend para front-end. Así que hice una implementación con SendGrid. Es una forma de enviar correos electrónicos. Y lo que hice aquí, en realidad un problema que tengo, estaba usando SendGrid directamente para mi cliente. Y una desventaja que tienes, si empiezas a interactuar con APIs de terceros desde tu cliente o tal vez tus propios microservices desde el cliente, puedes filtrar información. Así que si miras aquí, tengo una clave API, tengo una ID de lista, y ahora estoy enviando esto desde una ruta API de backend, se manejará en el backend. Así que el usuario no verá que hay una solicitud de red a SendGrid. El usuario sólo verá que hay una solicitud de red a API slash sign-up newsletter. Así que esta es una gran forma de ocultar también la información subyacente sobre tal vez tus credenciales, sobre tu microservices architecture, sobre qué servicio es responsable de qué. Así que al hacerlo de esta manera, es uno de los ejemplos de tener un BFF, es ser capaz de ocultar patrones arquitectónicos subyacentes o credenciales a un usuario. Así que si estuviera haciendo esto desde el cliente, mi usuario podría ver que estoy haciendo una solicitud a SendGrid, así que ya estoy revelando qué tercero estoy usando para los correos electrónicos. Luego también estoy revelando mi clave API de SendGrid, e incluso mi ID de lista. Así que probablemente hacer esto desde un cliente, no sería tan inteligente. No diría realmente estúpido, pero digamos que no es realmente inteligente, porque estás filtrando toda esta información a un usuario, y el usuario sería capaz de ver esto.

6. Construyendo Rutas API con Next.js

Short description:

Al construir un front-end, no quieres crear una API completa o depender de un equipo diferente. Con las rutas API de Next.js, puedes manejar todo desde una base de código, ocultando datos sensibles y protegiendo contra hackers. Otro beneficio es la integración con GraphQL, simplificando el manejo de datos y haciendo el desarrollo más sencillo. Las rutas API en Next.js también admiten middleware, eliminando la necesidad de un servidor express y permitiendo el despliegue sin servidor.

Pero lo que tampoco quieres hacer, si estás construyendo un front-end, no quieres construir una API completa para hacer esto. Así que anteriormente, tenía que pedirle a mi desarrollador de back-end, hey, ¿puedes hacer una llamada a la API en la que puedo enviar algo a un tercero API, y probablemente funcionará, pero necesito depender de un equipo diferente. Si ya tengo mi back-end para front-end, probablemente puedo hacer el cambio allí, o tal vez puedo pedirle a un desarrollador de back-end que haga el cambio, pero todavía dependo de un servicio diferente.

Así que con las rutas API, puedo hacer todas estas cosas solo desde una única base de code. Así que crearías una página, slash API, slash enviar un boletín, y es la forma en que puedes ocultar todas las cosas que están sucediendo aquí para mi usuario. Así que no estás revelando tu API de terceros, no estás revelando tu microservice architecture o patrón. Y también, que es el más importante, no estás filtrando ningún data sensible, porque eso es algo que no quieres hacer. Voy a suponer que la mayoría de nuestros usuarios son bastante amigables, pero tal vez si encuentras a un hacker real en tu sitio web, entonces es algo que específicamente no quieres hacer.

Así que otro caso de uso genial, que también escribí aquí, incluso puedes usar GraphQL. Así que esta es una de las mayores ventajas que veo aquí, usando esto junto con GraphQL. Y este es un caso de uso realmente genial, específicamente porque GraphQL hace las cosas mucho más simples para la mayoría de nosotros, porque podemos tener una ruta API que es una ruta API de GraphQL, porque GraphQL es una API única. Y desde allí podemos hacer todo nuestras cosas de ida y vuelta, toda nuestra limpieza, toda la normalización de data, asegurarnos de que todos nuestros patterns están allí. Así que realmente nos ayuda a hacer las cosas más sencillas. Así que volvamos al code y veamos cómo se ve. Así que tenemos nuestros endpoints de GraphQL. Así que simplemente creamos un endpoint, páginas slash API slash GraphQL. Y aquí, definimos un esquema. Uh, defines tus resolvers y tus resolvers probablemente serán solo llamadas a la API a algún lugar. Así que esto probablemente sería, um, return call microservice, microservice X. Así que ya conoces el procedimiento. Probablemente estás creando resolvers. Estás diciendo qué microservices necesitas llamar, y luego realmente creas tu esquema. Estás realmente creando un esquema ejecutable. Y antes de ir a esto, vamos aquí. Así que lo que estoy haciendo aquí, uh, estoy creando mi esquema ejecutable, pero lo que también hago es ejecutar middleware, que es en realidad un futuro muy agradable porque, uh, la forma en que crearon las rutas API para asegurarse de que son compatibles con middleware, uh, para conectar diferentes servicios. Así como en realidad sabemos de express. Así que ahora puedo usar Express GraphQL y básicamente cualquier otro middleware para express para mi ruta API. Así que no hay necesidad real de encender para iniciar un servidor express. En realidad, puedes hacer todas estas cosas directamente desde, um, 1API route index s. Así que te va a ahorrar enormes cantidades de tiempo de despliegue, de asegurarte de que hay un docker, asegurándote de que hay todas estas otras cosas y no diciendo incluso mejor alojarlos

7. Extendiendo Rutas API con Next.js

Short description:

Al usar las rutas API de Next.js, puedes extender tus rutas API de manera ejecutable, haciéndolas a prueba de futuro. Puedes crear una API gráfica que se ejecuta en una ruta API, con resolvers, esquema y middleware todo en un directorio. Consulta la documentación para más detalles. También estoy lanzando un curso sobre el uso de las rutas API de Next.js para construir una API GraphQL sin servidor. Visita mi sitio web para obtener más información y aprender sobre otros cursos. Sígueme en Twitter o encuentra mis videos en YouTube para aprender más sobre React, GraphQL y TypeScript. ¡Disfruta de la conferencia y mantente atento a las próximas charlas!

porque las rutas API, también puedes llevarlas a serverless, lo cual es realmente agradable. Um, una forma realmente agradable de hacer esto es porque al tenerlo serverless, no tienes que preocuparte por cosas como el despliegue, estar disponible, estar en funcionamiento. Y por supuesto, Next.js ha sido construido por Vercel. También hay soporte para eso. Y también hay nuevas herramientas geniales. Si quieres asegurarte de que tus aplicaciones serverless y API estén realmente funcionando, uh, pero quizás esas las podemos guardar para la sesión de preguntas y respuestas. Así que ejecutar middleware es algo realmente genial porque, uh, al tener esta forma ejecutable de extender tus rutas API, también las hace realmente a prueba de futuro porque todas las cosas que ya han sido construidas, todas las bibliotecas de código abierto para diferentes APIs de Express. Ya puedes hacerlas ahora desde las rutas API. Así que usando esto, básicamente puedo crear una API gráfica que se ejecuta en una ruta API. Uh, tener todos mis resolvers, tener mi esquema allí. Estamos en medio de eso como Express GraphQL, pero quizás también middleware para authentication, middleware para logging, todo desde un solo directorio. Así que es una característica realmente genial para tener.

Entonces sí, si quieres aprender más sobre el uso de rutas API y Next.js, uh, por supuesto, te insto a que consultes la documentation porque la documentation realmente te ayuda a entender las rutas API, pero además de eso, también estoy lanzando un curso sobre el uso de Next.js, pero GraphQL en rutas API. Así que si estás interesado en este curso, asegúrate de ir a mi sitio web, que es hack team.io slash courses. Y podrás encontrar un enlace para construir la API GraphQL serverless con Next.js en este curso. Mostraré, por supuesto, más in depth, el code que ya vimos antes. Um, y también aprender algunos trucos nuevos geniales sobre las rutas API de Next.js, pero sobre todo, también GraphQL. Así que estaremos construyendo cosas geniales, um, como el polling de red en el backend, uh, pero también cómo manejar estas rutas API. Así que a continuación, Next.js. Um, y sobre todo, también aprender cómo desplegarlas de manera serverless. Así que si quieres aprender más sobre Next.js, asegúrate de ir al sitio web de Next.js. Para saber más sobre mis cursos, por favor, ve a mi sitio web. Uh, sobre todo, si quieres aprender más sobre, uh, react, GraphQL, TypeScript, uh, este tipo de cosas, asegúrate de seguirme en Twitter o encontrar mis, um, encontrar mis videos en YouTube. Uh, y luego espero que realmente estés disfrutando de la conferencia hasta ahora, y sigas disfrutando de la conferencia, uh, las charlas que vienen. Porque si miro el horario, veo que hay algunas personas realmente agradables hablando de cosas realmente geniales. Así que asegúrate de, uh, de quedarte. Y luego espero ver tus preguntas fluyendo en Twitter, uh, o quizás de alguna otra manera puedes encontrarme. Gracias a todos.

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

Enrutamiento en React 18 y más allá
React Summit 2022React Summit 2022
20 min
Enrutamiento en React 18 y más allá
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.
De GraphQL Zero a GraphQL Hero con RedwoodJS
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
De GraphQL Zero a GraphQL Hero con RedwoodJS
Top Content
Tom Pressenwurter introduces Redwood.js, a full stack app framework for building GraphQL APIs easily and maintainably. He demonstrates a Redwood.js application with a React-based front end and a Node.js API. Redwood.js offers a simplified folder structure and schema for organizing the application. It provides easy data manipulation and CRUD operations through GraphQL functions. Redwood.js allows for easy implementation of new queries and directives, including authentication and limiting access to data. It is a stable and production-ready framework that integrates well with other front-end technologies.
Estado Local y Caché del Servidor: Encontrando un Equilibrio
Vue.js London Live 2021Vue.js London Live 2021
24 min
Estado Local y Caché del Servidor: Encontrando un Equilibrio
Top Content
This Talk discusses handling local state in software development, particularly when dealing with asynchronous behavior and API requests. It explores the challenges of managing global state and the need for actions when handling server data. The Talk also highlights the issue of fetching data not in Vuex and the challenges of keeping data up-to-date in Vuex. It mentions alternative tools like Apollo Client and React Query for handling local state. The Talk concludes with a discussion on GitLab going public and the celebration that followed.
Una Guía Práctica para Migrar a Componentes de Servidor
React Advanced 2023React Advanced 2023
28 min
Una Guía Práctica para Migrar a Componentes de Servidor
Top Content
React query version five is live and we'll be discussing the migration process to server components using Next.js and React Query. The process involves planning, preparing, and setting up server components, migrating pages, adding layouts, and moving components to the server. We'll also explore the benefits of server components such as reducing JavaScript shipping, enabling powerful caching, and leveraging the features of the app router. Additionally, we'll cover topics like handling authentication, rendering in server components, and the impact on server load and costs.
El Nuevo Router de Aplicaciones Next.js
React Summit 2023React Summit 2023
27 min
El Nuevo Router de Aplicaciones Next.js
Top Content
Today's Talk is about the Next.js App Router, which has evolved over the years and is now a core feature of Next.js. The Talk covers topics such as adding components, fetching remote data, and exploring layouts. It also discusses submitting form data, simplifying code, and reusing components. The App Router allows for coexistence with the existing pages router and enables data fetching at the layout level using React Server Components.
No sabes cómo hacer SSR
DevOps.js Conf 2024DevOps.js Conf 2024
23 min
No sabes cómo hacer SSR
The Talk covers the speaker's personal journey into server-side rendering (SSR) and the evolution of web development frameworks. It explores the use of jQuery for animations in SSR, the challenges faced in integrating React with Umbraco, and the creation of a custom SSR framework. The Talk also discusses the benefits of Next.js and the use of serverless artifacts for deployment. Finally, it highlights the features of Astro, including its function per route capability.

Workshops on related topic

AI para Desarrolladores de React
React Advanced 2024React Advanced 2024
142 min
AI para Desarrolladores de React
Top Content
Featured Workshop
Eve Porcello
Eve Porcello
El conocimiento de las herramientas de AI es fundamental para preparar el futuro de las carreras de los desarrolladores de React, y la suite de herramientas de AI de Vercel es una vía de acceso accesible. En este curso, examinaremos más de cerca el Vercel AI SDK y cómo esto puede ayudar a los desarrolladores de React a construir interfaces de transmisión con JavaScript y Next.js. También incorporaremos APIs de terceros adicionales para construir y desplegar una aplicación de visualización de música.
Temas:- Creación de un Proyecto de React con Next.js- Elección de un LLM- Personalización de Interfaces de Transmisión- Construcción de Rutas- Creación y Generación de Componentes - Uso de Hooks (useChat, useCompletion, useActions, etc)
Tracing: Frontend Issues With Backend Solutions
React Summit US 2024React Summit US 2024
112 min
Tracing: Frontend Issues With Backend Solutions
Top Content
Featured WorkshopFree
Lazar Nikolov
Sarah Guthals
2 authors
Los problemas de frontend que afectan a tus usuarios a menudo son provocados por problemas de backend. En esta masterclass, aprenderás cómo identificar problemas que causan páginas web lentas y malos Core Web Vitals usando tracing.
Luego, pruébalo tú mismo configurando Sentry en un proyecto Next.js ya preparado para descubrir problemas de rendimiento, incluyendo consultas lentas a la base de datos en una sesión interactiva de programación en pareja.
Saldrás de la masterclass siendo capaz de:- Encontrar problemas de backend que podrían estar ralentizando tus aplicaciones de frontend- Configurar tracing con Sentry en un proyecto Next.js- Depurar y solucionar problemas de rendimiento deficiente usando tracing
Este será un evento en vivo de 2 horas donde tendrás la oportunidad de codificar junto con nosotros y hacernos preguntas.
El Viaje Desde el Frontend con React al Desarrollo Fullstack Con Next.js
React Summit 2025React Summit 2025
91 min
El Viaje Desde el Frontend con React al Desarrollo Fullstack Con Next.js
Featured Workshop
Eric Burel
Eric Burel
Únete a nosotros en el viaje desde el desarrollo frontend con React hasta el desarrollo fullstack con Next.js. Durante esta masterclass, seguiremos el tutorial oficial de Next.js Learn con Eric Burel, entrenador profesional y autor de NextPatterns.dev. Juntos, configuraremos un sitio web con Next.js y exploraremos sus características del lado del servidor para construir aplicaciones de alto rendimiento.
Construye una aplicación WordPress sin cabeza con Next.js y WPGraphQL
React Summit 2022React Summit 2022
173 min
Construye una aplicación WordPress sin cabeza con Next.js y WPGraphQL
Top Content
Workshop
Kellen Mace
Kellen Mace
En esta masterclass, aprenderás cómo construir una aplicación Next.js que utiliza Apollo Client para obtener datos de un backend de WordPress sin cabeza y usarlo para renderizar las páginas de tu aplicación. Aprenderás cuándo debes considerar una arquitectura de WordPress sin cabeza, cómo convertir un backend de WordPress en un servidor GraphQL, cómo componer consultas usando el IDE GraphiQL, cómo colocar fragmentos GraphQL con tus componentes, y más.
Next.js 13: Estrategias de Obtención de Datos
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Estrategias de Obtención de Datos
Top Content
Workshop
Alice De Mauro
Alice De Mauro
- Introducción- Prerrequisitos para la masterclass- Estrategias de obtención: fundamentos- Estrategias de obtención – práctica: API de obtención, caché (estática VS dinámica), revalidar, suspense (obtención de datos en paralelo)- Prueba tu construcción y sírvela en Vercel- Futuro: Componentes de servidor VS Componentes de cliente- Huevo de pascua de la masterclass (no relacionado con el tema, destacando la accesibilidad)- Conclusión
Construir con SvelteKit y GraphQL
GraphQL Galaxy 2021GraphQL Galaxy 2021
140 min
Construir con SvelteKit y GraphQL
Top Content
Workshop
Scott Spence
Scott Spence
¿Alguna vez has pensado en construir algo que no requiera mucho código de plantilla con un tamaño de paquete pequeño? En esta masterclass, Scott Spence irá desde el hola mundo hasta cubrir el enrutamiento y el uso de endpoints en SvelteKit. Configurarás una API de GraphQL en el backend y luego usarás consultas de GraphQL con SvelteKit para mostrar los datos de la API de GraphQL. Construirás un proyecto rápido y seguro que utiliza las características de SvelteKit, y luego lo desplegarás como un sitio completamente estático. Este curso es para los curiosos de Svelte que no han tenido una experiencia extensa con SvelteKit y quieren una comprensión más profunda de cómo usarlo en aplicaciones prácticas.

Tabla de contenidos:
- Inicio e introducción a Svelte
- Inicializar el proyecto frontend
- Recorrido por el proyecto esqueleto de SvelteKit
- Configurar el proyecto backend
- Consultar datos con GraphQL
- Recuperación de datos en el frontend con GraphQL
- Estilización
- Directivas de Svelte
- Enrutamiento en SvelteKit
- Endpoints en SvelteKit
- Despliegue en Netlify
- Navegación
- Mutaciones en GraphCMS
- Envío de mutaciones GraphQL a través de SvelteKit
- Preguntas y respuestas