Herramientas y Procesos para Gestionar GraphQL a Escala

Rate this content
Bookmark

En esta charla, cubriremos las bibliotecas, herramientas y procesos que utilizamos para implementar GraphQL a cientos de desarrolladores en Yelp.

18 min
09 Dec, 2021

Video Summary and Transcription

Esta charla discute la vida de un desarrollador de GraphQL en Yelp, cubriendo las herramientas, procesos y la escala de uso de GraphQL. Se enfatiza la importancia de tomar buenas decisiones de esquema y utilizar GraphQL Faker para una iteración rápida. La charla también destaca los desafíos de usar data loaders en Yelp y las soluciones implementadas, como la generación de código y los precommits. Se menciona la importancia de la revisión de esquemas, la documentación y la adopción de GraphQL. Por último, se menciona el valor de la documentación obsesiva y el uso de vPress para generar markdown y una interfaz de usuario interna para referencia de consultas.

Available in English

1. Life as a GraphQL Developer at Yelp

Short description:

Esta charla trata sobre la vida de un desarrollador de GraphQL en Yelp. Mark, líder del equipo de API de datos del cliente, te guiará a través de las herramientas y procesos que han construido. Compartirán la escala del uso de GraphQL en Yelp, con más de 500 tipos en el esquema y 10,000 QPS. La charla también abordará la importancia de tomar buenas decisiones de esquema.

Hola a todos. Esta charla te llevará a través de cómo es la vida como desarrollador de GraphQL en Yelp. Específicamente, quiero mostrarte algunas de las herramientas y procesos que hemos construido para hacer nuestras vidas más fáciles y para enviar cosas de manera más segura y rápida. Mi nombre es Mark, y soy líder del equipo de API de datos del cliente. Mantenemos la infraestructura de GraphQL utilizada por los desarrolladores de Yelp para construir nuestras aplicaciones web y móviles. Y si quieres ponerte en contacto conmigo sobre cualquier cosa que voy a decir, estoy en Twitter, es Mark underscore Lara. Si no estás familiarizado con Yelp, es un lugar para conectarse con excelentes negocios locales y encontrar dónde es bueno comer o encontrar fontaneros o mudanzas de los que puedes leer sus reseñas, ese tipo de cosas. Y aquí hay una página típica de un negocio de Yelp. Mira todos estos hermosos datos que hemos extraído de la base de datos. Se ve útil, ¿verdad? Así es como se ve esta página sin ningún dato. Lo cual no es muy útil. Así que creo que todos podemos estar de acuerdo en que los datos son buenos. Y nuestro trabajo es enviarlos a esta página de alguna manera. Lo que quiero hacer es llevarte en un viaje, y juntos pasaremos por la experiencia de hacer una solicitud de extracción y agregar un esquema para una nueva función en nuestro servicio de GraphQL. En el camino, compartiré los procesos y herramientas que hemos agregado para las personas, para que puedas tener una idea de cómo es nuestra experiencia como desarrolladores. Ahora, quiero establecer el escenario y compartir la escala de las cosas y por qué estamos invirtiendo mucho tiempo en esto. Entonces, GraphQL es el estándar moderno para hacer extracción de datos en Yelp. Es utilizado por cientos de desarrolladores en toda la organización. Hay más de 500 tipos en el esquema. 500 consultas persistentes activas. Es decir, consultas que se están utilizando en producción en las últimas dos semanas. Y en total, el servicio de GraphQL recibe alrededor de 10,000 QPS. Por lo tanto, mucho de Yelp depende de que esta cosa funcione de manera fluida y eficiente. Veamos cómo se ve eso. De acuerdo. Digamos que estamos creando un producto completamente nuevo en Yelp. Y puede haber algún esquema existente que podrías usar. Pero en su mayoría, tendremos que implementar alguna lógica nueva en el backend para esto. Entonces, lo primero que tendremos que averiguar es, bueno, ¿qué tipo de consulta quieres enviar? ¿Qué tipo de esquema queremos? Y obviamente, no queremos agregar simplemente lo primero que se nos ocurra y comprometernos con eso. Las malas elecciones de esquema pueden ser costosas y difíciles.

