¿Cómo implementarías una caché GraphQL de alto rendimiento? ¿Cómo podemos diseñar un buen algoritmo para ello? ¿Existe una solución de código abierto eficiente, escalable y fácil de implementar? ¿Cómo se calcula la clave de caché? ¿Qué hay de las invalidaciones de caché? ¿Sería posible deduplicar la ejecución del resolvedor? Esto puede parecer desalentador, pero en realidad todo se reduce a código y algoritmos.
En esta charla vamos a explorar un sistema de caché GraphQL que hemos desarrollado para Mercurius, uno de los servidores GraphQL más rápidos para Node.js.
This talk has been presented at GraphQL Galaxy 2021, check out the latest edition of this Tech Conference.
FAQ
Matteo Collina es un Arquitecto de Software Principal en NearForm y forma parte del Comité Técnico de Dirección de Node.js.
Matteo Collina habla sobre Node.js, JavaScript, GraphQL, código abierto y otras tecnologías relacionadas.
Fastify es uno de los frameworks web más rápidos para Node.js, fácil de usar y más moderno que Express. Se utiliza junto con Mercurius, un adaptador de GraphQL para Fastify, para mejorar el rendimiento de las puertas de enlace de GraphQL.
Mercurius es un adaptador de GraphQL que se puede ejecutar sobre Fastify y ofrece características como la integración con la biblioteca GraphQL JIT para compilación en tiempo real de consultas, lo que mejora la velocidad de ejecución.
AutoCANON es una herramienta de pruebas de carga en JavaScript desarrollada por Matteo Collina, utilizada para mejorar el rendimiento de las aplicaciones al permitir pruebas de carga más efectivas.
La deduplicación en GraphQL, implementada mediante el módulo AsyncCacheDedupe, permite que las llamadas a resolver que tienen la misma clave de caché compartan una única promesa de resultado, reduciendo la necesidad de ejecuciones duplicadas y mejorando el rendimiento.
Matteo Collina sugiere el uso de técnicas como la deduplicación y la caché con AutoCANON, además de considerar la implementación de cachés compartidas usando sistemas como Redis para manejar estados compartidos entre múltiples nodos.
Una buena clave de caché para un resolvedor en GraphQL se puede generar combinando información de los argumentos del resolvedor, el contexto y el objeto de info utilizando un módulo como save-stable-stringify, que genera JSON estables independientemente del orden de las propiedades.
La charla de hoy se centra en la caché de GraphQL y en mejorar el rendimiento utilizando Fastify y Mercurius. El experimento involucra servicios federados, caché de resolvedores y pruebas de carga con AutoCANON. Habilitar la caché con un TTL de 0 segundos puede aumentar el rendimiento en 4 veces. El módulo AsyncCacheDedupe permite una caché eficiente y evita cálculos innecesarios. La canalización de Redis ha mejorado las solicitudes por segundo en 100 veces. La invalidación de caché es un tema en desarrollo.
Hoy, Matteo Collina hablará sobre la caché de GraphQL y cómo mejorar el rendimiento de tu puerta de enlace de GraphQL en cuatro veces. Utilizará Fastify, uno de los frameworks web más rápidos para Node.js, y Mercurius, el adaptador de GraphQL que se ejecuta sobre Fastify e integra con la biblioteca GraphQL JIT para una ejecución de consultas más rápida.
Hola a todos. Soy Matteo Collina y hoy voy a hablarles sobre la caché de GraphQL. Antes de comenzar, síganme en Twitter en matteocollina. Pueden encontrarlo en la diapositiva, así que aquí estoy. Hablo mucho sobre Node.js, JavaScript, GraphQL, código abierto, todas las cosas, así que no sé, puede que les resulte interesante. Hoy vamos a hablar sobre GraphQL, pero antes de comenzar, oh, una cosa más. Sigan mi boletín, Aventuras en Node-Land, node-land.dev. ¿Quién soy? Soy Matteo, formo parte del Comité Técnico de Dirección de Node.js, y soy Arquitecto de Software Principal en una empresa llamada NearForm. Échennos un vistazo, estamos contratando, haciendo mucho por GraphQL, así que si quieren, es una buena empresa. De todos modos, yendo un poco más lejos, cuando era niño en los años 90, sí, les estoy diciendo cuántos años tengo, estaba realmente, realmente, realmente impresionado por este espectáculo de David Copperfield, y no sé acerca de ustedes, pero siempre quise ser, me fascinaba la magia, ¿verdad? Entonces, y, ya saben, cómo hacer que las cosas desaparezcan, cómo hacer que las cosas, ya saben, vuelen, lo que sea. Es muy, muy interesante y me parecían muy entretenidos los espectáculos. Y de hecho, hay mucho trabajo duro detrás de la magia, ¿verdad? Así que en esta charla, vamos a hablar de magia y vamos a hacer que las cosas desaparezcan. De hecho, vamos a aplicar magia a GraphQL. Así que vamos a mostrar cómo mejorar el rendimiento de tu puerta de enlace de GraphQL en cuatro veces. ¿Cómo? Haciendo que las cosas desaparezcan.
Entonces, ¿cómo? Bueno, hablemos un poco sobre la herramienta del oficio. Necesitamos herramientas, ¿verdad? Necesitamos cosas que vamos a usar para esta pequeña demostración. Así que primero, vamos a usar Fastify. Fastify es uno de los frameworks web más rápidos para Node.js. Es muy fácil de usar. Es similar a Express, pero más moderno, más rápido. Tiene más características. ¡Todas las cosas que necesitarás. Es genial! Échale un vistazo. Vamos a usar Mercurius. Mercurius es el adaptador de GraphQL que puedes ejecutar sobre Fastify. Es genial. Mercurius ofrece algunas características interesantes que lo hacen único. En primer lugar, se integra con la biblioteca GraphQL JIT, para que podamos tomar tu consulta y hacer una compilación en tiempo real para tu consulta,
2. Herramientas, Experimento y Magia
Short description:
Las herramientas discutidas incluyen una biblioteca llamada AutoCANON para pruebas de carga en JavaScript. El experimento involucra dos servicios federados por una puerta de enlace, que ofrecen objetos de usuario y publicación. Se utilizará el compilador en tiempo real y el módulo de caché para habilitar la caché del resolvedor. El servicio es un objeto de usuario simple con un ID y un nombre. Se realizarán pruebas de carga en vivo en hardware dedicado.
para que pueda ejecutarse mucho más rápido. Y así sucesivamente. También hace algunas cosas más como esa para rendimiento y razones de velocidad. Es genial. Así que échale un vistazo. Oh, también admite la federación completa, tanto como puerta de enlace como microservicio. Entonces, la última herramienta del oficio es una biblioteca llamada AutoCANON. AutoCANON es una herramienta que escribí hace mucho tiempo para realizar algunas pruebas de carga. Y puedes usar esto para omitir cosas en JavaScript. Así que es para omitir pruebas de carga en JavaScript. Es genial. Lo uso muchas veces. Estas son nuestras herramientas, ¿verdad? De acuerdo. Entonces vamos a usar estas. Tres cosas. Así que hablemos un poco sobre nuestro experimento. Tenemos dos servicios que están federados por una puerta de enlace. Y uno ofrece el objeto de usuario, y el otro ofrece el objeto de publicación. Y vamos a utilizar el compilador en tiempo real, y habilitaremos la caché para el resolvedor dependiendo de nuestros algoritmos. Así que podemos realizar múltiples experimentos, ¿verdad? Puedes verlo aquí. Puedes realizar múltiples experimentos. Y ver el impacto de este módulo de caché, ¿cómo se ve este módulo? Así que veamos dónde desaparecen o reaparecen las cosas.
¿Cuál es el servicio? Bueno, este es un ejemplo del servicio. Literalmente, es un objeto de usuario que tiene un ID y un nombre. Muy simple, ¿de acuerdo? No hay nada especial aquí.
Así que es hora de hacer un poco de magia. ¿Están listos para la magia? Hagamos que las cosas desaparezcan. ¿Cómo? Bueno, volvamos a nuestra terminal. Así que está conectado a mi servidor. Es
3. Mercurius Cache Repo and Experiments
Short description:
En el repositorio de caché de Mercurius, tenemos pruebas de referencia, servicios de puerta de enlace para datos de usuario y publicaciones, y experimentos utilizando AutoCanon. Ejecutar el script sin caché realiza 3000 solicitudes por segundo. Con un TTL de cero segundos, aumenta 4 veces. Exploremos esto más a fondo.
en hardware dedicado. Así que voy a realizar pruebas de carga en vivo. ¡Oh, wow! Así que veamos mi repositorio de caché de. Todo esto está en el repositorio de caché de Mercurius. Y podemos ver que tenemos nuestras pruebas de referencia y esta es la puerta de enlace que acabo de mostrarte. Y tenemos nuestros servicios de puerta de enlace. Este es el de usuario y este es el de publicaciones. Ten en cuenta que estos servicios sirven todos losdata desde la memoria. Por lo tanto, no hay bases de datos involucradas. Son realmente rápidos. Y este es nuestro banco de pruebas. Entonces, ¿cómo evaluamos el rendimiento de las cosas utilizando AutoCanon? Básicamente, requerimos AutoCanon. Y luego tenemos nuestra consulta, y enviamos nuestra consulta como cuerpo con 100 conexiones concurrentes. Eso es todo. Y luego hacemos varios experimentos utilizando nuestro script de banco de pruebas. Entonces, en nuestro script de banco de pruebas, puedes ver que estamos ejecutando todos los servicios más varias cosas. Varios ejemplos, uno sin caché, uno con un tiempo de vida de cero segundos y uno con un tiempo de vida de un segundo y uno con un tiempo de vida de 10 segundos. Así que vamos a ejecutar este script. Primero que nada, este es nuestro básico, este es nuestro control, ¿verdad? Es un modo de puerta de enlace. Algo donde no vamos a cachear nada. Así que hemos hecho esto, ¡y vaya! Realiza 3000 solicitudes por segundo. Bueno, parece rápido o no, depende de lo que quieras hacer. La latencia es buena, sin embargo. Así que estoy bastante contento con los resultados. Ahora, con un TTL de cero segundos, ¡vaya! ¿Cómo? Simplemente se multiplicó por 4. No estoy haciendo ninguna caché. Es un tiempo de vida de cero segundos. Simplemente lo activo y se multiplica por 4. Y, ¡vaya! Todavía 4 veces. ¿Cómo es esto posible? ¿Cómo funciona esto?
4. Caching and Deduplication
Short description:
Nuestro punto de referencia tiene una latencia P99 de 80 milisegundos, lo que resulta en aproximadamente 3000 solicitudes por segundo. Al habilitar la caché con un tiempo de vida de 0 segundos, podemos reducir la latencia a 18 milisegundos y aumentar el número de registros por segundo y el rendimiento en 4 veces. El gráfico de llamas muestra que la mayor parte del tiempo se dedica ahora a la caché, gracias a la deduplicación. El diagrama del bucle de eventos de Node.js proporciona información sobre el flujo de ejecución y el tiempo de bloqueo entre C++ y JavaScript, que se utiliza para la deduplicación mediante el cálculo de una clave de caché.
OK, dejemos esto ejecutándose. Explicaremos esto en un momento. Entonces, nuestro punto de referencia tiene una latencia P99. Eso es lo que quieres medir para una latencia de 80 milisegundos. Mientras que una solicitud por segundo te da más o menos 3000 solicitudes por segundo.
Sin embargo, también puedo crear gráficos de llamas. ¿Qué es un gráfico de llamas? Bueno, es una representación de dónde se está gastando nuestro tiempo de CPU. Más específicamente, todo ese tiempo se está gastando en hacer solicitudes HTTP. Por cierto, si no has visto mis charlas sobre undici y Node.js, por favor échales un vistazo porque puedes acelerar bastante tus llamadas HTTP.
Pero el resultado es que la gran mayoría del tiempo se gasta haciendo HTTP. Entonces, bueno, ¿qué podemos hacer? Necesitamos reducir el HTTP. Sí, ¿cómo podemos mejorar esto? Bueno, simplemente haciéndolo un tiempo de vida de caché de 0 segundos, podemos reducir la latencia a 18 milisegundos y multiplicar por 4 el número de registros por segundo y el rendimiento. ¡Vaya! Esto es una gran mejora sin tener ninguna caché en absoluto. Cero caché. No es caché en absoluto. Simplemente habilitamos la caché. Bueno, y si habilitamos la caché, no mejora mucho. Bueno, ¿cómo es posible? Bueno, este es el gráfico de llamas de nuestra puerta de enlace ahora. Y como puedes ver en el medio, la solicitud HTTP que estaba allí antes ha desaparecido. Y ahora tenemos en el medio un gran bloque de tiempo que se gasta haciendo la caché, vale. Literalmente, ahora la parte inferior es el sistema de caché. Entonces, ¿pero a dónde fue la llamada HTTP? ¿Dónde desapareció? Bueno, lo que estamos haciendo, estamos haciendo deduplicación, que es la estrategia clara que hará las cosas increíblemente más rápidas, especialmente en el lado gráfico. Así que volvamos y hablemos un poco sobre el bucle de eventos de Node.js. Probablemente hayas visto este diagrama sobre Node. Esto es genial porque has visto que la solicitud llega y sabes que tienes un evento, va a la cola de eventos, se procesa, y luego esto genera más actividad asíncrona. Lo que no has visto es este diagrama. Este diagrama es una presentación diferente del mismo bucle de eventos exacto. Sin embargo, lo muestra desde el punto de vista de la función JavaScript que se está ejecutando. Entonces, cuando el bucle de eventos está en ejecución, está esperando algo, está esperando, ¿verdad? Esto es, a la izquierda y a la derecha, el bucle de eventos está esperando. Luego, cuando ocurre un evento, llama a C++, llama a JavaScript, que normalmente programa algún next-tick o algunas promesas, luego vuelve a C++, que a su vez inicia las promesas y la ejecución de next-tick, y finalmente, una vez que todo eso se ha hecho y se ha resuelto, vuelve y cede el control al evento. Todo el tiempo que lleva entre medias, desde este punto de inicio del C++ hasta el final, es el tiempo en el que el bucle de eventos está bloqueado. Entonces, para hacer la deduplicación de la solicitud, lo que estamos haciendo es, cuando estamos recibiendo nuestra función de resolución, podemos calcular una clave de caché, ¿vale? Y con esa caché
5. Módulo AsyncCacheDedupe
Short description:
El módulo AsyncCacheDedupe te permite calcular la misma clave de caché para un resolvedor y evitar ejecutarlo varias veces. Automáticamente almacena en caché los resultados y proporciona una forma rápida y eficiente de evitar cálculos innecesarios.
clave, podemos crear una promesa coincidente. Entonces, y luego podemos, ya sabes, completar nuestra ejecución, ¿verdad? Sin embargo, cuando llega una ejecución de seguimiento, podemos calcular exactamente la misma clave de caché y obtener la promesa que colocamos allí antes, que aún puede estar pendiente. Sin embargo, no necesitamos ejecutar el mismo resolvedor dos veces. Solo podemos ejecutarlos una vez, ¿verdad? Es bastante genial. Podemos evitar muchos cálculos de esta manera. Esto es lo que hace este módulo. Se llama AsyncCacheDedupe. Creas una nueva caché donde defines algunos métodos en ella y que son asíncronos, y luego automáticamente almacena en caché los resultados. Y podemos tener, puedes tener un TTL, pero automáticamente deduplica y almacena en caché el resultado. Es fenomenal y es muy rápido. Entonces puedes usar esto en todos los demás lugares donde quieras usar el sistema, ¿verdad? Bueno, en primer lugar, pero la pregunta ahora es ¿cómo podemos calcular una buena clave de caché? Porque queremos, para usar este módulo, necesitamos proporcionar una clave de caché y ¿qué es una buena, cómo podemos
6. Implementación de Resolvedores y Caché
Short description:
Al implementar un resolvedor en Node.js, puedes usar cuatro argumentos: root, arguments, context e info. Al combinar la anatomía del resolvedor, el objeto info y otros parámetros, puedes calcular una clave de caché para cada resolvedor de GraphQL. Sin embargo, las cachés en proceso son problemáticas y el uso de Redis como una caché compartida entre nodos puede generar problemas de rendimiento.
¿Cómo obtenemos una buena clave de caché? Bueno, veamos la anatomía de nuestro resolvedor. Cuando implementas un resolvedor en Node.js, puedes tener cuatro argumentos. Tienes el root, tienes los argumentos, tienes el contexto, que es el objeto actual, pero luego tienes los argumentos para el resolvedor, el contexto que puede incluir tu solicitud de Node.js, respuesta, conexiones de base de datos, todas las cosas, y luego el objeto info que incluye la definición de la consulta que estás calculando. Bueno, ten eso en mente y espera un segundo. Ahora, lo que puedes hacer es tomar un objeto arbitrario y convertirlo en JSON, ¿verdad? Puedes llamar a JSON.stringify. Si haces eso, dependiendo del orden de las propiedades, obtendrás diferentes JSON. Sin embargo, hay un módulo llamado save-stable-stringify, que independientemente del orden de las propiedades, siempre generará el mismo JSON. Entonces, lo que podemos hacer es usar este módulo y combinarlo con la anatomía del resolvedor, el info, los datos en el objeto info, el root y todas esas cosas para crear una clave de caché, un hash para un hash arbitrario para ese resolvedor específico.
¿Cómo se implementa esto? Bueno, como puedes ver aquí, es bastante simple. Navegamos por el objeto info para obtener la selección, la selección actual del campo, y luego creamos un objeto que incluye el objeto resuelto actual, los argumentos, los campos y algunos parámetros más. Es genial, ¿ves? Podemos calcular una clave de caché para cada resolvedor de GraphQL. Esto es lo que llamamos TTL de cero segundos. Estamos deduplicando todos los resolvedores que acceden a tus datos. Agregar caché no mejora mucho aquí porque los servicios objetivo son en su mayoría muy simples. No requieren mucho tráfico. Lo siento. No requieren muchas CPUs para calcular. No tienen una base de datos. No tienen nada. Sin embargo, agregar más caché cambiará en caso de que necesites más. Agregar más tiempo aquí mejorará tu rendimiento si los servicios objetivo no son lo suficientemente rápidos o son lentos o algo así. Bueno, todo esto es muy bueno, ¿verdad? Pero las cachés en proceso son problemáticas. Entonces, realmente no podemos aumentar demasiado el tiempo porque todo está en proceso, ¿verdad? Si todo está en proceso, si los datos expiran en mi nodo, no están expirando en el otro nodo. Entonces, ¿cómo podemos implementar eso? Bueno, una de las buenas soluciones es usar algo como Redis para implementar un estado compartido, una caché compartida, entre todos los nodos. Sí, pero lo intentamos y lo implementamos, y no funcionó. Y no funcionó, principalmente porque, ya sabes, en nuestra prueba de referencia, teníamos cien consultas gráficas por segundo, cada una de las cuales invocaba 20 resolvedores. Y esto implica que, ya sabes, si quieres obtener esos datos de la caché, son de doscientos a dos mil Gets de Redis por segundo. Y desafortunadamente, el tiempo de ida y vuelta de Redis es de 0.5 milisegundos.
7. Redis Pipelining y Rendimiento
Short description:
Hemos resuelto el problema del bloqueo sin conexión de cabeza con el auto-pipelining, una técnica que agrupa múltiples comandos en un solo pipeline de Redis, reduciendo el tiempo de ida y vuelta de la red. Esta lógica en producción ha mejorado las solicitudes por segundo en 100 veces y ha ampliado Redis en 15 veces. Redis maneja el tráfico sin problemas. Sin embargo, nombrar cosas e invalidaciones de caché siguen siendo desafíos.
Pero el tiempo real de ida y vuelta es de 15. Así que no se puede hacer mucho. Necesitamos paralelizar estos Gets de Redis, ¿verdad? Entonces, tal vez puedas usar un grupo de conexiones o, no sé. Bueno, hay algo mejor. Bueno, en realidad ya he resuelto este problema. Sí, es con esta figura. De todos modos, echa un vistazo a esta charla que di en RedisConf 2021. Explico cómo resolver el problema del bloqueo sin conexión de cabeza con el auto-pipelining. Entonces, básicamente, es una técnica que hemos inventado para... Bueno, hemos aplicado al cliente de Redis que permite agrupar múltiples comandos que ocurren en la misma iteración del bucle de eventos en un solo pipeline de Redis. De modo que los enviamos como un lote, asegurándonos de reducir el tiempo de ida y vuelta de la red en el servidor. Es genial, y funciona maravillosamente, y puedes realmente acelerar el acceso a Redis. Pero esto es en realidad lo mismo que hacíamos antes con el sincronismo. Así que, es tortugas todo el camino hacia abajo. Días felices.
Así que, tenemos toda esta lógica en producción. Es importante decir que este código en producción nos está dando una mejora de 100 veces en términos de número de solicitudes por segundo. Y tiene un factor de expansión de 15 veces en Redis. Así que, para cada consulta compleja que recibimos en promedio, estamos haciendo 15 Gets de Redis con diferentes claves de caché para verificar si las cosas funcionan como nos gustaría. Es bastante genial, ¿verdad? Pero también es bastante aterrador. Por cierto, Redis ni siquiera parpadea un ojo, ni siquiera parpadea un ojo. Está perfectamente bien con todo este tráfico, así que no nos importa. Redis es increíble, por cierto. Usa Redis. Más Redis para todos.
Así que, eso es lo que tenemos en la vida real. Esta técnica ha sido un salvavidas fenomenal recientemente. Pudimos manejar un pico enorme de tráfico sin siquiera parpadear. Así que, sí, échale un vistazo. Es genial. Sin embargo, hay dos cosas en la ciencia de la computación, ¿verdad?
8. Invalidación de Caché y Conclusión
Short description:
No hemos discutido la invalidación de caché, pero es un tema fundamental. Aunque se me ha acabado el tiempo, estamos trabajando activamente en la implementación de este módulo. Pronto podrás invalidar la caché localmente y en Redis. Mantente atento a las actualizaciones en Twitter y en mi boletín. ¡Gracias por ver!
Uno es nombrar cosas, y el otro es la invalidación de caché. Oh, vamos, está realmente mal, ¿verdad? Porque no hemos hablado de cómo invalidamos la caché, y este es uno de los temas fundamentales. Sin embargo, casi hemos llegado a los 20 minutos, así que se me ha acabado el tiempo. Así que, no los voy a cubrir en esta charla. Estoy bromeando. No hemos terminado de trabajar. No hemos terminado la implementación de este módulo. Pero en realidad estamos trabajando en esto. Así que, en realidad, los añadiremos a AsyncCache.JDube pronto. Por lo tanto, podrás invalidar la caché tanto localmente como en Redis más temprano que tarde. Así que, échale un vistazo, porque estaremos atentos a mis noticias en Twitter y en mi boletín, porque habrá algunos buenos anuncios en las próximas semanas. Con eso, solo quería decirte gracias. Como dije, soy Matteo Collina. Soy el Arquitecto Principal de Software en NearForm. Puedes encontrarme en Twitter, en Matteo Collina. Por favor, hazme cualquier pregunta que quieras en Twitter, y estaré muy feliz de responder tan pronto como pueda. Así que gracias por ver esta charla. ¡Adiós!
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.
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.
The talk discusses the importance of supply chain security in the open source ecosystem, highlighting the risks of relying on open source code without proper code review. It explores the trend of supply chain attacks and the need for a new approach to detect and block malicious dependencies. The talk also introduces Socket, a tool that assesses the security of packages and provides automation and analysis to protect against malware and supply chain attacks. It emphasizes the need to prioritize security in software development and offers insights into potential solutions such as realms and Deno's command line flags.
There is a need for a standard library of APIs for JavaScript runtimes, as there are currently multiple ways to perform fundamental tasks like base64 encoding. JavaScript runtimes have historically lacked a standard library, causing friction and difficulty for developers. The idea of a small core has both benefits and drawbacks, with some runtimes abusing it to limit innovation. There is a misalignment between Node and web browsers in terms of functionality and API standards. The proposal is to involve browser developers in conversations about API standardization and to create a common standard library for JavaScript runtimes.
ESM Loaders enhance module loading in Node.js by resolving URLs and reading files from the disk. Module loaders can override modules and change how they are found. Enhancing the loading phase involves loading directly from HTTP and loading TypeScript code without building it. The loader in the module URL handles URL resolution and uses fetch to fetch the source code. Loaders can be chained together to load from different sources, transform source code, and resolve URLs differently. The future of module loading enhancements is promising and simple to use.
This talk covers various techniques for getting diagnostics information out of Node.js, including debugging with environment variables, handling warnings and deprecations, tracing uncaught exceptions and process exit, using the v8 inspector and dev tools, and generating diagnostic reports. The speaker also mentions areas for improvement in Node.js diagnostics and provides resources for learning and contributing. Additionally, the responsibilities of the Technical Steering Committee in the TS community are discussed.
¿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
Construye Aplicaciones Modernas Utilizando GraphQL y Javascript
Featured Workshop
2 authors
Ven y aprende cómo puedes potenciar tus aplicaciones modernas y seguras utilizando GraphQL y Javascript. En este masterclass construiremos una API de GraphQL y demostraremos los beneficios del lenguaje de consulta para APIs y los casos de uso para los que es adecuado. Se requiere conocimiento básico de Javascript.
En este masterclass, obtendrás una visión de primera mano de lo que es la seguridad de tipo de extremo a extremo y por qué es importante. Para lograr esto, construirás una API de GraphQL utilizando herramientas modernas y relevantes que serán consumidas por un cliente de React. Prerrequisitos: - Node.js instalado en tu máquina (12.2.X / 14.X)- Se recomienda (pero no es obligatorio) utilizar VS Code para las tareas prácticas- Un IDE instalado (se recomienda VSCode)- (Bueno tener) *Un conocimiento básico de Node.js, React y TypeScript
Hay muchas ventajas en utilizar GraphQL como fuente de datos para el desarrollo frontend, en comparación con las API REST. Nosotros, los desarrolladores, por ejemplo, necesitamos escribir mucho código imperativo para recuperar datos y mostrarlos en nuestras aplicaciones y manejar el estado. Con GraphQL, no solo puedes reducir la cantidad de código necesario para la obtención de datos y la gestión del estado, sino que también obtendrás una mayor flexibilidad, mejor rendimiento y, sobre todo, una mejor experiencia de desarrollo. En este masterclass aprenderás cómo GraphQL puede mejorar tu trabajo como desarrollador frontend y cómo manejar GraphQL en tu aplicación frontend de React.
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.
En esta masterclass profundizaremos en el modelado de datos. Comenzaremos con una discusión sobre varios tipos de bases de datos y cómo se mapean a GraphQL. Una vez que se haya establecido esa base, el enfoque se desplazará a tipos específicos de bases de datos y cómo construir modelos de datos que funcionen mejor para GraphQL en varios escenarios. Índice de contenidosParte 1 - Hora 1 a. Modelado de Datos de Bases de Datos Relacionales b. Comparando Bases de Datos Relacionales y NoSQL c. GraphQL con la Base de Datos en menteParte 2 - Hora 2 a. Diseño de Modelos de Datos Relacionales b. Relación, Construcción de Tablas Multijoin c. Complejidades de Consulta de Modelado de Datos Relacionales y GraphQL Prerrequisitos a. Herramienta de modelado de datos. El formador utilizará dbdiagram b. Postgres, aunque no es necesario instalar esto localmente, ya que estaré utilizando una imagen de Dicker de Postgres, de Docker Hub para todos los ejemplos c. Hasura
Comments