Panel Discussion 'El Futuro de GraphQL del Lado del Servidor'

Déjame presentar a esos distinguidos invitados, comenzando con Benji de GraphL. GraphL es un proyecto de código abierto financiado por la comunidad y Benji es el principal mantenedor. Le encanta hacer GraphQL, realmente le encanta hacer GraphQL y ayudar a la comunidad. Estoy realmente emocionado de tener a Benji aquí. Tenemos a Danielle Mann de Apollo. Ella es directora senior de ingeniería en Apollo. Danielle ha estado trabajando en hacer que GraphQL sea más fácil y más agradable de usar durante los últimos seis años y medio. Es increíble tener a alguien con tanta experiencia aquí.

Y Tim Shuchanik de Stellate. Él es el cofundador y CEO de Stellate. Tim fue el primer empleado en el primer backend de GraphQL como servicio, GraphQL, que todos recordamos hace seis años y medio y ahora está trabajando en hacer que sea fácil ejecutar APIs de GraphQL en producción en Stellate. Y Fredrik Georg de Graphbase. Él es el fundador y CEO de Graphbase. Ellos hacen, es súper fácil desplegar backends de GraphQL sin servidor. Así que gracias a todos por unirse a mí y por este panel. Sabes, este panel tiene un título muy grande, ¿Cuál es el futuro de GraphQL? Y creo que todos nosotros probablemente tenemos muchas perspectivas diferentes de todas las muchas áreas diferentes de las que las personas aquí son parte.

Así que tal vez podamos comenzar con Benji. Solo en términos muy, digamos, generales. ¿Cómo ves las tendencias actuales en GraphQL? ¿Dónde comenzamos y dónde estamos hoy y algunas de las cosas emocionantes que estás viendo por ahí? Gracias, Yuri. GraphQL, creo, ha crecido de manera bastante impresionante. Ha despegado desde su lanzamiento en 2015. Y es realmente interesante ver a la gente. Creo que el GraphQL base abordó muchos de los problemas de las personas, y ahora estamos comenzando a ver los casos extremos de esos donde ciertos patrones no están completamente cubiertos, y luego estamos buscando lidiar con esos. Así que en mi trabajo con el grupo de trabajo, hemos estado recibiendo las solicitudes y las ideas de varias personas sobre cómo avanzar GraphQL, cómo hacerlo servir a todas estas diferentes necesidades. Y creo que Lee habló antes sobre el nuevo flujo de deferencia, que es una de las cosas emocionantes que se están añadiendo a GraphQL actualmente, lo cual es genial.

Pero también hay un gran número de otras propuestas que se están trabajando como formas de avanzar GraphQL. Y algunas de ellas pueden nunca ver la versión final real en las especificaciones. Algunas de ellas pueden generar mejores ideas que resuelvan los problemas de mejores maneras. Pero lo que me encanta ver es a la gente realmente involucrándose y trabajando juntos para encontrar estas soluciones a estos problemas comunes. Y en lugar de pensar, ¿cómo puedo resolver esto para mi único negocio? Pensar, ¿cómo puedo resolver esto para todos los que usan GraphQL? Para que esta marea creciente pueda elevar todos los barcos, por así decirlo.

Sí, y veo... También estoy realmente interesado en la perspectiva de Daniel porque sé que en Apollo, básicamente probablemente piensan tanto en las historias de usuarios y cuántos tipos diferentes de empresas están usando GraphQL, tanto en el front-end como consumidores y en el back-end. ¿Cómo abordas esta pregunta?

Sí, creo que a medida que han pasado los últimos seis años y medio, realmente hemos visto a GraphQL pasar de ser una tecnología muy temprana que necesitaba solo muchas herramientas básicas para ayudarte a usarla en general, a que ahora estamos entrando en una fase de mayoría temprana donde mucha gente está buscando cosas más sofisticadas de GraphQL y comenzando a construir sobre GraphQL para hacer cosas como defer o para hacer cosas como consultas en vivo, que es algo de lo que hablamos en Apollo.

