Full-stack JS hoy: Fastify, GraphQL y React

Rate this content
Bookmark

Primero hubo LAMP, luego MEAN y JAM. Pero ahora estamos en 2022 y los tiempos han cambiado... ¿Cómo se ve el stack completo moderno? Está construido completamente con tecnologías gratuitas y de código abierto, es escalable más allá de la imaginación, puede ejecutarse en las instalaciones o en la nube, no debe generar dependencia de proveedores y, lo más importante, debe funcionar sin problemas. Hay tantas herramientas para elegir. Elegir el stack correcto desde el primer día puede marcar la diferencia entre el éxito del proyecto y un montón de cenizas de software. Usando fastify, mercurius, urql y react, podemos construir aplicaciones full-stack de alto rendimiento utilizando todas las tecnologías de JavaScript.

25 min
17 Jun, 2022

Video Summary and Transcription

La Charla discute la construcción de una aplicación moderna de stack completo con JavaScript y GraphQL, enfatizando la importancia de priorizar el 20% crítico de los desafíos. Destaca los beneficios de construir un stack tecnológico productivo y transparente con modularidad y herramientas amigables para los desarrolladores. Se recomienda el uso de PostGrey como base de datos relacional y Fastify como framework de servidor. La Charla también explora las ventajas de usar Mercurius y Urql para la implementación de GraphQL. Además, menciona el uso de React, SSR y Fastify Vite para SSR de stack completo y componentes modulares. La Charla concluye mencionando las ventajas de este stack para funcionalidades complejas y la posibilidad de usar Fastify en una infraestructura serverless.

Available in English

1. Building a Modern Full Stack Application

Short description:

Hablaré sobre cómo construir una aplicación de pila completa moderna con JavaScript y GraphQL. Nos centraremos en el último 20% del proyecto, la parte difícil que a menudo pasamos por alto. El Principio de Prado, introducido por Vilfredo Prado, establece que el 80% de nuestros resultados provienen del 20% de los desafíos. Steve Jobs aplicó este principio en Apple, reduciendo el número de modelos de computadoras y dispositivos. Aprendamos de esto y prioricemos el 20% crítico desde el principio.

Estoy muy contento de estar aquí. Gracias a todos. Hablaré sobre cómo construir una aplicación de pila completa moderna con JavaScript y, como pequeño adelanto, hablaremos sobre GraphQL, todo de código abierto, porque eso es lo que amamos. Mi nombre es Cody, trabajo en NearForm, enseño un curso de desarrollo web en la universidad local donde vivo en Francia, pero dejemos de hablar de mí. Lo que realmente quiero hacer es desafiar a todos aquí, hacer un pequeño ejercicio conmigo.

Cierra los ojos e imagina tu próximo proyecto. Tienes todos los requisitos de tus interesados, sabes lo que quieres construir, ¿y qué vas a hacer cuando cierres los ojos? Vas a empezar a pensar en esas herramientas y esos frameworks a los que vas a recurrir. Cuando hago esto y empiezo a pensar en esas herramientas y frameworks, me digo a mí mismo que esta vez será diferente. Esta vez será correcto, esta vez habrá arcoíris y esta vez habrá unicornios.

Creo que todos hacemos eso porque queremos utilizar nuevas tecnologías que nos ayuden, que resuelvan todos esos problemas que tuvimos en nuestro último proyecto. Sin embargo, creo que la trampa está en que podemos llegar al 80% de nuestro proyecto. Cuando llegamos a ese 80%, de repente algo sucede. Esas necesidades no funcionales del mundo real afectan ese último 20%, y ese último 20% es realmente difícil. ¿Dónde nos encontramos? Estamos pensando en arcoíris y unicornios, terminamos con algo como esto. No sé cuántas veces he estado así, tratando de solucionar problemas reales en una aplicación en producción. Tenemos tuberías de CI complejas, tenemos problemas de escalabilidad, tenemos problemas de rendimiento, de seguridad, cosas en las que no pensamos al principio, autorización, autenticación, así que siento que hay una brecha enorme entre lo que imaginamos y la realidad, porque todos somos personas del mundo real solucionando problemas del mundo real. Somos desarrolladores, estamos tratando de hacer lo mejor que podemos, y creo que lo que quiero desafiar hoy es que nos centremos en ese último 20%, en ese difícil 20% que no siempre pensamos al principio.

