¿Sin código? ¡Sin problema! Cómo los servidores GraphQL fallan y cómo fortalecer tus resolvers

Rate this content
Bookmark
Slides

Los servidores GraphQL son componentes críticos de tu infraestructura y deben ser altamente disponibles, confiables y tolerantes a fallos. Esta charla demuestra cómo aprovechar el filtro de proxy GraphQL Envoy de Solo.io para implementar puntos finales GraphQL a prueba de balas que sean confiables, seguros y amigables para los desarrolladores. ¡Todo esto sin escribir ningún código!

20 min
08 Dec, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Discutimos los servidores GraphQL, su estado actual y cómo fortalecer los resolvers. La charla explora el funcionamiento de los resolvers, el manejo de las interrupciones del servidor y la implementación de la verificación pasiva de la salud. También profundiza en el papel de las pasarelas de API, los proxies y los resolvers declarativos en la mejora del manejo del tráfico de red. Se demuestra el uso de JQ para la transformación de datos y la detección de valores atípicos. La charla concluye con la importancia de los resolvers resilientes y la participación en la comunidad GraphQL.

Available in English

1. Introducción a GraphQL y Resolvers

Short description:

Estamos aquí para hablar sobre GraphQL, sin código, sin problema, cómo se rompen los servidores de GraphQL y cómo fortalecer tus resolvers. Discutiremos el estado actual de los servidores de GraphQL, cómo fallan los resolvers programáticos y cómo solucionarlos. Además, exploraremos los resolvers declarativos y demostraremos su funcionalidad.

♪♪ Gracias por unirse a nosotros. Estamos aquí para hablar sobre GraphQL, sin código, sin problema, cómo se rompen los servidores de GraphQL y cómo fortalecer tus resolvers. Así que, primeras presentaciones, mi nombre es Kevin. He estado aquí en solo.io durante varios años, trabajando en una amplia variedad de proyectos pero relevante para lo que estamos hablando hoy, un gran defensor de nuestro Envoy en GraphQL y Envoy Filter y proyectos relacionados. Y hoy nos acompaña amablemente Sai.

Sí, hola, soy Sai. Soy un ingeniero de software en solo.io. Junto con Envoy, Istio y Flagger, he contribuido a varios proyectos de open-source, incluyendo Glue, y también estoy aquí hablando sobre GraphQL. Soy uno de los ingenieros líderes del esfuerzo de GraphQL y service mesh aquí en solo.io. Y hablando de solo.io, ¿quiénes somos exactamente? Somos una startup en Cambridge, Massachusetts, y nos consideramos líderes de la industria en networking de aplicaciones, service mesh, y tecnologías modernas de API gateway. Y más recientemente, GraphQL, pero continuemos.

Entonces, sí, los objetivos para hoy. Queremos hablar sobre el estado actual de los servidores de GraphQL, específicamente los resolvers. ¿Cómo fallan los resolvers programáticos? ¿Cómo los solucionamos? Luego queremos echar un vistazo concreto a los resolvers declarativos, cómo podrían funcionar y demostrarlo. Solo vamos a verlo en acción.

2. Estado actual de los servidores de GraphQL

Short description:

Tenemos un cliente móvil simple que realiza una solicitud GraphQL a un servidor GraphQL. El servidor resuelve la solicitud de pagos y servicios de planes. Hay tres réplicas de cada servicio. El servidor GraphQL reconcilia los datos y los devuelve en una respuesta GraphQL singular.

Así que vamos directo al grano. El estado actual de las cosas. Quiero decir, esto es una conferencia de GraphQL. Todos deberíamos estar familiarizados con esto, pero solo para recapitular. Aquí a la izquierda, tenemos un cliente móvil simple que realiza una solicitud GraphQL a un servidor GraphQL. Este servidor aquí resuelve la solicitud para un servicio de pagos y planes, como un servicio telefónico, por ejemplo. Tenemos tres réplicas del servicio de pagos y tres réplicas del servicio de planes como se indica en las líneas punteadas. Este servidor GraphQL resuelve algunos campos en el servicio de pagos y otros en el servicio de planes, los reconcilia a través del esquema y devuelve todos los data aquí a la derecha en esa única respuesta GraphQL.