Así que estoy realmente, quiero decir, incluso solo por el caso de uso de defer, estoy realmente emocionado por cómo estamos comenzando a poder implementarlo porque con defer, no solo hace que tus consultas de GraphQL sean más eficientes. Quiero decir, bueno, sí lo hace, pero no se trata solo de hacer que tus consultas sean más eficientes. De hecho, una vez que has trasladado ese tipo de consideración de cómo se cargarán los datos en fragmentos de vuelta a la capa de consulta de GraphQL y fuera de tu capa de renderizado de React, puedes hacer que tus aplicaciones de React sean mucho más simples. Vas a arquitectar componentes de una manera diferente porque ya no vas a necesitar dividir las páginas del front-end componente por componente solo porque necesitas cargar datos progresivamente.

Así que incluso solo en el último mes, he comenzado a jugar con defer y algunas de mis propias aplicaciones porque tuvimos una implementación temprana en Apollo y me di cuenta de algunas de esas cosas. Y tuve este momento de como, oh Dios mío, esto va a cambiar cómo las personas construyen sus componentes front-end. Esto es increíble. Estoy emocionado por GraphQL de nuevo. Y así que estoy realmente emocionado de que estamos entrando en esta fase de defer, consultas en vivo, caché, lo que Tim está haciendo, todas estas otras cosas increíbles sobre GraphQL ahora que hemos superado lo básico de solo hacer GraphQL disponible para las masas.

¿Qué crees que sería la cosa conceptual más grande que las personas ahora pueden hacer con defer? ¿Cuál fue el mayor momento de revelación para ti cuando comenzaste a jugar con esto? Así que mi momento de revelación, tenemos una gran aplicación front-end en Apollo llamada Studio y cada vez que cargamos una lista de cosas, tenemos una consulta para la lista y luego una consulta para cada componente de la lista para que la lista pueda aparecer, pero luego los metadatos de esa lista pueden cargarse de manera más progresiva. Y así que cuando solo cargas una página, son tal vez como 100 consultas, que son demasiadas. Y así que tuve este momento de revelación de como, oh Dios mío, con defer, esto ya no necesita organizarse de esta manera, esto puede ser solo una consulta, va a ser mucho mejor para los desarrolladores front-end que ya no tienen que dividir este componente en estos límites, va a ser mucho mejor para el servidor que ya no tiene que lidiar con una carga mega. Así que incluso solo eso fue un momento tan simple, pero pensé, el potencial aquí es tan emocionante.

Sí, estoy de acuerdo. Y también mencionaste consultas en vivo. Y sé que GraphVis ha comenzado a jugar un poco con esas cosas. Quizás puedas tomar la pregunta desde tu perspectiva, Frederick. ¿Cuáles son las cosas más emocionantes que se avecinan para ti? Absolutamente. Quiero decir, creo que solo para hacer clic en GraphQL, donde estamos, creo que el hecho de que se esté volviendo un poco aburrido es algo bueno, ¿verdad? Ya no se debate acaloradamente. Está aquí, y ha venido para quedarse. Y estoy bastante emocionado por eso. Ahora, estamos refinando y añadiendo cosas para facilitar que cualquiera lo adopte y generalizar patrones comunes. Así que me gusta eso. Pero sí, de nuestra parte, también estamos mirando defer y stream, y de hecho tenemos soporte experimental para consultas en vivo ya. Y la mayoría de las personas, creo, conocen las suscripciones de GraphQL, pero no todos conocen las consultas en vivo. Así que ese es otro ejemplo de hacer que el tiempo real sea realmente fácil. Y eso es obviamente algo que nos importa profundamente porque nos importa profundamente porque queremos hacer que los servidores GraphQL sean más fáciles. Porque creo que el tipo de conocimiento común, al menos en mi experiencia, ha sido que construir servicios GraphQL es un poco difícil y fragmentado. Así que eso es algo que estamos emocionados de mejorar.