2. Writing Dream Queries and Using GraphQL Faker

Short description:

Alentamos a los desarrolladores a escribir una consulta de ensueño, que es la consulta que desearían poder escribir si el esquema estuviera disponible. Tenemos revisores de esquemas que ayudan a revisar y señalar los tipos existentes. Utilizamos GraphQL Faker, una herramienta de código abierto, para iterar y probar nuevos esquemas antes de implementar los resolvers.

para eliminar una vez que se utilicen en producción. Por lo tanto, queremos mantener las cosas bastante flexibles hasta el punto en que realmente comprometamos el código. Ahora, tal vez seas nuevo en la empresa o nuevo en GraphQL, y aún no tengas una idea de lo que hay en el resto del esquema o cómo se ve un esquema idiomático en general. Y así, al escribir la consulta para tu nueva página, alentamos a los desarrolladores a simplemente escribir algo que se parezca a una consulta de GraphQL y haga lo que deseas. Y llamamos a esto la consulta de ensueño. Y esa es la consulta que desearías poder escribir si el esquema estuviera mágicamente disponible para alimentarla. Y a partir de ahí, tenemos un grupo de revisores de esquemas que pueden ayudar a revisar y señalar los tipos existentes y demás. Y hemos encontrado que esta es una buena forma de comunicar las cosas y de incorporar a las personas de una manera menos intimidante. He vinculado nuestra publicación de blog, que describe este proceso con más detalle y por qué nos gusta. Échale un vistazo al enlace en la diapositiva. Entonces, sí, sigamos adelante con nuestra nueva función y hemos escrito una consulta de ensueño que queremos usar en nuestra nueva página web. Y una vez que tengamos algo con lo que estemos razonablemente satisfechos y que se vea bien en papel, a continuación, podemos comenzar a elaborar el esquema que escribiríamos para alimentar esa consulta. Y supongo que realmente esto se puede hacer en paralelo con una consulta de ensueño. Somos grandes fanáticos de una herramienta, una herramienta de código abierto llamada GraphQL Faker. Es un poco como GraphQL o GraphQL Playground y crea un entorno de desarrollo para que puedas hacer consultas en él.

3. Using GraphQL Faker for Quick Iteration

Short description:

Puedes consultar y ampliar tu esquema GraphQL real con datos generados automáticamente utilizando GraphQL Faker. Está disponible globalmente en nuestras máquinas de desarrollo y se puede integrar fácilmente en tu aplicación React para una iteración rápida y para paralelizar el trabajo entre los desarrolladores de backend y frontend.

Pero también obtienes un editor para agregar nuevos esquemas y nuevos tipos sobre la marcha. Entonces, puedes consultarlos y obtener datos de lorem ipsum generados automáticamente. Y esto también se puede integrar y ampliar un esquema existente. Así que usamos esto para ampliar nuestro esquema GraphQL real y puedes hacer consultas que combinen el esquema real y tu nuevo esquema en progreso. Esta es una excelente manera de tener configurado un ciclo de iteración rápida y tener una idea del nuevo esquema que deseas agregar antes de dedicar tiempo a implementar los resolvers. Hemos hecho esto disponible globalmente en nuestras máquinas de desarrollo. Simplemente escribe un comando y inicia una instancia falsa de GraphQL, preconfigurada para comunicarse con una de nuestras instancias de desarrollo reales de GraphQL, y todo está mágicamente disponible. Puedes ir más allá y integrar esto en la aplicación React que estás desarrollando y probarlo con algunos componentes reales que estás desarrollando en la interfaz de usuario, al mismo tiempo, para que no tengas que esperar al backend. Y sí, esto es genial para paralelizar el trabajo entre los desarrolladores de backend y frontend. GraphQL Faker es genial. Recomiendo encarecidamente usarlo en tus flujos de desarrollo y proporcionar algunas herramientas ligeras a su alrededor para que sea fácil ampliar tu esquema real.