Así que quiero hablar de este tipo. Este tipo, su nombre es Vilfredo Prado. Lo llamamos el Principio de Prado. Sé que no puedes leer ese texto, pero lo harás en un segundo. Vilfredo Prado, este economista italiano, ideó la regla del 80-20. Sigo hablando de estos porcentajes y él dijo que tal vez solo el 80% de nuestros resultados en nuestros proyectos provengan del 20% de los desafíos, de los requisitos. Eso es lo que quiero desafiarnos a hacer hoy. Pensemos en ese 20% desde el principio. Así es el Principio de Prado en su totalidad. Y creo que Steve Jobs lo sabía. Cuando regresó a Apple en 1996, tenían como 15 modelos de computadoras de escritorio, los redujo a uno. Tenían un montón de dispositivos portátiles, creo que los llamaban laptops en 1996, los redujo a uno. Periféricos, impresoras, los eliminó todos.

2. Building a Productive and Transparent Tech Stack

Short description:

Quiero centrarme en el difícil 20% que puede llevar a un aumento del 80% en la productividad. Construir una pila tecnológica con modularidad nos permite adaptarnos a los requisitos cambiantes. La experiencia del desarrollador es crucial, con herramientas que guían en lugar de obstaculizar. Es importante ejecutar aplicaciones en cualquier lugar, sin depender de servicios en la nube. Los proyectos de código abierto respaldados por la comunidad brindan seguridad y transparencia.

Después de deshacernos de todos ellos. Él quería centrarse en ese último 20 por ciento, ese último 20 por ciento que realmente importaba. Así que hoy, en lo que quiero centrarme, en lo que quiero desafiarnos a centrarnos es en ese difícil 20 por ciento. Y tal vez, solo tal vez, podamos obtener un 80 por ciento en nuestra productividad.

Entonces, ¿cómo podemos construir esta pila tecnológica, esta pila tecnológica mágica, que se va a centrar en ese difícil 20 por ciento, ese 20 por ciento de requisitos no funcionales, ayudarnos a obtener velocidad de entrega y asegurarnos de que nuestra aplicación de calidad de producción funcione de la manera que queremos, que podamos solucionar problemas mientras está en producción? Para hacer eso, quiero establecer algunos principios cuando vaya a construir mi pila tecnológica. Estos son los principios en los que voy a pensar. El primero va a ser la modularidad. Y creo que uno de los desafíos, las trampas en las que podemos caer, es que vamos a buscar ese marco de trabajo que dice que lo hace todo, y pensamos que lo hará todo, pero tal vez no lo haga todo. ¿Qué sucede cuando llegamos a ese momento en el que no hace algo que queremos y tenemos que recurrir a algo más, o desechar el marco de trabajo y comenzar desde el principio? Entonces, si podemos construir una pila tecnológica en la que podamos reemplazar capas de la pila cuando algo no funcione, hemos ganado algo, ¿verdad? Como si nuestra pila de repente se volviera modular y pudiéramos adaptarnos a la situación, a los requisitos a medida que evolucionan.

El siguiente principio en nuestra lista es la experiencia del desarrollador. Por eso estamos aquí. Todos somos desarrolladores. Todos estamos solucionando problemas reales. Quiero herramientas que me ayuden, que me guíen, que no me obstaculicen, ¿verdad? Y quiero poder ejecutar mi aplicación en cualquier lugar. Quiero poder ejecutarla en mi computadora portátil mientras estoy en el tren, cuando no tengo Wi-Fi o en el avión, como si necesitara ejecutarse localmente o en la nube, en el sitio, en Docker, lo que sea. Eso también es muy importante para mí. No quiero depender de algunos servicios en la nube y no poder ejecutar mis pruebas de extremo a extremo en mi máquina porque dependo de esa conexión a Internet que no existe en el hotel. Basado en mis principios, la comunidad es lo primero. Estoy hablando de proyectos de código abierto. Apoyados por la comunidad. Idealmente, serán más seguros, ¿verdad? Porque más personas, más ojos están mirando el código. Los errores se corregirán. Las cosas no se ocultan de ti. Creo que eso es realmente importante cuando se trata de una pila tecnológica. Estoy hablando de un 100% de código abierto. No solo ese 80% y el 20% de la fórmula mágica secreta se ejecuta en un servicio en la nube que nadie puede ver. Quiero ver un 100% de código abierto. Mi último y último principio será la transparencia. Esto está relacionado con el código abierto y esa idea de un proyecto respaldado por la comunidad.