Sí, eso me lleva a la siguiente pregunta. Estoy de acuerdo contigo en que hemos llegado a la... Es gracioso cómo dijiste que hemos llegado a la fase aburrida donde sabemos más o menos qué es GraphQL. Tenemos estas cosas, pero ahora hay algunos desafíos. Creo que probablemente alguien que ha estado en este problema durante tantos años es Tim, por GraphQL. ¿Verdad? Donde eres uno de los primeros que realmente miró cómo hacerlo lo más fácil posible, lo más simple posible. Y has pasado por muchas olas e iteraciones durante estos seis años y medio. ¿Dónde ves los desafíos actuales de dónde estamos, y cuáles serían las alas más fáciles para avanzar para la comunidad? Creo que esa es en realidad una buena pregunta, y definitivamente tengo pensamientos al respecto. Creo que hay dos, digamos, grandes áreas. Veo la educación y las herramientas. Y diría incluso que la educación es probablemente más importante en este momento, porque vemos que hay muchas malentendidos. Cada segundo día hay una discusión en estos días. Es una mala herramienta o lo que sea. Y ves que hay solo un malentendido básico. Creo que comienza con, vemos que GraphQL es muy valioso en los equipos y empresas que tienes. GraphQL es una herramienta de colaboración. Reúne a las personas en la misma mesa y pueden hablar sobre algo. Y ahora, de alguna manera, una función de forzado tiene muchas ventajas allí. Y creo que eso sigue siendo algo que muchas empresas no entienden. Y para eso primero necesitas entender tu propio, primero necesitas ser auto-introspectivo en la empresa, entender tus propios problemas. Digamos que hay 10 diferentes soluciones de autorización por ahí. ¿Cuál es el problema? Puede ser un problema de gobernanza. Una vez que lo identifiques ahora puedes ver si puede haber una herramienta que nos ayude. Y creo que eso es como unos pocos pasos más adelante. Y es mucha educación la que necesita suceder para realmente obtener como los beneficios, como también el estilo relay, GraphQL también sigue siendo bastante diferente de lo que es usar, digamos, muchos de, digamos, proyectos iniciales. Y la gente tiene como esta barrera para relay, aunque hay muchas ventajas en ello. Y creo que se necesita mucha educación en el lado de las herramientas. Creo que todos aquí están trabajando en algo para hacer que sea más fácil y avanzar GraphQL. Y es un gran, como es algo en todos nosotros, ¿verdad? No solo una persona o empresa puede avanzar eso.

Y creo que mientras todos avancemos juntos y eso es como, la especificación está combinando todo esto, nos mantiene unidos. Creo que eso es increíble.

Sí, creo que estoy de acuerdo. Creo que la educación es muy importante. Y también, pero siempre me pregunto si podemos. La educación a veces también significa que las personas necesitan saber más cosas o, ya sabes, algunas cosas simplemente tienen sentido cuando estás entrando en aplicaciones más complejas. Pero siempre me pregunto, ¿podemos construir mejores herramientas para el principiante, donde sabes, comienzas fácil, obtienes lo que quieres, y luego simplemente gradualmente, ya sabes, gradualmente entras en donde quieres sin, no sé, saltar entre cosas.

O me pregunto si alguno de ustedes tiene, no sé quién quiere tomarlo como, pero ¿cómo imaginan que resolveremos este camino en el futuro? Como, digamos que soy un principiante, estoy comenzando, sé que soy un principiante pero soy un desarrollador que está comenzando una nueva aplicación, y quiero comenzar fácil y rápido, pero luego quiero asegurarme de que no estoy, ya sabes, encerrándome con cosas. ¿Creen que estamos ahí ahora? ¿Creen que hay cosas que necesitan ser cambiadas? ¿Tienen ideas concretas sobre cosas así? Tal vez Danielle, tú puedes tomarlo.

Sí, de hecho... Bueno, quería preguntar al resto de los panelistas porque mi opinión sobre eso es que tenemos tanto material para ayudar a los recién llegados completos a GraphQL, GraphQL a comenzar con GraphQL, como tenemos kits de inicio, tenemos muchas rampas fáciles, pero siento que lo que aún estamos en el proceso de construir en esta comunidad es respuestas fáciles, estándares fáciles para las preguntas más complicadas y avanzadas.