4. Implementando Resolvers y Usando Data Loaders

Short description:

Estamos contentos con nuestro nuevo esquema y queremos implementar los resolvers. Nuestra arquitectura consiste en diferentes servicios propiedad de diferentes equipos, expuestos a través de un servicio de puerta de enlace GraphQL. Para evitar solicitudes de red innecesarias y utilizar puntos finales en bloque, utilizamos data loaders. Los data loaders son funciones de agrupación y almacenamiento en caché que se conectan a recursos externos cuando no se puede acceder directamente.

y úsalo en tus aplicaciones React. De acuerdo. Estamos muy contentos con nuestro nuevo esquema, y queremos invertir algo de tiempo en hacer que funcione de verdad e implementar los resolvers.

Instantánea rápida de la arquitectura. Esta es una descripción general aproximada de cómo se ve nuestra arquitectura. Esperemos que se vea algo familiar. Simplemente tenemos un montón de servicios diferentes propiedad de diferentes equipos que exponen APIs REST internas para diversos productos y casos de uso. Nos comunicamos con todos estos servicios a través del servicio de puerta de enlace GraphQL, que es nuestro servicio GraphQL ligeramente monolítico escrito en Node con Apollo Server. Y los resolvers necesitan obtener datos y comunicarse con estos puntos finales.

Aquí hay algunos problemas comunes. ¿Cómo evitamos sobrecargar el backend y hacer un montón de solicitudes de red innecesarias y desperdiciadas? ¿Cómo utilizamos correctamente los puntos finales en bloque? La respuesta principal son los data loaders. Apollo también tiene un patrón llamado data sources. Estoy seguro de que la mayoría de ustedes probablemente ya conocen los data loaders. Existen en varios lenguajes, pero si no, la idea principal aquí es que son una función mágica de agrupación y almacenamiento en caché sobre algún recurso subyacente. Si no tienes acceso directo a donde se encuentran los datos en tu servidor GraphQL, y necesitas conectarte a algún recurso externo, probablemente deberías estar usando

5. Desafíos con Data Loaders en Yelp

Short description:

Utilizamos data loaders para manejar los cientos de puntos finales HTTP internos distribuidos en múltiples servicios en Yelp. Escribir y mantener data loaders individuales para cada punto final sería consumir mucho tiempo y propenso a inconsistencias. Es desafiante determinar a qué punto final debe ir un data loader y cómo manejar de manera consistente la gestión de errores y el registro. Este enfoque resultaría en un código boilerplate desordenado y difícil de gestionar.

algo como esto. De acuerdo. Utilizamos data loaders. Pero como con muchas cosas en el desarrollo de software y en herramientas de código abierto, tienes algunos ejemplos básicos en la documentación y algunos tutoriales en línea, pero se vuelve complicado cuando queremos escalar esto y conectarlo con el resto de Yelp. El problema es que tenemos cientos de estos puntos finales HTTP internos que están distribuidos en cientos de servicios y el enfoque básico sería escribir a mano los cientos de data loaders para comunicarse con todos estos cientos de puntos finales, lo cual sería bastante engorroso por varias razones. Tenemos múltiples puntos finales que devuelven información de usuario. Por ejemplo, hay muchas representaciones diferentes de usuario, por lo que si alguien crea un data loader de usuario, ¿a qué punto final va? ¿Quién decide? ¿Cómo evitamos que las personas creen múltiples data loaders de usuario? ¿Cómo obtenemos tipado en estos data loaders? ¿Cómo nos aseguramos de que la gestión de errores y el registro sean correctos cada vez? Simplemente lleva tiempo escribirlo. Es otra cosa para mantener, etc. Así que puedes imaginar que todo este boilerplate inconsistente puede volverse bastante desagradable.