3. Transparencia y Empezar por el Final

Short description:

Amamos las capas de abstracción, pero ¿qué sucede cuando la abstracción no funciona? Hablemos de empezar por el final al construir una pila tecnológica. La pila comienza con PostGrey, una base de datos relacional con la que la mayoría de los desarrolladores están familiarizados.

También la transparencia, cuando hablamos de abstracción. Amamos las capas de abstracción. Eso es lo que facilita nuestras vidas. Eso es lo que nos hace productivos y nos permite desarrollar cosas rápidamente. ¿Qué sucede cuando la abstracción no funciona? Quiero poder quitar esas capas y meter las manos en los detalles más minuciosos. Las partes sucias. Como vimos en ese primer meme de personas arreglando cosas. Quiero poder acceder a esas abstracciones si es necesario. No deberían estar ocultas para mí.

Entonces hablemos de la pila. Ahora la pila. La mayoría de las personas, cuando comenzamos a construir una pila tecnológica, a menudo empezamos desde el frente y avanzamos hacia atrás. Creo que ese enfoque es incorrecto. Si queremos solucionar ese último 20% de los requisitos no funcionales, entonces debemos empezar desde el final. Eso es lo que hoy les desafío a hacer. Así que voy a darle la vuelta al problema por completo. Vamos a empezar por el final. Así que hablemos de la pila.

Verán esta diapositiva con los waffles bastante seguido. Los encontré bastante sabrosos. Así que los veremos a menudo en esta presentación. Entonces, lo primero en la pila, empezamos por el final. Pueden criticarme. Pueden enviarme su correo de odio. Tienen mi nombre de usuario de Twitter ahí. Pero amigos míos, hay un elefante en la habitación. Y el nombre del elefante es PostGrey. ¿Por qué hablaría de PostGrey? PostGrey es increíble porque las bases de datos relacionales, también amo las bases de datos sin esquema basadas en documentos. Pero los desarrolladores lo conocen. Y estoy dispuesto a apostar que en esta sala, cualquiera que tenga un título en ciencias de la computación o ingeniería de software, apuesto a que ha tomado un curso de bases de datos relacionales.

4. PostGrey y Fastify

Short description:

Apuesto dinero a que es así. PostGrey es la mejor base de datos relacional con soporte JSON. El agrupamiento de conexiones permite una escalabilidad increíble. PostGrey proporciona una experiencia de desarrollo potente. Fastify es un servidor que permite construir aplicaciones monolíticas y evolucionar con el código.

Apuesto dinero a que es así. Así que los desarrolladores lo conocen. Puedes agregar desarrolladores a tu proyecto sin muchos desafíos. Y creo que eso es realmente importante.

Lo siguiente, lo digo ahora mismo. Cítame en eso. Es la mejor base de datos relacional. No solo es la mejor base de datos relacional, también está lista para no-SQL porque han tenido soporte JSON, creo, desde la versión 9, y estamos en la versión 14 actualmente. Así que el soporte JSON solo mejora cada vez más. Entonces, si quieres construir una base de datos basada en documentos, puedes hacerlo en PostGrey. Esa es una de sus superpotencias.

El agrupamiento de conexiones, no voy a dedicar mucho tiempo a eso. Necesito acelerar un poco. Pero el agrupamiento de conexiones nos permitirá una escalabilidad increíble. Eso es otra cosa en la que tenemos que pensar cuando estamos construyendo esa gran pila tecnológica. Entonces podemos hacer agrupamiento de conexiones, podemos cortar de repente toneladas de recursos haciendo el handshake TLS si podemos compartir conexiones. Y la última cosa de la que quiero hablar es esa experiencia de desarrollo porque puedo ejecutar PostGrey, puedo iniciarlo en mi computadora portátil aquí en un segundo en un contenedor de Docker y puedo ejecutar todas mis pruebas directamente. Y, ya sabes, ámalo u ódialo. Tengo esa relación con SQL, pero es increíblemente poderoso. agregaciones en múltiples tablas, o si estuviéramos hablando de colecciones en una base de datos basada en documentos, puedo hacerlo.

