Matando BFFs con GraphQL y Next.js

Rate this content
Bookmark

Las aplicaciones frontend se están volviendo cada vez más complicadas, a menudo ofreciendo mucho más que solo una interfaz de usuario. Con esta creciente complejidad surge la necesidad de conocimientos por parte de los desarrolladores que la crean, ya que deben lidiar con temas como la gestión del estado, la autorización, el 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 frontend limpia y "estúpida".

21 min
25 Oct, 2021

Video Summary and Transcription

Esta charla analiza los desafíos y beneficios de utilizar Backend for 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 de API de Next.js al simplificar el desarrollo, implementación y mantenimiento de las API. Muestra la implementación de un BFF utilizando Next.js y las rutas de API, y la extensión de las rutas de API de manera ejecutable. El orador también menciona el lanzamiento de un curso sobre cómo usar las rutas de API de Next.js para construir una API GraphQL sin servidor.

Available in English

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

Short description:

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

Hola a todos y bienvenidos a mi charla, Killing BFFs con Next.js. Supongo que casi es Halloween, así que es una excelente manera de comenzar con una apertura de Halloween. Pero Killing BFFs con Next.js 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? Comencemos... Probablemente ya conozcan los microservicios o tal vez aún estén utilizando un monolito. También tienen BFFs y monolitos, pero estos son un poco diferentes. Imaginen que tienen microservicios y luego tienen un backend para el frontend de su cliente web, tal vez tengan un backend separado para el frontend de su cliente móvil. Esto probablemente esté bien, pero es algo que requiere mucho trabajo adicional para su equipo y tal vez también para sus desarrolladores de backend porque necesitan asegurarse de que los microservicios estén adaptados a dos backend diferentes para los frontends. Eso es algo que discutiremos hoy en esta charla. Así que espero que todos disfruten y si tienen alguna pregunta después,

2. Backend for Frontends and Microservices

Short description:

Los Backend for Frontends (BFFs) pueden ser beneficiosos y complicados. Permiten experiencias personalizadas para diferentes clientes, pero también pueden generar inconsistencias. Los monolitos, que son una única API para controlar todo, 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 utilizas 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. Entonces, el Backend for Frontends es... Bueno, también podría ser esto, cuando tú y tu backend para frontend saben algo que nadie más sabe. Esto puede ser un problema porque tu cliente móvil puede estar haciendo algo con su backend para frontend móvil, mientras que el cliente web quiere hacer lo mismo, pero tal vez la lógica no está implementada allí. Entonces, los Backend for Frontends no solo son una forma de facilitar las cosas para el cliente. También pueden generar complicaciones adicionales porque tal vez un cliente sabe algo que otro cliente no sabe.

Un poco sobre mí. Mi nombre es Roy. Puedes encontrarme en Twitter con mi usuario GetHackTeam. Soy emprendedor, ingeniero de software y también he escrito algunos libros y soy ponente regular en conferencias. Si aún no me conoces, por favor encuéntrame en Twitter. Actualmente también trabajo en una empresa llamada Stepsen. Lo que están haciendo es crear una API GraphQL unificada para todas tus fuentes de datos. Es bastante genial si quieres comenzar con GraphQL. También imparto talleres y entrenamientos en mi propia empresa, Hack Team, así que asegúrate de visitar el sitio web si tienes preguntas al respecto. Pero también asegúrate de disfrutar esta charla e intentar aprender algo nuevo.