3. Working of Resolvers and Handling Server Outages

Short description:

Tenemos un único resolvedor para el servicio de planes, que devuelve una respuesta JSON estándar al servidor GraphQL. Tenemos tres réplicas del servicio de planes, elegidas al azar para equilibrar la carga. En caso de una interrupción del servidor, una de las réplicas puede devolver un tiempo de espera de solicitud, lo que provoca errores y datos incompletos. Para minimizar el problema, podemos implementar sondas de preparación y supervivencia, como realizar solicitudes HTTP GET al servicio en /health y monitorear las fallas.

Así que vamos a sumergirnos en ello, tenemos un único resolvedor aquí. Así que solo quería centrarme en el servicio de planes. Puedes ver aquí que devuelve como una respuesta JSON estándar a nuestro servidor GraphQL. Y el servidor sabrá en el motor de ejecución cómo poner eso de nuevo en tu esquema y enviar la respuesta de vuelta.

En particular, me gustaría centrarme en cómo esto está funcionando un poco por debajo. Como mencioné antes, tenemos tres réplicas del servicio de planes aquí. Ahora, cuando tenemos tres réplicas, simplemente elegimos una al azar para equilibrar la carga. Para ser concretos, usaré Kubernetes como ejemplo aquí, pero tu infraestructura tiene algún tipo de lógica equivalente en algún lugar si estás, ya sabes, eligiendo entre tres servicios de una réplica para satisfacer las demandas de escalado de tu infraestructura.

En el ejemplo de Kubernetes aquí, el código del resolvedor podría verse así. Tienes un cliente HTTP que intenta hacer una solicitud, una solicitud GET con parámetros de consulta a esa entrada DNS. En el ejemplo de Kubernetes, resolviste eso a través de DNS para obtener ese servicio de IP de clúster correcto, en el servicio de Kubernetes, y esa IP de clúster es una IP virtual que se resuelve a través del equilibrio de carga a una de estas tres IP para los pods. La clave aquí es que estamos eligiendo al azar uno de estos tres pods para golpear realmente una de estas tres réplicas del servicio.

Ahora, si pensamos en las interrupciones del servidor, supongamos que una de esas tres réplicas se cae por cualquier motivo. Podríamos decir falla de hardware, error en el código que es una fuga de memoria, bloqueo, lo que sea. Lo que esto significará en la práctica es que cuando el servidor GraphQL resuelva esa solicitud, una de esas tres réplicas volverá con un tiempo de espera de solicitud, y luego el cliente verá errores. La interfaz de usuario obtendrá datos incompletos. Esto obviamente es malo y algo que queremos evitar. Entonces sí, como mencioné, queremos minimizar el problema. ¿Cómo podemos hacer esto? Así que mirando un ejemplo, sé que me apoyé en Kubernetes antes, esto es solo para hacer las cosas concretas. Pero nuevamente, esto es algo que probablemente tu infraestructura tenga de alguna forma u otra, y es posible que simplemente no estés al tanto. Aquí, vamos a ver qué hacen las sondas de preparación y supervivencia. Nuevamente, los escenarios que esto intenta resolver son principalmente cosas como una fuga de memoria, bloqueo de tu código, o incluso simplemente una falla de hardware, volver a programar las cosas. La esencia de esto es que en Kubernetes, al menos tienes un pod, tienes un proceso aquí. En este ejemplo, tenemos una sonda de supervivencia, y lo que hace es hacer una solicitud HTTP GET a tu servicio en /health. Espera tres segundos antes de hacer la primera solicitud, y lo más importante, hace una solicitud cada tres segundos. Y así está simplemente haciendo una encuesta todo el tiempo. Y si comienza a ver fallas, sabe que tu servicio no está saludable. Realmente no le importa la razón, solo sabe que no está saludable y probablemente sea mejor reiniciar reiniciar el proceso, moverlo a otro hardware. Y nuevamente, esta es la forma de Kubernetes, pero esto se puede hacer de varias formas diferentes, un vigilante, algún tipo de monitor de procesos, infiltrado por puppet. Y gran parte de esto está fuera del ámbito de la conferencia de GraphQL, pero esto probablemente exista de alguna forma. Entonces nuestro objetivo es minimizar el problema.