6. Generación de código, Precommits y Verificación de esquemas

Short description:

Creamos una capa de generación de código llamada generación de código de data loader que genera data loaders para cada punto final especificado. Esto elimina la necesidad de pensar en qué data loader usar para cada punto final y ahorra tiempo. También recomendamos utilizar tipos generados para los resolvers para verificar el tipo de implementación en JavaScript. Los Precommits se utilizan como un sistema de advertencia temprana para detectar problemas antes de confirmar los cambios. Utilizamos herramientas como GraphQL Schema Linter para verificar las convenciones de nombres y las reglas de estilo. Los bots de GitHub, como el bot de verificación de esquemas, detectan cambios que rompen el esquema y proporcionan advertencias. También verifican las consultas que utilizan campos que se han eliminado para evitar problemas en producción. Si no se encuentran consultas, la solicitud de extracción pasa la verificación.

para manejar. La solución que encontramos fue una capa de generación de código llamada generación de código de data loader. Ya tenemos Swagger UI configurado para documentar todos los puntos finales internos en Yelp. La gente ya está acostumbrada a pensar en términos de estos puntos finales de Swagger y sus interfaces. Son muy utilizados y están muy bien documentados, una buena fuente de verdad. Queremos que la gente piense en términos de esos puntos finales. Y eso es lo que hace la generación de código de data loader. Tenemos un archivo de configuración y genera data loaders para cada punto final que especificamos. Entonces, piensas en términos de los puntos finales, no en los data loaders, que pueden tener diferencias sutiles. Y tenemos esta estricta correspondencia uno a uno. No es necesario pensar en qué data loader necesito para este punto final. Siempre será el verdadero. Y tendrá una interfaz coincidente. Y esto es genial. Entonces, la capa de data loader ahora es básicamente transparente. Es una cosa menos de la que preocuparse. Ahorra mucho tiempo escribirlos y mantenerlos y nos ha permitido escalar hasta tener cientos de data loaders, todos con el mismo manejo de errores y registro, etc. Incluso si no estás hablando con puntos finales REST detrás de escena, algunos de estos conceptos aún pueden aplicarse a tu situación. Creo que la conclusión aquí es que la generación de código y la eliminación de cosas mantenidas por humanos cuando sea posible es bueno. De todos modos, hemos abierto esto al público, y si estás interesado en obtener más información, puedes consultarlo en GitHub con el enlace de la diapositiva. Lo otro que recomiendo encarecidamente son los tipos generados para los resolvers. Utilizamos una buena biblioteca de Guild, GraphQL cogenerator, que también hace muchas otras cosas, pero la usamos para generar tipos a partir de nuestro archivo de esquema y los usamos para verificar el tipo de implementación en JavaScript. Es una victoria rápida y fácil.

Bien, ahora estamos realmente listos para confirmar nuestro nuevo esquema al confirmar el código, y utilizamos Precommits como un sistema de advertencia temprana para detectar problemas que romperían la compilación. Precommit es una herramienta que realiza verificaciones justo después de escribir git commit en tu terminal, pero antes de confirmarlo realmente, y esto es principalmente para cosas como linters y comprobadores de tipos y cosas que se ejecutan en CI, pero esto se ejecuta en tu terminal de inmediato. Entonces, no tienes que esperar 20 minutos para que CI falle y luego darte cuenta de que tenías un error de espacio en blanco. Además de verificar el formato del JavaScript, también verificamos el esquema, y para hacer esto, utilizamos una herramienta llamada GraphQL Schema Linter, y esto nos permite verificar un conjunto básico de convenciones de nombres y reglas de estilo, sí, es una herramienta realmente buena, y la ejecutamos en precommit, por lo que esto es lo que sucede si intentas pasar un esquema que sabemos que rompe las reglas. Muy bien. Suponiendo que todo salió bien, ahora es el momento de enviar tu solicitud de extracción, y lo primero que hacemos es tener un par de bots de GitHub para verificar más de tu esquema. El primero es el bot de verificación de esquemas, y este utiliza un paquete llamado GraphQL inspector para detectar cualquier cambio que rompa el esquema. Si encontramos cambios que rompen, como eliminar un campo o cambiar el nombre de un campo, mostramos una gran señal de advertencia como esta, y vamos un paso más allá, por lo que tenemos esta lista blanca de consultas, consultas persistentes, y sabemos cuándo se están utilizando las consultas, y podemos revisar todas las consultas que se están utilizando en las últimas dos semanas y decir, oye, parece que estás tratando de eliminar este campo, pero tenemos, como, estas 20 consultas que están utilizando este campo en producción en este momento, por lo que va a romper estas consultas, así que tal vez no lo empujes, por lo que es un buen sistema de advertencia y nos evita romper Yelp, como la solicitud de extracción realmente se volverá roja.