Lo siguiente en la pila tecnológica de la que vamos a hablar es el servidor. Si vamos a hablar del servidor, vamos a hablar de Fastify. No pude evitar pensar en ese gato de Fastify comiendo algunos de esos waffles. Este es mi servidor node.js y está inspirado en happy. Será muy familiar para cualquiera que haya usado Express antes. Es fácil de usar. Y lo increíble de happy, Fastify, es que te permite construir una aplicación monolítica hoy cuando estás haciendo tu POC. A medida que tu proyecto crece y tus requisitos crecen, inevitablemente, vas a querer dividirlo probablemente en servicios, crear algún tipo de arquitectura de microservicios y Fastify, con esa arquitectura de complementos, te permitirá evolucionar con tu código. Entonces, la Ley de Conway siempre entrará en juego. Básicamente, tu código se verá como tu organización, y Fastify te permite hacer eso.

5. Fastify, Mercurius y Urql

Short description:

Fastify es un marco de trabajo de código abierto, transparente y modular que admite complementos. Es perfecto para construir aplicaciones. La capa de API será GraphQL, específicamente utilizando el complemento Mercurius. Mercurius resuelve problemas reales de GraphQL de manera predeterminada, con características como caché, federación, autenticación, suscripción y carga de archivos. La caché en Mercurius es excepcional y proporciona un excelente rendimiento a medida que la aplicación se escala. En el lado del cliente, utilizaremos Urql, un potente cliente de GraphQL.

Es de código abierto, es transparente y es modular, porque tenemos esos complementos. Nuevamente, puede ejecutarse en cualquier lugar. Eso es una de las cosas que nos encanta de Fastify. Y esa arquitectura de complementos es como un Xen de programación cuando cada complemento está aislado de los demás, y puedes construir lógicamente tu aplicación.

Así que ahora vamos a la buena parte, nuestra capa de API. Será GraphQL. Si estamos usando GraphQL en el servidor de Fastify, vamos a usar Mercurius. Mercurius es un complemento de GraphQL, un servidor de GraphQL para Fastify. Y resolverá problemas reales de GraphQL hoy, como de manera predeterminada. Esto es lo genial de Mercurius. Admite caché, federación, autenticación, suscripción, carga de archivos, todas esas cosas que no pensaste cuando escribiste tu primer servidor GraphQL, vienen con esos en forma de complemento que son compatibles con el proyecto principal, o vienen con ellos de manera predeterminada. Eso es lo que es tan increíble. Y la caché, vamos a hablar de eso en un momento. La caché es realmente increíble en Mercurius, y eso es lo que nos dará un rendimiento increíble a medida que nuestra aplicación se escala. Integra el servidor GraphQL, por lo que obtenemos una línea de tiempo donde podemos ver nuestras consultas pasar y podemos depurarlas en nuestro navegador. Oh, lo siento, ese es el siguiente paso, me salté un paso. Eso nos permite depurar nuestras consultas en nuestro navegador mientras las estamos construyendo. Tiene soporte incorporado para cargadores. No tengo tiempo para entrar en eso. Inevitablemente, si alguien aquí ha construido un servidor GraphQL, tendrá ese problema donde sus datos están en un gráfico, por lo que tiene algún tipo de jerarquía. Si está obteniendo padres, eventualmente tendrá que obtener hijos. No quieres hacerlo uno tras otro. Quieres encolar a todos los padres y luego encolar a todos los hijos y tal vez hacer dos consultas a tu base de datos para obtener todos tus datos. Y el cargador te permite hacer eso, y eso viene incorporado en Mercurius y eso es una de las cosas que me encanta de usar Mercurius.

Vamos a cambiar al lado del cliente. Si vamos a usar GraphQL en nuestro cliente, ¿qué vamos a usar? Vamos a usar Urql. Yo lo llamo Urql. Tú puedes llamarlo U-R-Q-L. U-R-Q-L. Creo que Urql suena bien.

6. Urkle GraphQL Client

Short description:

Urkle es el mejor cliente de GraphQL que admite todas las principales bibliotecas de front-end, incluyendo React. Ofrece potentes capacidades de almacenamiento en caché, soporte sin conexión y una API de hooks. Además, Urkle proporciona herramientas útiles para desarrolladores.