Entonces, ¿cómo llegamos al backend para frontend? ¿Cómo llegamos realmente allí? Creo que la primera vez que la mayoría de ustedes se encontraron con una API fue con los monolitos. Los monolitos son, como dicen, una única API para controlar todo. Los monolitos pueden ser APIs REST, también pueden ser APIs GraphQL, tal vez incluso SOAP si comenzaste con el desarrollo web o el desarrollo en general hace mucho tiempo. Entonces, los monolitos son básicamente una única API para controlar todo. Y si estás trabajando con diferentes clientes desde nuestro monolito, típicamente tendrías puntos finales REST separados o si estás usando GraphQL, que puede ser una excelente manera de tener diferentes clientes para un monolito. Probablemente tendrás consultas diferentes adaptadas a diferentes clientes que consumen tu API GraphQL o REST. Entonces, básicamente son monolitos, una única API para controlar todo, lo cual está perfectamente bien porque la mayoría de las empresas ni siquiera llegan a un tamaño en el que necesiten tener microservicios, pero si llegas allí, entonces los microservicios también son algo muy interesante para los desarrolladores de API. Pero para los desarrolladores de frontend o los desarrolladores de React, esto generará algunas dificultades adicionales, porque siempre me gusta este meme sobre los microservicios. Cuando tu jefe te dice que estamos migrando a microservicios, esto realmente puede suceder. Los microservicios son servicios pequeños, por eso micro, y es un servicio para un objetivo separado. Entonces, tal vez tengas un servicio para la autenticación, tengas un servicio para obtener tus usuarios, un servicio para obtener información sobre productos, otro servicio para obtener tus pedidos de pago, todas estas cosas se dividirán en diferentes microservicios. Y estos microservicios, por supuesto, necesitan estar unificados en algún lugar, tal vez una puerta de enlace de API, tal vez tu frontend esté llamando a todos los microservicios por separado, lo cual es algo que deberías tratar de evitar. Entonces, incluso si no estás utilizando backend para frontends, puede ser un resultado interesante de esta charla, aprender cómo puedes usar Next.js para tener una puerta de enlace unificada para todos tus microservicios. Entonces, ¿para qué son buenos los backend para frontends? Ahora sabemos más o menos por qué tenemos backend para frontends, así que teníamos APIs monolíticas, que es bueno, pero puede ser confuso si tienes múltiples clientes que usan el mismo monolito. También hemos visto los microservicios, que también están perfectamente bien, pero también pueden ser muy confusos si no tienes una puerta de enlace de API en su lugar o la división sobre quién es responsable de qué microservicios.

3. Benefits and Challenges of Back-end for Front-ends

Short description:

Los Back-end for Front-ends (BFFs) son buenos para separar las preocupaciones y proporcionar diferentes experiencias para clientes web y móviles. La autonomía es otra ventaja, permitiendo que diferentes equipos trabajen de forma independiente. Sin embargo, tener más servicios puede generar desafíos en la implementación y el mantenimiento. Las rutas de 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? Ya vi esta imagen, así que podrías tener un conjunto de microservicios, o también podría ser un monolito. Eso es algo que también veo que sucede. Así que las personas tienen un back-end para front-end que está conectado al monolito. Y desde el monolito, simplemente tienen API REST separadas que están utilizando y API que no están utilizando. Pero es back-end para front-ends, o back-end para terminales móviles, me gusta llamarlos, simplemente se llama cliente móvil y back-end para front-end también. Entonces, tenemos un back-end para front-end para un cliente web, tenemos uno para un cliente móvil. Y la razón por la que estos back-end para front-ends están ahí es probablemente porque tienes experiencias muy diferentes. Tal vez tienes un cliente web que es una interfaz de panel enorme mientras que tu cliente móvil es simplemente una versión muy simple de eso. Entonces, para ese caso de uso, los back-end para front-ends son geniales porque realmente puedes separar las preocupaciones, puedes asegurarte de que no haya interacciones entre diferentes clientes. Y también si algo se rompe, la otra cosa no necesariamente también se rompe a menos que, por supuesto, uno de tus microservicios subyacentes o monolito se rompa. 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. Entonces, tal vez estés haciendo cosas muy diferentes en tu cliente móvil y no quieras que tu cliente web esté al tanto de estos cambios. Entonces, la separación de preocupaciones para esto es perfecta porque tal vez también tengas más separaciones de preocupaciones incluso con tus servicios. Entonces, tal vez tus microservicios o parte de tu monolito estén específicamente adaptados para móviles, entonces puede ser un buen caso de uso tener este back-end para front-end mejor. Y luego el que más me gusta es la autonomía. Entonces, si tienes una empresa a gran escala o tal vez incluso una empresa más pequeña con una persona haciendo el cliente web, otra persona haciendo el cliente móvil y luego una persona haciendo el back-end, para esta autonomía ya funciona porque las personas del back-end no tienen que preocuparse por cómo el front-end consume el producto. Mientras que la persona del web puede hacer un BFF para su cliente web que es específicamente utilizado por el cliente web, y él o ella es la única persona que realmente lo usa. Y lo mismo ocurre para el móvil. Entonces, tal vez tengas una persona haciendo móvil, pueden construir su propio BFF, no tienen que preocuparse por romper nada en un cliente web. Entonces, la autonomía es una muy buena razón para comenzar a usar back-end BFFs.