7. Revisión de Esquema y Documentación

Short description:

Si deseas eliminar un campo, pero no se está utilizando en producción, la verificación de GitHub pasará. Los bots de sugerencias de esquema brindan comentarios sobre posibles problemas que son difíciles de verificar estrictamente. La aprobación del grupo de revisión de esquemas es el paso final para garantizar la consistencia. Una documentación sólida es esencial para la incorporación y el mantenimiento de la consistencia. Hemos compartido algunas páginas relacionadas con el diseño de esquemas en GitHub. Agradecemos los comentarios y estamos contratando.

Si deseas eliminar un campo, pero no se está utilizando en producción, la verificación de GitHub pasará. Y, por otro lado, si realmente deseas eliminar un campo después de un proceso adecuado de desaprobación o limpiar algunos experimentos, entonces podemos decir que la lógica dice: bueno, estás eliminando un campo, pero en realidad no encontramos ningún documento que esté siendo utilizado en producción que utilice este campo, por lo que no romperá nada, puedes seguir adelante y la verificación de GitHub simplemente pasará para ti. Otro bot en el que nuestro equipo está trabajando actualmente es el bot de sugerencias de esquema, y esto es para cosas que creemos que podrían aplicarse a ti, pero que son inherentemente difíciles de verificar estrictamente, por lo que no queremos que la compilación falle por esto. Y esto podría ser cosas como, hey, estás agregando un nuevo tipo llamado horario de negocios, pero parece que ya hay un tipo llamado horario de apertura de negocios, así que tal vez quieras usar eso en su lugar, y tenemos un montón de reglas de expresiones regulares sofisticadas para detectar cosas que podrían estar rompiendo nuestras pautas de diseño de esquemas. Entonces, si creemos que encontramos algo, verás un comentario en línea en GitHub y puedes optar por hacer algo al respecto o ignorarlo como un falso positivo. Una vez que todo se ve bien, el paso final, final, es obtener la aprobación de alguien en nuestro grupo de revisión de esquemas, y estas son personas que están familiarizadas con nuestras pautas de diseño de esquemas, y este paso existe como una verificación adicional de seguridad final para asegurarse de que el esquema se vea bien. Inicialmente, esto era solo un pequeño grupo de desarrolladores para asegurarnos de tener consistencia en los primeros tipos y difundir ese conocimiento en toda la empresa, pero ahora está abierto a todos y es un módulo de aprendizaje que pedimos a las personas que completen y una vez que lo hayan completado, pueden unirse al grupo y aprobar nuevos esquemas. Intentamos tener dos revisores por equipo, pero hay desigualdades en algunos lugares, por lo que las personas manejan las revisiones de diferentes equipos cuando es necesario, y eso también es algo bueno, porque significa que no hay opiniones específicas del equipo sobre el esquema y todo se ve un poco más consistente en toda la empresa. Bien, una cosa final que quería mencionar es el valor de una documentación sólida. En el primer año en que implementamos GraphQL, diría que hubo una división absolutamente equitativa del tiempo dedicado a la codificación versus la documentación interna para iniciar el conocimiento de esta nueva cosa y servir como material de incorporación. Para una plataforma que muchos desarrolladores usarán con el tiempo, la documentación es tanto un producto como un enfoque y, sinceramente, solo la documentación y el pensamiento y el proceso que se le dedica podrían ser un tema de conversación en sí mismo, pero ese no es el tema más emocionante, así que eso es un tema para otra charla. Las únicas conclusiones importantes que daré aquí son que la mayoría de las veces, las personas de productos solo quieren centrarse en construir productos, y para la infraestructura, solo quieren ver cosas para copiar y pegar y no tener diferentes principios fundamentales. Todo lo que ves en el código abierto a veces de que no tenemos opiniones, usa x como quieras, es genial para el código abierto donde los autores no conocen tu configuración específica, pero internamente en la empresa, conocemos tu configuración y es nuestro trabajo como equipo de Infraestructura tener esas opiniones y crear abstracciones y establecer pautas tanto como sea posible para ahorrar tiempo a todos los demás en la empresa para que no tengan que hacerlo de un millón de formas diferentes. Entonces, tener todo eso listado en la documentación de solo hacer esto, descubrimos que funciona para nosotros. Estoy emocionado de decir que esta semana hemos compartido algunas de las páginas relacionadas con el diseño de esquemas. Por lo tanto, puedes consultarlas en GitHub con el enlace en la diapositiva para ver cómo diseñamos los esquemas en Yelp. Finalmente, si crees que nos hemos perdido algo que deberíamos estar haciendo, genial. Nos encantaría saber de ti. Estamos contratando. Así que visita la página de carreras.