Es el mejor cliente de GraphQL. Funcionará con todas las principales bibliotecas de front-end. Estamos en React, por lo que admite React como su principal biblioteca de front-end. Almacenamiento en caché. Hace un almacenamiento en caché increíble. Almacena cosas utilizando tu consulta como clave en la caché, pero también puede normalizar tus data y almacenar cosas por ID, ID de la entidad. Esto te permite extraer elementos de la caché que ya han sido consultados por una consulta diferente. Y tiene soporte sin conexión. Si tenemos la capacidad de almacenar cosas en caché, podemos almacenarlas en la base de datos del índice en el navegador y nuestra aplicación de repente puede funcionar sin conexión. Todas las cosas que podríamos desear en un cliente de GraphQL, Urkle las tiene de serie. Y, por supuesto, tiene una API de hooks. Estamos aquí hablando de React. Es una API mágica y tienen algunas herramientas de desarrollo.

7. Construyendo una aplicación de Pizza con Urkel

Short description:

Así que dividí el componente en dos segmentos para que encaje en la diapositiva. Voy a construir una aplicación de pizza con slash pizzas para listar todas mis pizzas. El hook useQuery devuelve un objeto de resultado con datos de búsqueda de errores. Puedo manejar fácilmente los errores y renderizar los datos. Urkel nos permite obtener datos de la caché sin tener que ir al servidor. Configurar las APIs de GraphQL para que coincidan con nuestro dominio empresarial y almacenar datos en la caché simplifica nuestra aplicación.

Así que tuve que incluir un par de fragmentos de código. Esto es realmente un componente, pero lo dividí en dos segmentos para que encaje en la diapositiva y vamos a construir una aplicación de pizza. Voy a tener slash pizzas en mi aplicación que va a listar todas mis pizzas. Probablemente tendré, como, slash pizza, slash un ID, para obtener detalles. Así que esta es la lista. Y tenemos ese hook useQuery. Supongo que tengo mi consulta a la izquierda. Y en la parte superior de mi componente, tengo el hook useQuery. Y eso devuelve un objeto de resultado que tiene estas tres claves en él. Data fetching error. Esto es increíble porque, como, la API está construida para escribir componentes React. Así que si hay un error, puedo mostrar una cosa, mostrar algo emergente. Puedo tener un spinner de carga. Súper fácil. Y finalmente, puedo renderizar mis data. Y si he configurado correctamente mi caché, si ejecuto esa consulta, y ahora voy a obtener detalles de una pizza, tengo una consulta similar a la izquierda. Esta vez voy a obtenerla por ID. Si he configurado correctamente mi caché, sabes, mi componente se ve más o menos igual a la derecha, solo tienes una consulta un poco diferente. De repente, como, Urkel nos permite obtener los data de la caché sin tener que ir al servidor, así que voy a visualizar esto muy rápidamente aquí. Así que tengo dos componentes a la izquierda. Mi componente de pizza y mi componente de pizza. Voy a hacer esa consulta. Va a recorrer la database. Va a volver. Pero las cosas se van a almacenar en la caché. Así que ahora lo que va a suceder, aunque si he configurado Urkel de la manera correcta, cuando finalmente haga esa consulta en el cliente, vendrá directamente en el lado del cliente de la caché. Sin viajes al servidor. Y esto, esto es increíble porque si, como, configuramos nuestras APIs de GraphQL para que coincidan con nuestro dominio empresarial y podemos almacenar cosas en la caché, como, imagina si, como, realmente no necesitamos preocuparnos por el estado de la aplicación, como, estado global, redux, todas esas cosas pueden complicar nuestra aplicación. Tuve que incluir esto aquí. Así es como me siento cuando no tengo que escribir código de redux.

8. React, SSR y Fastify Vite

Short description:

Amamos React porque siempre está evolucionando pero sigue siendo estable. Los componentes nos ayudan a arquitecturar nuestro código. Vite es una herramienta imprescindible. Una mención honorífica es SSR con Fastify Vite, que permite SSR de pila completa y componentes modulares. Se integra con las principales bibliotecas de front-end y maneja la plantilla y el enrutamiento a nivel de página. Fastify DX, lanzado por Jonas Galvez, configura React y Fastify Vite de manera transparente. Incorporar requisitos no funcionales en nuestra pila tecnológica desde el principio garantiza unicornios.