En el lado de Apollo, tenemos muchos tutoriales, tenemos nuestros cursos de aprendizaje Odyssey, tenemos mucha documentación con guías para comenzar para... Sí, ¿cómo escribes un resolver? Sí, ¿cómo escribes una consulta en tu aplicación cliente? Pero una vez que comienzas a abordar temas más avanzados, complicados, mucho de eso sigue estando muy dentro de empresas específicas, equipos técnicos específicos, y siento que no hemos estandarizado esas respuestas.

Benji, en realidad tenía curiosidad desde tu perspectiva sobre cómo piensas en eso, porque justo antes de que comenzáramos el panel, Benji y yo estábamos hablando sobre su nuevo proyecto en torno a una forma diferente de escribir resolvers de GraphQL, así que tengo curiosidad sobre cómo piensas en enseñar a las personas a hacer GraphQL mientras están en el back end. Sí, es una gran pregunta. Y creo que una de las cosas clave a tener en cuenta con GraphQL es que siempre se construyó para resolver problemas del cliente. Siempre se construyó para resolver los problemas del front end. Y así como describías antes, Danielle, con defer y tu momento de avance, ayuda, siempre se centra en eso, en hacer que esos front ends sean más fáciles.

Pero como dijo Frederick antes, no siempre es lo mejor para hacer que los back ends sean más fáciles. Y hay tantas diferentes enfoques para construir esquemas de GraphQL. Quiero decir, incluso elegir qué lenguaje de programación vas a usar para construirlos es una primera pregunta. Y luego, incluso a partir de ahí, tienes varias preguntas diferentes dependiendo de qué bibliotecas tienes disponibles. ¿Quieres ir primero por el esquema? ¿Quieres ir primero por el código? ¿Quieres ir primero por la base de datos? ¿Quieres generación automática? ¿Quieres hacerlo manualmente? Incluso hay preguntas fundamentales sobre el diseño de tu esquema. Como, ¿deberías estar usando conexiones de cursor o solo quieres listas simples? Y creo que muchas personas siempre quieren comenzar de la manera más simple. Pero una de las cosas que GraphQL intenta ayudarte a lograr es hacer que tu esquema sea compatible hacia atrás. Quieres poder agregar cosas a tu esquema sin romper aplicaciones anteriores. Y así hay bastantes patrones en GraphQL que inicialmente parecen sobrecomplicados. Así que conexiones, por ejemplo, el patrón de mutación donde tienes un objeto de entrada y un objeto de carga útil, y varias cosas así que la gente podría pensar inicialmente, no necesito todas estas cosas. Si voy a crear una publicación, solo necesito devolver la publicación. Pero luego, cuando se dan cuenta, oh, en realidad, cuando creo la publicación, también quiero saber, tal vez me cueste algo de dinero crear la publicación. ¿Cuántos créditos me quedan después de esto? Si lo hubieras hecho con una carga útil, entonces habría este espacio después. Así que siempre se trata de pensar en términos del futuro de tu esquema. Y creo que eso es quizás donde la educación en el front end sobre cómo consumir GraphQL es relativamente directa. Porque ya tienes un esquema. Alguien ya lo ha diseñado para ti. Ahora, todo lo que necesitas saber es cómo lo consulto, cómo integro esto con React o Vue o Angular, lo que sea con lo que estés trabajando. Mientras que en el back end, no se trata solo de aprender lo que GraphQL puede hacer, sino también de aprender lo que debería hacer y cómo eso se integra con tu dominio empresarial. Y creo que ese es un desafío bastante difícil de resolver en general.