4. Passive Health Checking and Resolvers

Short description:

¿Podemos hacer más? Tenemos un mecanismo de sondeo, pero consideremos un escenario con una API ocupada. Podemos implementar una verificación de salud pasiva utilizando código de resolutor que esté instrumentado con conocimiento de IPs y DNS. Cuando el servidor GraphQL se inicia, obtenemos todas las IPs detrás de nuestro servicio y elegimos una IP saludable al azar para enrutar las solicitudes. Si recibimos una respuesta que no está bien, la marcamos como no saludable. El desafío es dónde colocar esta lógica en nuestro servidor GraphQL. Podemos explorar opciones como middleware del servidor GraphQL, servidor DNS o un proxy local. Los resolutores idealmente deberían ser livianos y no estar cargados con preocupaciones como el circuit breaking y la autenticación. Es mejor mantener estas preocupaciones locales y considerar el uso de un proxy con conocimiento contextual o integrar el servidor GraphQL con un proxy o infraestructura existente como API Gateway y Service Mesh.

¿Podemos hacer más? Ya sabes, tenemos este mecanismo de sondeo cada tres segundos, pero pensemos en el escenario donde tenemos una API muy ocupada. Por eso tenemos réplicas. Estábamos recibiendo miles de solicitudes. Eso es bastante lento. Nos llevará un tiempo, ya sabes, inyectar esos puntos finales y realmente servir respuestas saludables a nuestro cliente.