Todos los días me siento así cuando no lo estoy haciendo. Entonces, por supuesto, estamos aquí en la React Summit. Tenemos que hablar de React. ¿Por qué amamos React? Bueno, porque es React. Y todos estamos aquí, como, los desarrolladores conocen React, por lo que podrás aumentar tu equipo, agregar recursos. Eso es una de las cosas que amamos de React.

Siempre está evolucionando pero, aún así, sigue siendo estable. Ok. La versión 18 tuvo algunos cambios que nos sorprendieron a todos, pero, como, estábamos preparados para eso, ¿verdad? Los componentes nos ayudan a arquitecturar nuestro código de manera correcta. Las herramientas de desarrollo, nos encantan. Vite. Si no estás usando Vite, úsalo. Ve a echarle un vistazo. Sí, si no lo estás haciendo, simplemente hazlo.

Así que una mención honorífica. Me estoy quedando un poco corto de tiempo, pero una mención honorífica aquí es SSR. Como, tenemos que hablar un poco de SSR. Ahora, lo increíble es que si estamos usando Fastify y Vite, hay un pequeño complemento para Fastify llamado Fastify Vite que nos permite hacer SSR, por lo que de repente tenemos una pila completa donde podemos hacer SSR y cada componente es modular, volviendo a esos principios. Funciona con todas las principales bibliotecas de front-end. Se encargará de la plantilla a nivel de página e integrará todas esas rutas que probablemente tengas en tu enrutador de React. Las agregará al servidor de Fastify para que podamos mapear nuestras rutas del lado del cliente en rutas en el servidor. Voy a ir muy rápido aquí, si alguien quiere hablar de esto conmigo, tenemos un stand, un stand de near-form aquí, ven a verme y podemos hablar de eso en más detalle. Es personalizable, no es mágico, es súper transparente. Una mención honorífica, mi colega Jonas Galvez, acaba de lanzar Fastify DX que va a tener React y Fastify Vite configurados y listos para usar, echa un vistazo a este proyecto, si no lo has hecho, todavía está en beta. Lo acaba de lanzar, creo, hace dos semanas, y va a estar listo para usar, teniendo todo configurado pero de una manera transparente que puedes personalizar.

Entonces, cuando comencé la charla, estábamos hablando de unicornios y arcoíris. Tal vez no podamos tener ambos. Si comenzamos a pensar en los problemas que inevitablemente tendremos en una aplicación en producción esos requisitos no funcionales, y los incorporamos en nuestra pila tecnológica desde el principio, aún podemos tener unicornios. Es posible que no tengamos arcoíris, pero aún tengo un unicornio. Así que solo quiero revisar esta pila muy rápido.

9. Why Use This Stack and NearForm

Short description:

Esta pila está diseñada para funcionalidades complejas y requisitos no funcionales. Es altamente personalizable y tiene un diseño modular. La transparencia y el apoyo de la comunidad en proyectos de código abierto la convierten en una excelente elección. Si tienes alguna idea para nombrar la pila, házmelo saber. Trabajo en NearForm, manteniendo paquetes de código abierto importantes y brindando servicios profesionales. Echa un vistazo a la aplicación de prueba de concepto de pizza que construí y no dudes en hacerme preguntas. ¡Gracias a todos!

¿Por qué usaría esta pila? Como dije, está diseñada para esa funcionalidad compleja, esos requisitos no funcionales que van a surgir al final. Ese último 20 por ciento, estamos pensando en eso desde el principio, es altamente personalizable, podemos intercambiar cosas, aún tiene ese diseño modular.

Todas las capas de abstracción son transparentes, podemos quitar las cubiertas, podemos ensuciarnos las manos si es necesario, y por supuesto, es una community... Todos los proyectos son compatibles con la comunidad, de código abierto, tienen muchos ojos que los observan.

Entonces, eso es por qué usaría esta pila, y así es como vendo esta pila a tu equipo cuando están buscando ese marco que afirma hacerlo todo. Solo quiero hacerles una pregunta muy rápida. Tuvimos la pila lean, tuvimos la pila mean, tuvimos la pila jam. ¿Cómo se llama mi pila? Lo mejor que se nos ocurrió es Frump, Fastify, React, Urkel, Macarius, Postgre? No suena muy bien. Pensé en algo como firm o merf. Esos también son un poco extraños. Si tienes alguna idea, envíamela por Twitter o ven a verme al stand. Estaré encantado de hablar sobre eso.