Preguntaste sobre mi proyecto, que se llama Graphast. Y una de las cosas que veo que mucha gente dice sobre GraphQL es, ya sabes, el problema de N más uno y el problema de la caché y varias cosas así. Lo que Graphast se propone hacer es resolver estos problemas desde el principio al deshacerse del modelo de ejecución basado en resolvers que tenemos en GraphQL actualmente y reemplazarlo con un modelo de ejecución completamente alternativo. Ahora, esto no quiere decir que los resolvers sean concretamente malos ni nada por el estilo. Es más para decir que los resolvers establecen como la línea base de cómo debería verse, cómo debería ser percibido por el usuario como si hiciera esto. Pero en el backend, si hacemos algo un poco más avanzado, pero no necesariamente con un código más complicado, podemos lograr mejores resultados y podemos evitar, podemos eludir un buen número de estos problemas, el problema de N más uno y mucho más desde el principio. ¿Cuáles son otras ideas interesantes que facilitan resolver, construir servidores gráficos en el backend? ¿Ves otras ideas interesantes? Por cierto, vi un vistazo de Graphast que es muy emocionante, pero sé que ambos equipos y tanto los equipos como Frederik también tienen ideas interesantes allí. Frederik, tal vez quieras también dar una idea de cómo ves esta idea de que escribir GraphQL en el backend es difícil. Estaba en silencio, lo siento. Iba a continuar con lo que Benji dijo allí en términos de que, ya sabes, hay muchas decisiones que tienes que tomar antes de que realmente veas la API en una URL en producción en algún lugar y creo que ese es el problema que queremos resolver y queremos tener una barrera de entrada realmente baja comenzando con tu terminal y desarrollo local ¿verdad? No quiero que tengas que instalar Docker o Java o configurar archivos YAML complicados o algo así.

Quiero llevarte de la idea a la URL y ese es el tipo de referencia que necesitamos buscar. Debería ser minutos, no como un día o dos, ¿verdad? Así que creo que esa es una propuesta interesante y creo que, sabes, estamos comenzando con lo más simple en mi mente, que es un archivo y su esquema primero, pero por supuesto, como veo los beneficios de tener código primero cuando alcanzas cierta escala, así que definitivamente lo permitiremos, pero ¿cuál es la forma más simple de hacer que un desarrollador front-end despliegue una API de GraphQL? Eso es realmente lo que estamos buscando ahora y, con el tiempo, hacer que sea más interesante para los desarrolladores full stack y back-end desplegar servidores de GraphQL y creo que, si pusiera una analogía de dónde estamos ahora, se siente como donde estaba React antes de que hubiera un marco y otro marco, así que un marco para React, siento que necesitamos más marcos para GraphQL que lo hagan realmente fácil de adoptar y no voy a usar nombres, pero creo que conoces los nombres y son realmente exitosos y me gustan, pero ahora también estamos viendo que eso va a otra fase, pero creo que eso es lo que espero de la próxima generación de marcos.