Pero tener más servicios también tiene un inconveniente, por supuesto, y esto es algo de lo que quiero hablar hoy. Tener más servicios siempre tiene un inconveniente porque si volvemos a este ejemplo, tienes la parte de autonomía pero tienes los servicios que deben implementarse, tienes un BFF que debe implementarse y tienes un cliente web que debe implementarse. Entonces, si estás trabajando en un cliente web, tienes tres cosas que son importantes para ti y que deben implementarse para que tu servicio funcione. Entonces, esto es algo de lo que preocuparse porque tienes 1, 2, 3 servicios y luego la persona móvil también tiene tres servicios y luego ya hay personas trabajando juntas tal vez en sus microservicios en la parte posterior porque tal vez la persona web ya está ayudando al back-end, luego la otra cosa sucede y es solo para la puesta en marcha. Entonces, si eres una gran empresa, tal vez tengas varios equipos trabajando en un cliente web, varios equipos trabajando con el back-end para front-end y varios equipos trabajando en tus microservicios. Entonces, esto es algo de lo que preocuparse porque servicios adicionales también significan trabajo adicional. Entonces, esta desventaja es para el mantenimiento, para la implementación, pero también para la innovación porque si quieres hacer cambios en algún lugar, necesitas hablar con toda esta cadena de personas para asegurarte de que realmente puedes hacer los cambios que deseas hacer. Entonces, las rutas de API de NextJS hacen que esto sea realmente muy simple, así que creo que comenzaron esto no hace mucho tiempo.

4. Simplificando las Rutas de API con NextJS

Short description:

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

Hace un tiempo, con las rutas de API puedes crear, bueno, las palabras lo dicen, puedes crear rutas de API desde NextJS. NextJS es el sistema de enrutamiento interno basado en archivos, por lo que tal vez tengas una página 'welcome' en tu sitio web a la que las personas pueden acceder para ver un mensaje de bienvenida. Para la API es lo mismo, simplemente puedes tener una página 'API/welcome' y luego tener una API para obtener tal vez un bloque de JSON que deseas mostrar en la página de bienvenida de la API. Las rutas de API de NextJS hacen esto muy simple y antes de profundizar en por qué las rutas de API son buenas, veamos qué harán a nuestra arquitectura. 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 el cliente móvil lo utilizaba, y por supuesto, todos los servicios. Pero ahora, para los desarrolladores frontend o los desarrolladores web, se vuelve mucho más fácil porque ahora solo tienen un único BFF que está construido dentro de la aplicación NextJS y pueden hacer todas las cosas con él. Entonces, no tienen que preocuparse por el despliegue, no tienen que preocuparse por DNS, no tienen que preocuparse por dónde se encuentran las cosas dentro de una infraestructura de Kubernetes, por lo que simplifica las cosas para ellos.

5. Construyendo un BFF con NextJS y Rutas de API

Short description:

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

