Eliminando BFFs con GraphQL y Next.js

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,

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

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

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.

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

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.