Entonces, ese mecanismo de sondeo activo es como una verificación de salud activa. Estoy seguro de que hemos oído hablar de circuit breaking antes, pero otra forma de resolver esto es mediante una verificación de salud pasiva. Y así, un seudocódigo muy simple a la izquierda sobre cómo podría funcionar esto, solo para repasarlo juntos, es decir, supongamos que nuestro código de resolutor está instrumentado con algún conocimiento de las IPs y DNS. Y lo que podríamos hacer es, ya sabes, cuando el servidor GraphQL se inicia, obtenemos todas las IPs detrás de nuestro servicio, tenemos todas nuestras réplicas. Luego, cuando resolvemos, simplemente elegimos una IP saludable al azar y la enrutamos. Y si resulta que recibimos una respuesta que no está bien, entonces la expulsamos, la marcamos como no saludable, y la próxima vez no lo intentaremos. Luego, podemos, ya sabes, volver a marcarla como saludable después de un tiempo de espera, pero la clave de esto es que, si estamos recibiendo miles de solicitudes por segundo, podemos instruir a nuestro servidor para que diga, `oye, si tienes cinco errores seguidos, como deja de intentarlo, ¿sabes? Como que este punto final probablemente no está bien, nuestro resolutor puede hacerlo mucho mejor, ser más inteligente y no enviar solicitudes a esta réplica que sabe que probablemente no funcionará. Ahora, obviamente, este código no está listo para producción, definitivamente no quieres instrumentar tus resolutores con este tipo de lógica, pero esta lógica debe estar en algún lugar. Si queremos incorporar esto en nuestro servidor GraphQL, ¿dónde lo colocamos? Podría estar en algún tipo de middleware del servidor GraphQL detrás de tu servidor GraphQL, podríamos intentar mover partes de él a un servidor DNS, malo por otras razones, podríamos usar un proxy local de nodo, otro balanceador de carga, hay muchas opciones aquí, podemos profundizar.

Simplemente retrocediendo un poco, así que hemos visto el circuit breaking aquí como ejemplo, pero el problema aquí es que GraphQL es un único punto final, es un único servidor que vive en un nodo que tiene que ser responsable de muchas responsabilidades antes de enviar solicitudes a servicios secundarios. Entonces, si estoy operando un servidor GraphQL e implementando resolutores, a veces tengo que instrumentarlos con cosas como preocupaciones de failover, circuit breaking, como acabamos de hablar, una política de reintento, autorización, autenticación, límites de velocidad. Puedes ver aquí a la izquierda nuestro resolutor ideal. Queremos que los resolutores sean livianos, muy simples de leer y comprender. Pero a menudo vemos resolutores instrumentados con cosas como las de la derecha, aquí tenemos comprobaciones de autenticación, para asegurarnos de que tienes permiso para acceder al backend. Pero esto no es ideal. Además, algunas de estas preocupaciones que estamos hablando y que deben ser manejadas en el nodo, como el hardware mismo en el que reside el servidor GraphQL. Por ejemplo, como el circuit breaking. Si quisiéramos mover esto a otro hardware, estaríamos introduciendo otro punto de falla. Más puntos de falla en la red, eso es más difícil de comprender. Son sistemas distribuidos, es mucho mejor si lo mantenemos local. Entonces, mencionamos algunas de esas opciones, podríamos considerar agregar otro proxy que tenga este tipo de conocimiento contextual en el mismo hardware. Así que puedes tener un servidor GraphQL que luego enrutará a un proxy local y ese proxy tendrá ese conocimiento de circuit breaking y autenticación y enrutará a los servicios secundarios. O podríamos juntarlos. ¿Y si fueran una sola cosa? ¿Y si pensamos en nuestro servidor GraphQL como algo menos de un servidor y más como un protocolo o una capa que existe en nuestro proxy preexistente o infraestructura? Esto se adentra un poco en las ideas que tengo sobre API Gateway y Service Mesh. Esto es un poco de lo que hace Solo y tal vez sea nuevo para muchos de ustedes que asisten a una charla sobre GraphQL.

5. API Gateways, Proxies, and Declarative Resolvers

Short description:

Discutimos el papel de las API Gateways y los proxies inversos en el manejo del tráfico de red. Service mesh es un concepto más nuevo que utiliza proxies similares para el enrutamiento dentro de una red. Exploramos los beneficios de fusionar servidores GraphQL con proxies, como el almacenamiento en caché, la autorización y el enrutamiento. Los resolutores declarativos se ilustran con ejemplos de solicitudes REST y gRPC. JQ se presenta como un lenguaje de plantillas para construir datos durante el tiempo de ejecución. Resuelve el problema de que GraphQL no funcione nativamente con respuestas de pares clave-valor.

Pero la idea real aquí a la izquierda, por ejemplo, es que si piensas en las solicitudes que entran y salen de tu empresa, tu red, generalmente tienes algo en el borde, esta cosa en el borde se llama una API Gateway o a veces detrás de un balanceador de carga. Es responsable de cosas como un firewall y prevenir fugas de datos personales. Ese tipo de lógica se implementa en un montón de proxies inversos. Por ejemplo, NGINX, Envoy proxy, HAProxy, y luego maneja enrutamiento complejo, failover, circuit breaking a tus servicios backend, ya sean microservicios monolíticos o funciones en la nube o clústeres de Kubernetes. Realmente, el único punto que quería mencionar es que tienes proxies inversos y es probable que ya existan en tu infraestructura, ya sea que estés consciente de ellos o no.

Del mismo modo, eso maneja lo que llamaríamos norte-sur, sabes, dentro o fuera de tu tráfico de red. A la derecha, también tenemos la idea de service mesh. Esto es aún más incipiente o nuevo, pero esto utiliza conjuntos similares de proxies, como Envoy, NGINX, HAProxy, para manejar el enrutamiento entre servicios dentro de tu red. Así que piensa en la observabilidad estandarizada, métricas, trazabilidad, así como, ya sabes, casos de uso comunes, encriptación en todas partes, redes de confianza cero, y tu infraestructura puede tener esto ya y es posible que ya tengas un proxy Anhui, ya sabes, junto a todos tus servicios sin siquiera saberlo.

Así que hablamos un poco sobre los problemas que estamos viendo actualmente con los resolutores y nuestro modelo de implementación actual y muchos servidores GraphQL donde es posible que necesites tener un proxy frente a él o un proxy inverso frente a tu servidor GraphQL actual y hablamos sobre cómo podemos fusionar el servidor GraphQL y el proxy juntos. Y hablemos un poco sobre cómo funciona esto y cuáles son los beneficios de hacerlo realmente. Ahora que tenemos nuestro servidor GraphQL como parte de nuestro proxy, obtenemos muchos beneficios que antes venían solo de tener proxies, como el almacenamiento en caché, la autorización, la autenticación, la limitación de velocidad, el firewall de aplicaciones web, así como el enrutamiento del tráfico, el tráfico de GraphQL de los usuarios a los servicios backend. Y también puedes enrutar el tráfico de forma segura a través de TLS a tus servicios backend y tener comunicación segura dentro de tu clúster desde tu proxy, tu API gateway a tus servicios backend. Y hablamos un poco sobre el hecho de que podríamos hacer esto en código, o también podemos hacerlo como configuración. Elegimos hacerlo más como configuración. Y aquí tienes un ejemplo de cómo se ven los resolutores declarativos. Así que en el lado izquierdo, tenemos un resolutor que resuelve una solicitud de GraphQL enrutando, creando una solicitud a un upstream REST. Y a la derecha, tenemos una solicitud gRPC que se está creando. Así que vemos gran parte del esqueleto de cómo se ve exactamente esta configuración declarativa, donde estamos construyendo una solicitud upstream. A la izquierda, vemos un campo de ruta para establecer la ruta hacia el upstream REST, el método HTTP, así como algunos encabezados adicionales que podríamos querer establecer en la solicitud upstream REST. Y a la derecha, vemos, para la solicitud gRPC, tenemos el nombre del servicio, el nombre del método, otros parámetros gRPC que se necesitan para crear una solicitud upstream, así como la referencia real al upstream. En este caso, esto podría ser un servicio Kubernetes, un destino, un servicio externo o algo así. Y luego tenemos este campo JQ. Vamos a profundizar un poco en qué es exactamente JQ, pero esencialmente es un lenguaje de plantillas que nos permite construir datos durante el tiempo de ejecución a partir de nuestra solicitud GraphQL en el protocolo específico que requiere el upstream. En este caso, estamos construyendo la ruta dinámicamente a partir de los argumentos y la consulta de GraphQL. Así que profundicemos un poco en qué es JQ realmente, y podemos enmarcar mejor lo que JQ resuelve al describir un problema. Y en este caso, tenemos un esquema que devuelve una matriz de objetos de revisión, y los objetos de revisión tienen un campo de revisor y calificaciones. Pero luego nuestro upstream responde con datos que se ven así, donde tenemos un montón de pares clave-valor, y básicamente un diccionario que tiene el nombre del revisor y las calificaciones. Ahora, esto no es algo que GraphQL sepa cómo trabajar nativamente. La especificación de GraphQL no incluye este tipo de forma de datos.

6. Using JQ for Transformation and Outlier Detection

Short description:

Utilizamos JQ para transformar los datos de upstream en datos que los servidores GraphQL pueden reconocer. Reutilizar la infraestructura existente y tratar GraphQL como un protocolo mejora la experiencia del desarrollador y la confiabilidad. En una demostración, interactuamos con los servicios a través de una consulta GraphQL, utilizando el gateway de ingreso de Istio y el proxy Envoy. Algunas solicitudes fallan debido a problemas de comunicación con los servicios de upstream. La mitigación implica el uso de una política de detección de valores atípicos para eliminar los servicios no saludables del grupo de puntos finales.

Entonces tenemos el problema de tener que transformar los datos de upstream en datos que los servidores GraphQL realmente puedan reconocer. Y para hacer eso, utilizamos JQ, que es un lenguaje de transformación expresivo. Aquí, mostramos que a través de una serie de filtros, podemos transformar los datos de solicitud o respuesta de upstream en datos que realmente son reconocidos por nuestro esquema y filtro de GraphQL. Recomiendo encarecidamente investigar más sobre JQ, ya que es un lenguaje extremadamente poderoso para transformar JSON. Gracias Sai por brindar un ejemplo concreto aquí.

Mirando desde una perspectiva más amplia, lo que estamos tratando de hacer aquí es simplemente reutilizar la infraestructura existente. Muchas empresas ya tienen API gateways o service mesh y ya tienen implementados estos proxies inversos. Obviamente, aprovechamos nuestra CDN para las consultas en caché y los servicios de respaldo de larga duración, pasándolos a través de suscripciones GRPC de GraphQL. Pero realmente, el sentimiento es que menos es más. Si podemos aprovechar nuestra infraestructura y tratar GraphQL como un protocolo en lugar de un servidor separado, podemos mejorar la experiencia del desarrollador y la confiabilidad.

Sí, veamos esto en la práctica. Veamos una demostración real de cómo funciona en el clúster. Este es nuestro entorno de clúster de Kubernetes. En el lado izquierdo, podemos ver una interfaz de usuario para interactuar con nuestro clúster, y en nuestro clúster tenemos un servicio en ejecución llamado página de producto. Ahora tenemos la versión uno y la versión dos de la página de producto en ejecución. Ahora queremos interactuar y obtener una respuesta de estos servicios a través de una consulta GraphQL, y podemos hacerlo a través del gateway de ingreso, que se está ejecutando aquí. Puedes ver que es el gateway de ingreso de Istio, y eso se ejecuta en Envoy. Si revisamos la imagen en el manifiesto, verás que se está ejecutando nuestro proxy Envoy, y dentro del proxy Envoy hay un filtro de GraphQL. Si envío una solicitud GraphQL, que debería ser familiar para el proxy Envoy, verás que recibimos una respuesta con los datos que queremos. Ahora agreguemos un poco más de detalles a esta solicitud, y obtendremos una respuesta como esta. Es posible que hayas notado que algunas de nuestras solicitudes están fallando. Y están fallando con el mensaje 'rest resolver got response status 503 from the upstream'. Esto significa que nuestro filtro de GraphQL no puede comunicarse con uno de nuestros servicios de upstream, y esto es esperado. Si observamos las imágenes utilizadas en estas dos implementaciones diferentes del servicio de página de producto, una de las imágenes es en realidad una imagen de curl no receptiva, lo que significa que si enviamos cualquier tipo de tráfico a ella, no responderá con ningún dato. Pero la otra imagen es un servicio real, nuestro servicio de reserva para una página de producto proporcionado por Istio. Entonces, lo que realmente está sucediendo aquí es que nuestro tráfico está siendo balanceado implícitamente por Kubernetes entre los dos servicios backend para nuestro servicio de página de producto. ¿Cómo mitigamos este comportamiento? Bueno, podemos usar una política de detección de valores atípicos, que nos permite eliminar los servicios no saludables del grupo de puntos finales a los que se dirigen las solicitudes de GraphQL en el upstream. ¿Cómo se ve esta política de detección de valores atípicos? Se ve algo así. Dice que podemos aplicar esta política de detección de valores atípicos a nuestros servicios y decir que si nuestros servicios reciben al menos un error consecutivo, queremos eliminar esa instancia particular del servicio del grupo de nodos saludables o del grupo de puntos finales saludables. Así que vamos a aplicar esta política de detección de valores atípicos.

7. Resilient Resolvers and Engagement

Short description:

Observamos que el campo de estado se actualiza a 'estado aceptado', lo que indica un procesamiento exitoso. El servicio defectuoso, página de producto V2, se elimina del grupo de puntos finales saludables al recibir un error 503. Después de 60 segundos, se vuelve a agregar el punto final para verificar si es necesario volver a interrumpir el circuito. Nuestros resolvers se vuelven resilientes con conmutación por error, reintentos y otras políticas. Gracias por recibirnos en GraphQL Galaxy. Únete a nuestro Slack público y síguenos en Twitter para mayor participación.

Podemos continuar y echar un vistazo a la política, esperar a que se actualice el campo de estado, lo que significa que sabemos que nuestro sistema lo ha procesado. Ahí vamos, y podemos ver el campo de estado se actualiza aquí mismo. Eso dice estado aceptado. Entonces, ahora lo que deberíamos ver es que podemos seguir haciendo curl a nuestro servicio, y en el momento en que reciba un 503, el servicio defectuoso, la página de producto V2, se eliminará del grupo de puntos finales saludables. Entonces, ahora el resto de nuestras solicitudes deberían estar completamente saludables, y verás que estamos recibiendo los data que esperamos.

Ahora hay una cosa más, y eso es el tiempo de inyección base. Eso significa cuánto tiempo el punto final estará expulsado del grupo de puntos finales saludables. Todo esto dice es que después de 60 segundos, el punto final se volverá a agregar para ver si es necesario volver a interrumpir el circuito, o si el punto final está saludable nuevamente. Y así es como hemos hecho que nuestros resolvers sean muy resilientes contra los servicios en el backend que se caen. No lo demostré en esta demostración, pero podemos agregar cosas como conmutación por error, reintentos, y otras políticas que hacen que nuestros resolvers sean súper resilientes.

Y esa fue nuestra demostración. Así que en nombre de solo.io y Kevin y yo, solo queríamos decir gracias por recibirnos aquí en GraphQL Galaxy. Únete a nosotros en nuestro Slack público y síguenos en Twitter. Estamos muy contentos de continuar la discusión allí y participar con ustedes en la community. ♪ Hey, hey, hey, hey, hey, hey, hey, hey, hey, hey ♪

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 Advanced Conference 2023React Advanced Conference 2023
27 min
Simplifying Server Components
Server Components are arguably the biggest change to React since its initial release but many of us in the community have struggled to get a handle on them. In this talk we'll try to break down the different moving parts so that you have a good understanding of what's going on under the hood, and explore the line between React and the frameworks that are built upon it.
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 Day Berlin 2023React Day Berlin 2023
21 min
Exploring React Server Component Fundamentals
I've been developing a minimalistic framework for React Server Components (RSC). This talk will share my journey to deeply understand RSC from a technical perspective. I'll demonstrate how RSC features operate at a low level and provide insights into what RSC offers at its core. By the end, you should have a stronger mental model of React Server Components fundamentals.
React Summit 2023React Summit 2023
26 min
Server Components: The Epic Tale of Rendering UX
Server components, introduced in React v18 end these shortcomings, enabling rendering React components fully on the server, into an intermediate abstraction format without needing to add to the JavaScript bundle. This talk aims to cover the following points:1. A fun story of how we needed CSR and how SSR started to take its place2. What are server components and what benefits did they bring like 0 javascript bundle size3. Demo of a simple app using client-side rendering, SSR, and server components and analyzing the performance gains and understanding when to use what4. My take on how rendering UI will change with this approach
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