un cliente web mucho más fácil. Pero también el BFF móvil, por supuesto, podría utilizar este BFF también, por lo que si no tienes un BFF separado para web o móvil, puede ser una buena solución que incluso, como dije antes, si ahora estás llamando a todos tus microservicios directamente desde tu cliente web sin un BFF, el BFF aún puede estar presente para ayudarte a hacer esto de manera más eficiente, porque siempre tendrás una forma muy buena de ver cómo se unen las cosas, tendrás una forma de normalizar y limpiar tus datos. Entonces, NextJS es muy bueno en esto, especialmente con las rutas de API para construir un BFF para tu aplicación web y, por supuesto, luego aún tendríamos las separaciones de responsabilidades, porque si planeas tener múltiples BFF o múltiples backend para frontends, aún tienes separación de responsabilidades porque las personas de web son responsables de lo que sucede en un BFF web y las personas de móvil no tienen que preocuparse, siempre y cuando no estén construyendo su aplicación móvil con NextJS, por supuesto, lo cual es posible con React Native, pero es una discusión completamente diferente.

Y aún tenemos autonomía. Así que todavía tenemos autonomía allí, porque las personas de web todavía son responsables de lo que sucede en una aplicación NextJS, son responsables de lo que sucede allí en términos de normalización de datos, limpieza de datos, en términos de qué API se llamará, por lo que todo se hará desde una sola aplicación Next, lo que la convierte en una especie de framework más completo que antes. Entonces, los frameworks full stack están ganando popularidad en el ecosistema de React, como Remix, o BlitzJS, tal vez incluso Redroot para Node.js. Entonces, las cosas se están volviendo cada vez más autónomas en términos de consideraciones full stack para aplicaciones de React. Y NextJS también sigue esto con las rutas de API. Y lo más importante de todo, lo que veo como lo más importante, es que no tienes la sobrecarga adicional de despliegues, de asegurarte de que las cosas estén disponibles, o de asegurarte de que las cosas estén en funcionamiento, tener DNS, ser responsable de otros servicios, necesitar aplicar cambios en otros servicios, necesitar alinear tal vez lo que está sucediendo en términos de despliegue en tu cliente web, tu cliente móvil y todos los otros pasos de BFF que existen. Entonces, la sobrecarga adicional realmente desaparece cuando comienzas a usar las rutas de API. Y hay muchas más ventajas, que puedo mostrarte en un momento, pero sobre todo para mí, tener todos tus despliegues en un solo directorio o tal vez en un solo repositorio es un gran logro. Entonces, hará que Next.js sea mucho más accesible para las personas que hacen cosas full stack y tal vez ahora tienen algo en funcionamiento con Express. Así que vamos a verlo. Vamos a ver cómo se ve esto. Así que permíteme cambiar a mi código aquí.

Hay varias formas de usar este patrón con las rutas de API. Y antes de adentrarnos en el backend para frontends, veamos algo como esto. Es en realidad algo así como un backend para frontend. Hice una implementación con SendGrid. Es una forma de enviar correos electrónicos. Y lo que hice aquí, en realidad tengo un problema, estaba usando SendGrid directamente para mi cliente. Y un inconveniente que tienes, si comienzas a interactuar con APIs de terceros desde tu cliente o tal vez tus propios microservicios desde el cliente, puedes filtrar información. Entonces, si miras aquí, tengo una clave de API, tengo un ID de lista, y ahora estoy enviando esto desde una ruta de API de backend, se manejará en el backend. Entonces, el usuario no verá que hay una solicitud de red que se envía a SendGrid. El usuario solo verá que hay una solicitud de red que se envía a API/sign-up-newsletter. Entonces, esta es una excelente manera de ocultar información subyacente sobre tal vez tu credenciales, sobre tu arquitectura de microservicios, sobre qué servicio es responsable de qué. Entonces, al hacerlo de esta manera, es uno de los ejemplos de tener un BFF, es poder ocultar patrones arquitectónicos subyacentes o credenciales a un usuario. Entonces, si estuviera haciendo esto desde el cliente, mi usuario podría ver que estoy haciendo una solicitud a SendGrid, revelando qué servicio de terceros estoy utilizando para los correos electrónicos. Luego también estaría revelando mi clave de API de SendGrid, e incluso mi ID de lista. Entonces, probablemente, si lo hiciera desde un cliente, no sería muy inteligente. No quiero decir estúpido, pero digamos que no sería muy inteligente, porque estarías filtrando toda esta información a un usuario, y el usuario podría ver esto.