Supongo que es interesante tus ideas, tu idea de marcos porque quiero decir, estamos hablando aquí sobre back-end y front-end, pero también en GraphQL es un poco como que ha hecho las fronteras un poco más raras, como hay muchos desarrolladores front-end que comenzaron a escribir esquemas y resolvers y código de back-end y de repente las fronteras se volvieron menos expresivas, como ¿de quién estamos hablando ahora que estamos escribiendo el back-end y creo que una de las cosas que me gustó de GraphQL es que para mí personalmente, incluso solo abrió las puertas para aprender sobre todas estas preocupaciones que Benji mencionaba, como antes de eso, era como, sabes, ni siquiera lo pensaba, pero con GraphQL, me fui como gradualmente metiendo en eso, como comencé con, sabes, solo escribiendo GraphQL y luego tuve que resolver esto y tuve que resolver eso y me metí en esto y me metí en aquello, así que supongo que también hay una pregunta de que tal vez es menos back-end y front-end, sino más, llamémoslo implementación de fuente de datos, APIs de GraphQL consumidas por el front-end, como hay muchas fronteras diferentes allí y los roles también son diferentes, supongo que creo que también para mí, quiero decir, quería hacer, hay la complejidad en el back-end que mencionamos, creo que para mí también hay esta pregunta en el front-end, como creo que para nosotros o para las personas aquí, mirar la consulta de GraphQL parece la más simple y hermosa y solo como una abstracción muy agradable, pero creo que lo que vemos de la comunidad en los últimos meses, al menos, es que tal vez para algunas personas no es la más no es la mejor, como vemos más y más personas que son, sabes, llamémoslos desarrolladores front o desarrolladores de producto que nos están diciendo cosas como, sabes, tal vez GraphQL no es lo suficientemente fácil para nosotros, tal vez queramos algo más simple para algunos casos, como sabes, hay el, llamémoslo, el elefante en la habitación, pero PRPC, por ejemplo, o sabes, todo tipo de alternativas y me pregunto, tengo una opinión muy particular al respecto, pero me pregunto si alguno de ustedes quiere, ¿cuál es su opinión sobre este tipo de tendencia o este tipo de, llamémoslo, el sentimiento en este momento donde la gente dice que GraphQL en el front-end es más difícil de lo que debería ser, um, tal vez puedes ir tú primero, sí, quiero decir, he estado construyendo el Prisma Client que es básicamente acceso seguro a tipos a tus bases de datos, como no es un ORM, es un generador de consultas y, um, en realidad la implementación bajo el capó se ve bastante similar a GraphQL, así que es posible construir algo que sea agradable y fácil de consumir desde TypeScript, tienes un poco de un sobrecoste de sintaxis siempre, creo que la sintaxis mínima absoluta hermosa sigue siendo GraphQL, um, probablemente no puedes reducirla, sin embargo, algo que creo que es hermoso en tRPC es que tienes una inferencia de tipo global que viene sin que yo tenga que proporcionar el tipo de objeto de salida puedo usarlo directamente en el front-end y lo que sea que esté devolviendo, he terminado con eso y quiero decir, en un sentido, esa es la, um, esa es una compensación que haces con GraphQL que también tienes con REST, ¿verdad? Recientemente hablé con alguien que estaba usando REST en una empresa que acaba de crecer de 40 a 400 personas y tienen el mantra de si necesitamos un endpoint, simplemente lo construimos y puedes escalar bastante lejos con eso y creo que lo que es agradable de eso es que cada endpoint de REST es como un contenedor aislado casi, esa cosa solo hace lo que hace y puedes controlarlo, por supuesto, no es realmente escalable y hay una razón por la que muchas grandes empresas llegaron a la misma conclusión de que la dirección de GraphQL, Falcor y demás se movieron en esa dirección, así que creo que a cierta escala tiene sentido, también creo que hay, por supuesto, un punto a hacer sobre hacer algunas selecciones predeterminadas, tal vez en la construcción que en el cliente, esa es una decisión de diseño que tomamos en los días con el cliente de Prisma que decimos que los escalares son, por ejemplo, la selección predeterminada en muchos casos si dices usuario encuentra muchos y el servidor y la base de datos están uno al lado del otro, está bien y creo que eso es algo que también ves en muchas implementaciones de servidores de GraphQL, probablemente no es algo que sucederá en, supongo, en Graph Fast, para eso es, ¿verdad? para tener realmente este plan de consulta super optimizado pero, um, sí, creo que tal vez mirar las selecciones predeterminadas podría ser una dirección también y personalmente soy un gran fan de los enlaces de TypeScript y también quiero mencionar que quiero decir, Flow todavía existe, ¿verdad?

Quiero decir, se trata de TypeScript estos días, ¿verdad? y Flow existe y quiero decir, no hace mucho tiempo añadieron más soporte de lenguaje GraphQL directamente en el lenguaje y eso también podría ser una oportunidad, uh, con TypeScript, quiero decir, GraphQL ahora no es solo un pequeño lenguaje de nicho más, también podríamos ver si hay algo que podamos hacer que sea muy interesante, creo que, um, sí, siempre hay la pregunta de cuándo, también en el front-end y también en el back-end, pero en el front-end, ¿cuándo deberías comenzar a introducir GraphQL y creo que, um, sí, como dijiste, la integración de TypeScript hoy. Creo que algo que muchas personas mencionan es doloroso, um, como, uh, miran el paso de cogent como algo que es doloroso para ellos, um, y quieren como inferencia, pero, uh, personalmente lo que, como probamos todo tipo de cosas, actualmente hay algunas características que faltan en TypeScript que en realidad lo hacen un poco más difícil, pero podría ser interesante abordarlo como comunidad, tal vez para que no necesites un paso de coaching en el front-end.