QnA

Adopción de GraphQL y Servicio de Gateway

Short description:

Es interesante ver el nivel de adopción de GraphQL y las inversiones que se están realizando. El servicio de gateway de GraphQL se está convirtiendo en un monolito, lo que causa problemas técnicos y sociales. Dividirlo es lo próximo en lo que nuestro equipo trabajará. También estamos explorando GraphQL Mesh y Federation. La integración de GraphQL Faker permite una iteración rápida y un desarrollo rápido de páginas sin tener que esperar a los desarrolladores del backend. Este enfoque en un ciclo de iteración rápido es un aspecto clave de nuestro enfoque.

Y sí, eso es todo lo que tengo. Gracias a todos. Tenemos una pregunta aquí. Preguntaste, ¿qué tan madura es la adopción de GraphQL en tu organización? ¿Qué opinas sobre estas respuestas? Sí, es muy interesante ver quién asiste a estas conferencias y el tipo de información que se aplica a ustedes en diferentes etapas de adopción. Obviamente, el nivel de inversión que deseen realizar en su infraestructura depende de cuántas personas esperen que la utilicen. Parece que se utiliza en muchos lugares, es una opción popular. Esperemos que haya muchas personas pensando en estas inversiones. Sí, seguro. Parece que muchas personas están investigando, pero ya se está utilizando. Eso es genial. Pasemos a algunas preguntas y respuestas de nuestra audiencia ahora. Tenemos una pregunta aquí que dice: El servicio de gateway de GraphQL parece un monolito. ¿Hay planes para dividirlo? Sí. Como escribí en el diagrama de arquitectura, todos los data loaders, toda la lógica del backend está en este servicio de gateway de GraphQL. Y aunque se pretende que sea una especie de proxy delgado sobre todos esos diferentes servicios y data loaders y puntos finales, ya sabes, se convierte en un poco de monolito, porque inevitablemente hay algo de lógica en ese servicio, y estamos hablando de cientos de estos resolutores, lo que crea problemas técnicos y problemas sociales, problemas técnicos que, ya sabes, los problemas habituales de los monolitos, como que se vuelve muy difícil trabajar en ese monolito porque tienes, como, cientos de pruebas que ahora podrían fallar cada vez que haces un pequeño cambio, y, ya sabes, hay conflictos de fusión y, ya sabes, lidiar con las convenciones de otros equipos y cosas así. Y luego hay problemas sociales, porque nuestro equipo es dueño de ese servicio y somos responsables de la infraestructura detrás de él, y tenemos, como, estas mejores prácticas que podrían, ya sabes, creemos que podrían aplicarse a todos, pero tal vez algún equipo tiene, ya sabes, queremos hacer las cosas de una manera específica. Entonces, y hay algunos asteriscos de rendimiento en los que no entraré en detalle, pero realmente parece que dividirlo de alguna manera probablemente será lo próximo, lo próximo grande en lo que nuestro equipo trabajará, y hay muchas respuestas a eso, como la federación, GraphQL mesh, así que definitivamente estamos trabajando duro en eso. Bien, entonces hay planes, próximamente. Sí. Genial. Entonces, sí, en la charla, mencionaste este GraphQL faker. Es algo que nunca he usado antes, y la integración de eso, y eso es algo en lo que tendré que investigar, porque parece muy interesante. Entonces, gestionar GraphQL, y obviamente, es posible que no tengas data para empezar. Entonces, tienes este faker, ¿verdad? Y eso es una gran ventaja. ¿Quieres ampliar algo de eso? Sí, mucho de lo que vemos son equipos que tienen páginas completas que se lanzan a producción y que podrían descartarse. Porque tenemos equipos de negocios que necesitan un ciclo de iteración muy rápido. Y tener algo que puedas crear una página como desarrollador web, no tienes que esperar necesariamente a un desarrollador del backend. Solo quieres algo que funcione. Necesitas jugar con esa consulta. Y también con el esquema. Entonces, ese ciclo de iteración rápida es algo en lo que nos enfocamos.

