Video Summary and Transcription
El ponente presenta GraphQL Mesh, una biblioteca que extrae esquemas de servicios existentes y los fusiona en un único punto final de GraphQL. Esto permite la seguridad de tipos y la capacidad de agregar metadatos federados a los servicios existentes. GraphQL Mesh puede funcionar como una puerta de enlace central o una fuente distribuida. El ponente también menciona el uso de plataformas para transmisión y los beneficios de accesibilidad de utilizar contenido HTML semántico. Además, se menciona el soporte de Ionic para aplicaciones nativas. En general, la charla cubre los beneficios y capacidades de GraphQL Mesh y sus aplicaciones en diferentes escenarios.
1. Introducción a GraphQL Mesh
Hola a todos. Mi nombre es Uli y soy el fundador de un grupo llamado The Guild. Somos un grupo que creó GraphQL Code Generator, GraphQL Inspector para comparar esquemas y validarlos antes de ir a producción, GraphQL CLI, GraphQL modules y muchos otros paquetes de la comunidad que mantenemos. Hoy quiero hablar sobre una nueva biblioteca de la que estamos muy emocionados, se llama GraphQL Mesh. GraphQL es genial. Tenemos seguridad de tipos en la red, pero ¿qué pasa con todas las fuentes de datos que consultamos? ¿Deberíamos usar GraphQL en todas partes? Una solución sería construir pequeños puntos finales de GraphQL en esos servicios, en esos antiguos back-ends y enseñarles GraphQL o Federation. Pero muchas veces esos son servidores antiguos como un antiguo servidor Java o un servidor .NET. No se mantienen o las personas allí no aprenderán GraphQL en el futuro previsible.
Mi nombre es Uli y soy el fundador de un grupo llamado The Guild. Tengo poco tiempo, así que iré directo al grano. Somos un grupo que creó GraphQL Code Generator, GraphQL Inspector para comparar esquemas y validar antes de ir a producción, GraphQL CLI, GraphQL modules y muchos otros paquetes de la community que mantenemos. Y nos esforzamos por mantener un nivel muy alto de mantenimiento de nuestras bibliotecas de código abierto. Y los combinamos todos porque los usamos como bloques de construcción o una plataforma completa para construir aplicaciones usando GraphQL.
Pero hoy quiero hablar sobre una nueva biblioteca de la que estamos muy emocionados, pero se llama GraphQL Mesh. Así que GraphQL es genial. Con GraphQL puedes consultar lo que quieras, GraphQL obtendrá lo que necesita de tus data fuentes y te devolverá una respuesta predecible. Y una de las cosas geniales es que en el back-end, los resolvers, sé exactamente en cada resolver, sabemos lo que vamos a obtener del resolver padre y qué necesitamos devolver. Por lo tanto, básicamente podemos conocer esos tipos e incluso generar tipos para las entradas y salidas de esos resolvers.
Pero una cosa que a veces olvidamos es que, sí, tenemos type safety en la red, pero ¿qué pasa con todas las data fuentes que consultamos? Por ejemplo, en el resolver, si estoy llamando a los puntos finales REST que solía llamar antes, no tengo tipos para eso, así que no tengo idea de lo que viene y eso puede ser un problema. Ahora que tenemos GraphQL en el front-end, ¿qué podemos hacer para mejorar el back-end y todas las interacciones que tenemos con él? ¿Deberíamos usar GraphQL en todas partes? Una solución sería básicamente construir pequeños puntos finales de GraphQL en esos servicios, en esos antiguos back-ends y enseñarles GraphQL o Federation, lo cual puede ser bueno, pero muchas veces esos son servidores antiguos como un antiguo servidor Java o un servidor .NET. No se mantienen o las personas allí no aprenderán GraphQL en el futuro previsible. También hay otros problemas, pero no tengo mucho tiempo para hablar de eso.
2. Usando GraphQL Mesh para fusionar múltiples fuentes
Pero, ¿qué pasaría si pudiéramos tomar servicios existentes, extraer sus esquemas, convertirlos en GraphQL y fusionarlos en un único punto final? Eso es exactamente lo que hace GraphQL Mesh. Toma diferentes fuentes, genera un SDK de GraphQL completamente tipado y las fusiona en un único punto final de GraphQL. Con el esquema de unión, podemos combinar GraphQL con otras fuentes como OData, gRPC y GraphQL Federation. GraphQL Mesh resuelve el problema de la seguridad de tipos en los resolvers y ofrece la capacidad de agregar metadatos federados a los servicios existentes.
Como, ¿qué es lo que nos gusta de GraphQL y que queremos en el back-end? Y probablemente eso sea el esquema y el lenguaje de consulta. Entonces, ¿sabes qué podemos hacer con eso? Así que lo pensamos y pensamos que esos back-ends realmente tienen algo de sentido y a veces incluso tienen esquemas, aunque no sean de GraphQL. En el pasado creamos una biblioteca llamada solfa que tomaba un concepto similar en el que tomábamos un servidor GraphQL existente y generábamos endpoints completos de servidor REST y OpenAPI a partir de él para servir a terceros o a otras aplicaciones que no conocen GraphQL. Así que pensamos que tal vez para resolver esos problemas podemos hacerlo al revés. Tal vez podamos tomar esos servicios, obtener sus esquemas, ya sea si están definidos como gRPC o OpenAPI, o tal vez simplemente podemos mirar los registros de sus respuestas y generar esquemas a partir de ahí, convertir cada uno de esos esquemas en GraphQL y luego incluso fusionar en un único punto final de GraphQL en el que básicamente podemos consultar todas nuestras fuentes que necesitamos cuando estamos en nuestros resolvers. Y lo que hemos hecho aquí es básicamente si hacemos eso, podemos aprovechar al máximo GraphQL utilizando todos los servicios existentes que tenemos hoy sin necesidad de cambiarlos o tocarlos o que siquiera sepan qué es GraphQL. Y eso es GraphQL Mesh. Así que GraphQL Mesh toma todas esas diferentes fuentes, hay muchas de ellas, y genera un SDK de GraphQL completamente tipado que se puede ejecutar en cualquier lugar. Básicamente, toma todas esas fuentes y las fusiona en una sola. Veamos un ejemplo. Este es un ejemplo simple en el que tenemos dos API públicas, una de ciudades, que es una API REST con Swagger, y otra de clima, que también es una API pública de Swagger. Así que simplemente definiendo estas dos en nuestra configuración de mesh, podemos comenzar a consultarlas como si fuera GraphQL. Eso es todo. Y esos son solo los puntos finales existentes, tenemos documentación completa, GraphQL, todo. Pero ahí no es donde queremos detenernos. También queremos fusionarlos. Así que podemos agregar un nuevo campo llamado pronósticos diarios en una ciudad. Y en esas funciones que los conectamos a ambos, esta función está completamente tipada porque generamos SDK a partir de ella. Así que ahora, simplemente definiendo este campo, podemos comenzar a consultar no solo la ciudad de Tel Aviv, sino también el pronóstico allí. Y lo que hemos hecho aquí es básicamente la unión de esquemas, no solo en GraphQL, sino en cualquier fuente, lo cual es extremadamente poderoso. Podemos hacer la unión de esquemas entre OData y gRPC. Podemos hacer la unión de esquemas entre GraphQL y GraphQL Federation. Y hay muchas, muchas fuentes que ya se han creado y hay más por venir. Así que OpenAPI y Swagger, gRPC, GraphQL Federation, servicios federados y GraphQL regular, SQL y más. Así que simplemente al tratar de resolver el problema de tener seguridad de tipos completa en nuestros resolvers, básicamente resolvimos un problema mucho más grande. Ahora, GraphQL Mesh tiene mucho más en su interior. Esas fusiones que te mostré con stitching, por cierto, tomamos el control de la unión de esquemas, lo mejoramos y lanzamos nuevas versiones para hacerla sin deprecación. Pero también puedes usar Federation para hacer esas fusiones. Y más que eso, tenemos una oportunidad, tenemos una forma para que tomes servicios existentes e incluso servicios de Swagger y agregar metadatos federados en ellos, y luego federar servicios que no son federados en absoluto.
3. GraphQL Mesh y Datos Distribuidos
Y hay muchas más cosas. Podemos simular cada una de esas fuentes, podemos hacer una instantánea de prefijo, hacer cualquier transformación que queramos, todo es adaptable. Mesh no es una puerta central; puede funcionar como una puerta central o como una fuente distribuida. Al crear una API del clima usando GraphQL y exponer APIs existentes como módulos de malla públicos, podemos conectar datos sin un lugar central. Visita graphicalmesh.com para unirte a la comunidad Guild para más discusiones y avances.
Y hay muchas más cosas. Podemos simular cada una de esas fuentes, podemos hacer una instantánea de prefijo, hacer cualquier transformación que queramos, todo es adaptable. Y lo más emocionante de Mesh es que no es una puerta central. Puede funcionar como una puerta central, pero básicamente puedes generar el SDK y ejecutarlo en cualquier lugar en cada uno de tus servicios. Así que es completamente distribuido. Puede ser como un lugar central o una fuente distribuida.
Y si llevamos esta idea un paso más allá, en realidad podemos comenzar a tomar esos códigos que te mostré en el ejemplo. Y puedes comenzar a crear una API del clima usando GraphQL. Puedes tomar tu propia API bancaria existente y exponerla como un módulo de malla público que expone GraphQL sin que el banco siquiera sepa qué es GraphQL. Y ahora, de repente, incluso puedes exponer la estrategia de fusión de esos datos. Así que ahora tu banco tiene una API pública de GraphQL que también muestra el clima en cada una de sus sucursales, y el banco no hizo nada, lo hizo la comunidad.
Y si llevamos esto un paso más allá, eso significa básicamente que ahora podemos tener módulos de malla públicos que se ejecutan en cualquier lugar y son completamente distribuidos. Así que podemos tener, y son completamente de código abierto, la comunidad es la propietaria, el registro puede ser cualquier registro, NPM, GitHub, lo que sea. Y realmente podemos acercarnos a la web semántica de la Web 3.0. Todos podemos comenzar a exponer datos que están conectados entre sí sin ponerlo todo en un lugar central. Si eso te interesa, ve a graphicalmesh.com y únete a la comunidad Guild. Tenemos discusiones al respecto todo el tiempo y avanzamos muy rápido. Muchas gracias.
Bueno, eso es mucho conocimiento en solo 20 o 28 minutos. Cuatro temas geniales. Me gustaría invitar a todos los oradores de las charlas relámpago al escenario para hacer la última ronda de preguntas y respuestas del día. Hola a todos. Hola. Hola. Hola. Buenos días, tardes, noches, lo que sea para ustedes. Sí, voy a ir directo a las preguntas. Voy a comenzar con la primera pregunta para Matt y Claire. ¿A qué mercado se dirigen y por qué alguien usaría Mox en lugar de Twitch o YouTube? Sí, es una pregunta válida. Somos un producto dirigido a los desarrolladores, por lo que somos simplemente APIs para que los desarrolladores las integren en sus plataformas, a diferencia de Twitch y YouTube, que son productos más orientados al consumidor.
4. Plataformas y Botones Div
Si eres un streamer, utiliza plataformas que te permitan transmitir en vivo sin programar. Si estás construyendo una plataforma, somos una mejor opción. El equipo web de React Native puede usar un div como un botón para envolver contenido HTML no semántico y hacerlo accesible. Jen amablemente toca el hombro y sugiere usar un div accesible. Martin van Houten elogia a Mash y comparte experiencias positivas. La empresa Albert Hein utiliza Mash.
Entonces, si eres un streamer que solo quiere transmitir en vivo sin escribir ningún código, esas son excelentes plataformas que probablemente deberías usar. Si estás intentando construir una plataforma, probablemente seamos una mejor opción allí.
OK, así que se trata más del público objetivo, supongo, y de que tienes más control sobre lo que estás haciendo. Sí, lo pensaría un poco como una mala analogía que mencioné en Slack, ellos son más como PayPal o Venmo. Nosotros somos más como Stripe, si lo piensas en términos de APIs de pago.
OK, gracias. La próxima pregunta es para Jen. ¿Cuáles son las razones por las que alguien como el equipo web de React Native querría usar un div como un botón? La razón es que colocar HTML dentro de un botón no es realmente HTML semántico. Entonces, pueden querer envolver ese contenido, por ejemplo, una tarjeta o un bloque de imagen y texto, en un div y convertirlo en un botón accesible en lugar de poner un botón alrededor de él.
Sí, por lo tanto, si tienes una tarjeta completamente clickable con diferentes elementos dentro, no puedes hacerlo de manera semántica dentro de un botón. Correcto. Entonces, en ese caso, querrás hacer un div accesible. Bueno, al menos deberías querer hacerlo. Quizás. Y puedo decir, si no lo haces, Jen vendrá y te lo dirá amablemente. Te tocaré el hombro y te haré sugerencias. ¿Qué tal eso? Sí. Sí, pero tocar no funciona. Entonces, tal vez lo piratee. Sí, sí.
No es una pregunta, pero solo para darte un toque amable en el hombro de Martin van Houten, no realmente una pregunta. Solo quiero decir que Mash se ve increíble. Bueno, siempre es agradable escuchar eso. Gracias. Muchas gracias. Gracias. Y espero que después de probarlo, sientas lo mismo y no me odies. Bueno, en realidad, en la empresa para la que trabajo, Albert Hein, lo estamos utilizando. Y debo decir que ha sido un placer. Así que muchas gracias. Oh, eres mi vecino.
5. Visiting and Ionic Support
Puedo ir a visitarte. Sí, eso sería gezellig. Mike, ¿Ionic admite aplicaciones nativas similares a React Native? Es una mezcla de ambos. La mayoría de la interfaz de usuario se muestra en una vista web, pero puedes integrarla con vistas nativas personalizadas o actividades en Android. Eso se siente poderoso. Gracias, chicos y señorita, por estas excelentes charlas. La parte formal ha terminado. Adiós.
Puedo ir a visitarte. Sí, eso sería gezellig.
Mike, ¿Ionic admite aplicaciones nativas similares a React Native? ¿O es como una aplicación estándar de Cordova donde es una interfaz de usuario web en lugar de una aplicación nativa? Entonces es una mezcla de ambos. La mayoría de la interfaz de usuario se muestra en una vista web, pero puedes integrarla con vistas nativas personalizadas o actividades en Android y mezclar cuál se muestra. Puedes tener la vista web o la vista nativa, o incluso superponer la vista nativa encima de la vista web. Así que obtienes lo mejor de ambos mundos. Eso se siente poderoso.
De acuerdo, gracias. Gracias, chicos y señorita, por estas excelentes charlas. Para las personas que están viendo, también estarán en las salas de Zoom para preguntas, pero la parte formal ha terminado. Me voy a despedir por un rato. Así que gracias por unirse. Gracias Gracias. Adiós. Adiós. Gracias.
Comments