6. Construyendo rutas de API con Next.js

Short description:

Cuando construyes un front-end, no quieres crear una API completa o depender de un equipo diferente. Con las rutas de API de Next.js, puedes manejar todo desde una sola base de código, ocultando datos sensibles y protegiéndote contra hackers. Otro beneficio es la integración con GraphQL, simplificando el manejo de datos y facilitando el desarrollo. Las rutas de 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 solo estás construyendo un front-end, es construir una API completa para hacer esto. Antes, tenía que pedirle a mi desarrollador de back-end, `oye, ¿puedes hacer una llamada a la API en la que pueda enviar algo a una API de terceros?`, y eso probablemente funcionará, pero necesito depender de un equipo diferente. Si ya tengo mi back-end para el front-end, probablemente pueda hacer el cambio allí, o tal vez pueda pedirle a un desarrollador de back-end que haga el cambio, pero aún dependo de un servicio diferente.

Con las rutas de API, puedo hacer todas estas cosas desde una sola base de código. Crearías una página, /API/enviar-boletin, y es la forma en que puedes ocultar todas las cosas que están sucediendo aquí para mi usuario. Entonces, no estás revelando tu API de terceros, no estás revelando tu microservicio o patrón de arquitectura. Y también, lo más importante, no estás filtrando datos sensibles, porque eso es algo que no quieres hacer. Supongo 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.

Otro caso de uso interesante, que también anoté aquí, es que incluso puedes usar GraphQL. Este es uno de los mayores beneficios que veo aquí, usar esto junto con GraphQL. Y este es un caso de uso realmente interesante, específicamente porque GraphQL simplifica las cosas para la mayoría de nosotros, porque podemos tener una ruta de API que es una ruta de API de GraphQL, porque GraphQL es una sola API. Y desde allí podemos hacer todas nuestras cosas de ida y vuelta, toda nuestra limpieza, toda la normalización de datos, asegurarnos de que todos nuestros patrones estén allí. Entonces realmente nos ayuda a simplificar las cosas. Así que volvamos al código y veamos cómo se ve. Tenemos nuestros puntos finales de GraphQL. Simplemente creamos un punto final, páginas /API/GraphQL. Y aquí, definimos un esquema. Uh, defines tus resolutores y tus resolutores probablemente serán solo llamadas a API en algún lugar. Entonces esto probablemente sería, um, return call microservice, microservicio X. Ya sabes cómo va. Probablemente estés creando resolutores. Estás diciendo qué microservicios necesitas llamar, y luego realmente creas tu esquema. Realmente vas a crear un esquema ejecutable. Y antes de ir a esto, vamos aquí. Lo que estoy haciendo aquí, uh, estoy creando mi esquema ejecutable, pero también estoy ejecutando middleware, que en realidad es una característica muy agradable porque, uh, la forma en que crearon las rutas de API para asegurarse de que sean compatibles con middleware, uh, para conectar diferentes servicios. Como ya sabemos de Express. Ahora puedo usar Express GraphQL y básicamente cualquier otro middleware de Express para mi ruta de API. Entonces no hay necesidad real de iniciar un servidor Express. Puedes hacer todas estas cosas directamente desde, um, 1API route index s. Entonces te ahorrará una gran cantidad de tiempo de despliegue, de asegurarte de que haya un docker, de asegurarte de que haya todas estas otras cosas y ni siquiera mencionar que es mejor alojarlos.

7. Extensión de rutas de API con Next.js

Short description:

Al utilizar las rutas de API de Next.js, puedes extender tus rutas de API de una manera ejecutable, haciéndolas a prueba de futuro. Puedes crear una API gráfica que se ejecute en una ruta de API, con resolutores, esquema y middleware en un solo directorio. Consulta la documentación para obtener más detalles. También estoy lanzando un curso sobre cómo utilizar las rutas de API de Next.js para construir una API GraphQL sin servidor. Visita mi sitio web para obtener más información y conocer 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 API, también puedes hacerlas sin servidor, lo cual es realmente bueno. Um, una forma realmente buena de hacer esto es que al tenerlo sin servidor, no tienes que preocuparte por cosas como el despliegue, la disponibilidad, estar en funcionamiento. Y por supuesto, Next.js ha sido construido por versa. También tiene soporte para eso. Y también hay nuevas herramientas geniales. Si quieres asegurarte de que tu aplicación y API sin servidor realmente se estén ejecutando, pero eso tal vez lo dejemos para la sesión de preguntas y respuestas. Así que hay middleware en ejecución. Es algo realmente genial porque, al tener esta forma ejecutable de extender tus rutas de API, también lo hace realmente a prueba de futuro, porque todas las cosas que ya se han construido, todas las bibliotecas de código abierto para diferentes API de Express, ya puedes hacerlas ahora desde las rutas de API. Entonces, usando esto, puedo simplemente crear una API gráfica que se ejecute en una ruta de API. Tener todos mis resolutores, tener mi esquema allí. Tener middleware como express-graphical, pero tal vez middleware automático para autenticación, middleware para registro, todo desde un solo directorio. Así que es una característica realmente genial de tener.

Entonces, sí, si quieres aprender más sobre cómo utilizar las rutas de API y Next.js, por supuesto, te recomiendo que consultes la documentación, porque la documentación realmente te ayudará a intentar comprender las rutas de API. Pero además de eso, también estoy lanzando un curso sobre cómo utilizar Next.js con GraphQL en las rutas de API. Así que si estás interesado en este curso, asegúrate de ir a mi sitio web, que es hackteam.io/courses. Y podrás encontrar un enlace para construir la API GraphQL sin servidor con Next.js en este curso. Mostraré, por supuesto, de manera más detallada el código que ya vimos antes. Y también aprenderemos algunos trucos nuevos y geniales sobre las rutas de API de Next.js, y sobre todo, GraphQL. Así que construiremos cosas geniales, como el seguimiento de red en el backend, pero también cómo manejar estas rutas de API en Next.js. Y, sobre todo, también aprenderemos cómo desplegarlas sin servidor. Así que si quieres aprender más sobre Next.js, asegúrate de visitar el sitio web de Next.js para obtener más información sobre mis cursos. Por favor, visita mi sitio web. Y sobre todo, si quieres aprender más sobre React, GraphQL, TypeScript y cosas así, asegúrate de seguirme en Twitter o encontrar mis videos en YouTube. Y luego, espero que hayas disfrutado mucho de la conferencia hasta ahora, y que sigas disfrutando de las charlas de la conferencia que están por venir. Porque si miro el programa, veo que hay personas realmente interesantes hablando sobre cosas realmente geniales. Así que asegúrate de quedarte. Y espero ver tus preguntas en Twitter, o tal vez de alguna otra manera en la que puedas 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

React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
Top Content
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!
Vue.js London Live 2021Vue.js London Live 2021
24 min
Local State and Server Cache: Finding a Balance
Top Content
How many times did you implement the same flow in your application: check, if data is already fetched from the server, if yes - render the data, if not - fetch this data and then render it? I think I've done it more than ten times myself and I've seen the question about this flow more than fifty times. Unfortunately, our go-to state management library, Vuex, doesn't provide any solution for this.For GraphQL-based application, there was an alternative to use Apollo client that provided tools for working with the cache. But what if you use REST? Luckily, now we have a Vue alternative to a react-query library that provides a nice solution for working with server cache. In this talk, I will explain the distinction between local application state and local server cache and do some live coding to show how to work with the latter.
React Summit 2023React Summit 2023
27 min
The New Next.js App Router
Next.js 13.4 recently released the stable version of the "App Router" – a transformative shift for the core of the framework. In this talk, I'll share why we made this change, the key concepts to know, and why I'm excited about the future of React.
React Advanced Conference 2023React Advanced Conference 2023
28 min
A Practical Guide for Migrating to Server Components
Server Components are the hot new thing, but so far much of the discourse around them has been abstract. Let's change that. This talk will focus on the practical side of things, providing a roadmap to navigate the migration journey. Starting from an app using the older Next.js pages router and React Query, we’ll break this journey down into a set of actionable, incremental steps, stopping only when we have something shippable that’s clearly superior to what we began with. We’ll also discuss next steps and strategies for gradually embracing more aspects of this transformative paradigm.