Herramientas, Bebidas y Documentación

Short description:

Siempre estoy atento a buenas herramientas como GraphQL o Faker. Me encanta cuando descubro nuevas herramientas. ¿Cuál es tu bebida preferida cuando trabajas en proyectos de gran escala? Yo personalmente soy amante del té, así que me gusta un buen té verde. Así que, los asistentes, continúen haciendo cualquier pregunta que puedan tener en el canal de preguntas y respuestas de Andromeda. ¿Hay una lista de herramientas que Mark presentó? Puedo compartir las diapositivas en mi Twitter y compartir la lista de herramientas. Todo lo mencionado en las diapositivas requirió un gran esfuerzo de todo el equipo. Si tuviera más tiempo, habría dedicado mucho más tiempo a la documentación. El valor de pensar mucho en eso, y no solo lanzar información en una página, sino tener un flujo de información considerado, qué es relevante, cómo se ve.

Mucho. Cuanta más información podamos obtener de eso. Mejor, más productivos seremos todos. Así que, siempre estoy atento a buenas herramientas como GraphQL o Faker. Y si alguien más conoce algo, alguna otra herramienta similar, por favor avísenme. Sí, me encanta cuando descubro nuevas herramientas. Tengo tantas herramientas. Las herramientas, nos ayudan sin importar en qué estemos trabajando. Probablemente haya una herramienta para eso.