Trabajo en NearForm. Como dije, tenemos un stand. Somos los mantenedores de algunos paquetes de código abierto realmente importantes y MPM, y brindamos servicios profesionales, pero también trabajamos en código abierto y contribuimos a él. Un lugar increíble para trabajar. Si quieres saber más sobre NearForm, visítanos en el stand. Estaré encantado de hablar sobre eso. Construí una aplicación de prueba de concepto, esa aplicación de pizza. Puedes echarle un vistazo en esta URL. También puedes ver mis diapositivas. Y si alguien tiene preguntas sobre estas cosas o quiere profundizar en los detalles, estaré encantado de hacerlo. Ven a verme al stand o contáctame en Twitter. Gracias a todos. Gracias. Pasemos a mi oficina. Vamos a la oficina. Eso está bien. En primer lugar, tengo un pequeño problema contigo. Tanta comida increíble en tus diapositivas, me estás dando hambre.

10. Using Fastify in a Serverless Infrastructure

Short description:

¿Es posible usar Fastify en una infraestructura serverless? Absolutamente fácil. La respuesta es sí. Ve al sitio web de Fastify y tienen un enlace directamente en la página de inicio para serverless, y te mostrarán cómo configurarlo.

Bueno, ¡es hora de eso, ¿verdad? Genial. Vamos a pasar a esas preguntas. Recuerda, si quieres, también puedes encontrarlo en el stand y también en el stand de preguntas y respuestas justo después de esto. Pero vamos directamente a esa pregunta. Vamos a hacerlo.

La primera. ¿Es posible usar Fastify en una infraestructura serverless? Porque siempre estoy tratando de hacer las cosas serverless. Absolutamente fácil. La respuesta es sí. Es un gran sí. Ve al sitio web de Fastify y tienen un enlace directamente en la página de inicio para serverless, y te mostrarán cómo configurarlo. AWS, GCP, Azure, cualquiera que sea tu plataforma de servicio. Tienen instrucciones para configurarlo en todas ellas. Perfecto. Así que un gran sí. Increíble. Increíble.

11. Ventajas de Mercurius y Ercu

Short description:

Mercurius cuenta con funciones incorporadas como federación, autenticación y almacenamiento en caché, lo que lo hace conveniente de usar. Estas funciones están disponibles de forma inmediata y están bien documentadas en el archivo readme.

Entonces hablemos de las ventajas de Ercu y Mercurius en comparación con Apollo, y vamos a combinarlas en dos. ¿Cuáles son las ventajas y desventajas de ambas? No quiero criticar ninguno de los frameworks existentes, pero lo que me encanta de Mercurius es que viene con todas esas cosas, esos pequeños detalles mágicos que tal vez no hayamos pensado cuando usamos los otros frameworks. Viene con ellos incorporados, listos para usar. Así que en el momento en que necesitemos hacer federación, o en el momento en que queramos hacer autenticación, o agregar almacenamiento en caché, simplemente viene incluido. Te lo entregan, está ahí mismo en el archivo readme, te dice cómo configurarlo. Esas son las cosas que me encantan de Mercurius y por qué trabajaría con eso.

12. Cons and Disadvantages of the Stack

Short description:

Hablemos de algunos de los inconvenientes y desventajas de esta pila. La velocidad inicial de desarrollo puede ser alta, pero debemos considerar los desafíos de mantener un código de calidad de producción. Pasar más tiempo al principio puede ahorrar tiempo al final.