Workshops on related topic

GraphQL Galaxy 2021GraphQL Galaxy 2021
140 min
Build with SvelteKit and GraphQL
Top Content
Featured WorkshopFree
Have you ever thought about building something that doesn't require a lot of boilerplate with a tiny bundle size? In this workshop, Scott Spence will go from hello world to covering routing and using endpoints in SvelteKit. You'll set up a backend GraphQL API then use GraphQL queries with SvelteKit to display the GraphQL API data. You'll build a fast secure project that uses SvelteKit's features, then deploy it as a fully static site. This course is for the Svelte curious who haven't had extensive experience with SvelteKit and want a deeper understanding of how to use it in practical applications.

Table of contents:
- Kick-off and Svelte introduction
- Initialise frontend project
- Tour of the SvelteKit skeleton project
- Configure backend project
- Query Data with GraphQL
- Fetching data to the frontend with GraphQL
- Styling
- Svelte directives
- Routing in SvelteKit
- Endpoints in SvelteKit
- Deploying to Netlify
- Navigation
- Mutations in GraphCMS
- Sending GraphQL Mutations via SvelteKit
- Q&A
React Advanced Conference 2022React Advanced Conference 2022
95 min
End-To-End Type Safety with React, GraphQL & Prisma
Featured WorkshopFree
In this workshop, you will get a first-hand look at what end-to-end type safety is and why it is important. To accomplish this, you’ll be building a GraphQL API using modern, relevant tools which will be consumed by a React client.
Prerequisites: - Node.js installed on your machine (12.2.X / 14.X)- It is recommended (but not required) to use VS Code for the practical tasks- An IDE installed (VSCode recommended)- (Good to have)*A basic understanding of Node.js, React, and TypeScript
GraphQL Galaxy 2022GraphQL Galaxy 2022
112 min
GraphQL for React Developers
Featured Workshop
There are many advantages to using GraphQL as a datasource for frontend development, compared to REST APIs. We developers in example need to write a lot of imperative code to retrieve data to display in our applications and handle state. With GraphQL you cannot only decrease the amount of code needed around data fetching and state-management you'll also get increased flexibility, better performance and most of all an improved developer experience. In this workshop you'll learn how GraphQL can improve your work as a frontend developer and how to handle GraphQL in your frontend React application.
React Summit 2022React Summit 2022
173 min
Build a Headless WordPress App with Next.js and WPGraphQL
Top Content
WorkshopFree
In this workshop, you’ll learn how to build a Next.js app that uses Apollo Client to fetch data from a headless WordPress backend and use it to render the pages of your app. You’ll learn when you should consider a headless WordPress architecture, how to turn a WordPress backend into a GraphQL server, how to compose queries using the GraphiQL IDE, how to colocate GraphQL fragments with your components, and more.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
GraphQL Galaxy 2020GraphQL Galaxy 2020
106 min
Relational Database Modeling for GraphQL
Top Content
WorkshopFree
In this workshop we'll dig deeper into data modeling. We'll start with a discussion about various database types and how they map to GraphQL. Once that groundwork is laid out, the focus will shift to specific types of databases and how to build data models that work best for GraphQL within various scenarios.
Table of contentsPart 1 - Hour 1      a. Relational Database Data Modeling      b. Comparing Relational and NoSQL Databases      c. GraphQL with the Database in mindPart 2 - Hour 2      a. Designing Relational Data Models      b. Relationship, Building MultijoinsTables      c. GraphQL & Relational Data Modeling Query Complexities
Prerequisites      a. Data modeling tool. The trainer will be using dbdiagram      b. Postgres, albeit no need to install this locally, as I'll be using a Postgres Dicker image, from Docker Hub for all examples      c. Hasura