Entonces, tenemos otra pregunta aquí. ¿Cuál es tu bebida preferida cuando trabajas en proyectos de gran escala? Oh, esa es una buena pregunta. Me gusta esa pregunta. Depende de cómo vaya el proyecto, ¿verdad? Sí, supongo. También depende de la hora en que esté trabajando. Yo personalmente soy amante del té, así que me gusta un buen té verde. ¿Caliente o frío? Entonces, ¿un buen oolong, tal vez? Sí. Bien, bien. Muy bien. Así que, los asistentes, continúen haciendo cualquier pregunta que puedan tener en el canal de preguntas y respuestas de Andromeda. Tenemos otra pregunta aquí. ¿Alguien tiene la lista de herramientas, o alguien tiene una lista de herramientas que Mark presentó? ¿Hay una lista en algún lugar? Puedo compartir las diapositivas en mi Twitter y compartir la lista de herramientas. Sí, puedo hacer eso. De acuerdo, de acuerdo, genial. Y finalmente, solo quiero decir que todo lo mencionado en las diapositivas requirió un gran esfuerzo de todo el equipo. Sé que algunos de ellos están viendo, así que les envío un saludo. Gracias a todos. Definitivamente, sí, no veo ninguna otra pregunta. ¿Hay algo más que sepas, en tu charla, que quisieras ampliar o algún plan futuro, algo más que quieras agregar para la audiencia? Bueno, si tuviera más tiempo, habría dedicado mucho más tiempo a la documentación. Lo mencioné brevemente en la charla. Y realmente fue un enfoque importante. No puedo enfatizar lo suficiente el valor de pensar mucho en eso, y no solo lanzar información en una página, sino tener un flujo de información considerado,

Documentación y Referencia de Consultas

Short description:

Valoramos la documentación obsesiva y hemos encontrado que es muy beneficiosa. Utilizamos vPress como generador de markdown y tenemos una página de pautas de diseño de esquema seleccionadas a mano. Además, tenemos una interfaz interna que muestra las consultas y mutaciones enviadas, sirviendo como referencia para trabajos anteriores. Gracias por asistir a la charla y siéntete libre de hacer más preguntas en la sala de conferencias.

qué es relevante, cómo se ve. Tal vez sea un poco obsesivo, pero creo que eso es algo de lo que obtuvimos mucho valor. Y toda esta conferencia está dedicada a la documentación y sitios web y cosas así. Así que para cualquiera que lo implemente para muchas personas, sí, definitivamente. Sí, de acuerdo. Genial. Y tenemos otra pregunta aquí. ¿Utilizan alguna herramienta especial para organizar su documentación? La organización siempre es difícil para algunos de nosotros.

Utilizamos vPress como generador de markdown. Aparte de eso, es algo seleccionado a mano. Agregamos un pequeño tema, supongo, para que sea rojo para Yelp. Pero sí, aparte de eso, la página de pautas de diseño de esquema, que ahora es de código abierto, por lo que puedes ver que está seleccionada a mano y se hace de una manera que esperemos que fluya. Y también tenemos Iba a decir, algo que no incluí en las diapositivas es que además de la pestaña de documentación de esquema gráfico, también tenemos una especie de interfaz interna donde puedes ver todas las consultas y mutaciones que se han enviado a la lista permitida. Y eso es algo que te permite ver todas las consultas diferentes en Yelp. Y eso ayuda a servir como referencia para lo que es algún trabajo anterior y puedes filtrar por equipo y ver la evolución de una de esas consultas, etc. Sí. Bueno, nuevamente queremos agradecerte mucho por esta excelente charla. Si alguno de los asistentes tiene más preguntas para Mark, vayan a spatial chat a la sala de conferencias. Pueden hacer más preguntas allí. Mark, nuevamente, muchas gracias. Gracias. Cuídense.

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 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
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.

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 Summit 2023React Summit 2023
137 min
Build a Data-Rich Beautiful Dashboard With MUI X's Data Grid and Joy UI
WorkshopFree
Learn how to put MUI’s complete ecosystem to use to build a beautiful and sophisticated project management dashboard in a fraction of the time that it would take to construct it from scratch. In particular, we’ll see how to integrate the MUI X Data Grid with Joy UI, our newest component library and sibling to the industry-standard Material UI.
Table of contents:- Introducing our project and tools- App setup and package installation- Constructing the dashboard- Prototyping, styling, and themes - Joy UI features- Filtering, sorting, editing - Data Grid features- Conclusion, final thoughts, Q&A
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