Muy bien, muy bien. Y Ercu en el front-end, disculpen. Bien, y muchas personas que han utilizado muchos tipos diferentes de pilas, siempre trato de compararlas, hablemos de algunos de los inconvenientes y desventajas de esta pila para poder evaluarla con otras. Sí, creo que es una pregunta justa, definitivamente creo que es una pregunta justa. Los inconvenientes pueden ser la velocidad inicial de desarrollo, así que si optamos por un framework que afirma hacerlo todo, nos lanzará súper rápido a una alta velocidad de desarrollo, así que creo que eso definitivamente es una ventaja de un gran framework. Pero lo que quiero advertir a todos es que piensen en lo que va a suceder una vez que se implemente en producción, una vez que comiencen a surgir esos otros desafíos cuando tengan que solucionar cosas en un código de calidad de producción, ¿podrán hacerlo cuando estén utilizando ese gran framework? Hay ventajas y desventajas, creo que tal vez si dedicamos un poco más de tiempo al principio, podemos ahorrar mucho tiempo al final. Muy bien, muy bien, pero, ¿qué hay de React Query? Voy a pausar en esta pregunta, vengan a verme al stand, me encantaría hablar de ello en detalle con cualquiera que quiera, pero ahora mismo no tengo una buena respuesta para compararlo, hablemos de eso más tarde, por favor. Eso es bastante justo, y una vez más estamos volviendo a las comparaciones de pilas, Remix es otra pila de la que mucha gente está hablando. Sí, ha generado mucha expectación. No voy a compararla, porque no soy un experto detallado en Remix, como esta es la pila que uso todos los días, y podría hablar mucho sobre eso, estaría encantado de comparar algunos detalles en el stand, o en la sesión de preguntas y respuestas justo después, o contáctenme en Twitter, pero no quiero hacer una comparación paso a paso ahora mismo, aunque sé que es un tema candente. Totalmente, lo que sugiero es que aquellos que estén interesados en diferentes pilas, se acerquen al stand, tengan una gran conversación y puedan profundizar en ello. Sí, estamos entrando en detalles. Sí. Me encantan los detalles. Eres un gran fan de GraphQL. Sí lo soy. ¿Por qué? ¿Cuáles son algunas de las cosas que más te gustan de GraphQL? Realmente no sé por dónde empezar con esa pregunta, pero honestamente creo que lo que realmente me gusta de GraphQL es que estamos construyendo una abstracción sobre nuestro modelo de datos, y nos permite crear una capa de API que se adapta a nuestro dominio empresarial, y puede que no nos importe dónde se almacenan los datos, cuántos servicios almacenan esos datos. Si podemos usar GraphQL, podemos construir una API específica para nuestro dominio empresarial, y creo que eso es realmente importante. Por supuesto, tenemos versionado, podemos deprecar ciertas entidades, siempre podemos agregar propiedades a los objetos. Así que si lo comparamos con una API REST regular, todas esas ventajas están integradas. Esas son cosas que realmente me encantan de GraphQL. Hay más. Podría seguir hablando de esto durante un tiempo. Junto a esto, definitivamente. Muy bien, esta será la última pregunta. ¿Dónde y cómo se almacenan y manejan los tipos? Bueno, si hablamos de GraphQL, nuestros tipos se almacenan en un esquema. Así que escribimos un esquema en nuestro servidor que se cargará cuando carguemos Mercurius. Ahí es donde encontraremos nuestros tipos. Y como admitimos federación, podemos federar esquemas de diferentes servidores GraphQL, lo cual es una arquitectura realmente genial, porque tendríamos un servidor GraphQL que actúa como la puerta de enlace y puede federar esquemas de diferentes lugares. Así que podemos almacenar los tipos junto a los datos de donde se obtienen. Muy bien. Muchas gracias, Cody. Gracias. Realmente disfrutamos esto, aplaudamos. Gracias.

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

Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
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 Remote Edition 2021React Summit Remote Edition 2021
43 min
RedwoodJS: The Full-Stack React App Framework of Your Dreams
Top Content
Tired of rebuilding your React-based web framework from scratch for every new project? You're in luck! RedwoodJS is a full-stack web application framework (think Rails but for JS/TS devs) based on React, Apollo GraphQL, and Prisma 2. We do the heavy integration work so you don't have to. We also beautifully integrate Jest and Storybook, and offer built-in solutions for declarative data fetching, authentication, pre-rendering, logging, a11y, and tons more. Deploy to Netlify, Vercel, or go oldschool on AWS or bare metal. In this talk you'll learn about the RedwoodJS architecture, see core features in action, and walk away with a sense of wonder and awe in your heart.
Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Top Content
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.

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
JSNation 2023JSNation 2023
174 min
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Featured WorkshopFree
This SvelteKit workshop explores the integration of 3rd party services, such as Storyblok, in a SvelteKit project. Participants will learn how to create a SvelteKit project, leverage Svelte components, and connect to external APIs. The workshop covers important concepts including SSR, CSR, static site generation, and deploying the application using adapters. By the end of the workshop, attendees will have a solid understanding of building SvelteKit applications with API integrations and be prepared for deployment.
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.
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