Panel Discussion: GraphQL Working Group

Gracias por tenernos aquí, y estoy realmente emocionado por esta discusión en el panel. Creo que el tema es realmente interesante y algo que debería ser destacado más, y es realmente importante.

Así que estoy realmente emocionado por la oportunidad. Presentaré a algunos de los increíbles panelistas que tengo aquí hoy, que espero que hablen tanto o menos como pueda y les dé el escenario. Primero que todo, Brielle Harrison es una Gerente Principal Senior en PayPal y ha estado trabajando con GraphQL desde que trabajó como ingeniera en Facebook desde 2013 hasta 2015. También forma parte del Comité de Dirección Técnica de GraphQL. Tenemos a Benji, que es un desarrollador de código abierto fundado por la comunidad, mantenedor de PostGraphQL y miembro del Comité de Dirección Técnica de GraphQL. Lee Byron es uno de los co-creadores de GraphQL y el director de la Fundación GraphQL, así como gerente de ingeniería en Robinhood. Y Sasha Salmon, ella es ingeniera de software del personal y co-líder técnico del equipo de plataforma en Twitter.

También forma parte del Comité de Dirección Técnica y de la Fundación GraphQL. Así que hay muchas personas increíbles aquí y tenemos mucho de qué hablar. Así que tal vez comience con una pregunta básica, pero creo que es muy interesante, que es ¿qué es realmente el grupo de trabajo de GraphQL y por qué lo necesitamos?

¿Alguien quiere tomar eso primero? Puedo comenzar con esto. Entonces, grupo de trabajo, ¿qué es? ¿Por qué lo necesitamos? ¿De dónde vino? El grupo de trabajo y el Comité de Dirección Técnica son en realidad dos cosas relacionadas pero diferentes. Y el grupo de trabajo es una sala, una sala virtual, así como esta, donde un grupo de personas que se preocupan por cómo se desarrolla GraphQL a lo largo del tiempo se reúnen una vez al mes y hablan sobre en qué están trabajando. Y tratamos de avanzar y trabajamos juntos para resolver problemas. Y, en última instancia, muchos de esos problemas se fusionan en la especificación de GraphQL y se reflejan en gran parte del software que todos ustedes utilizan. Pero ese no es el modelo que utilizan todos los proyectos de código abierto. Ciertamente no es el modelo que utilizan todos los proyectos. Y así, no era obvio que necesitaríamos esto. Así que, creo que es quizás un poco útil escuchar un poco de la historia del proyecto, tal vez a través de la lente de cómo se trabaja en lugar de lo que es. Así que, GraphQL se inició en 2012 y era solo una idea loca en ese momento. Así que, la forma de trabajo allí era como un par de personas escribiendo solicitudes de extracción o en Facebook, las llamamos diffs, y revisión de código. Así que, la mayor parte del trabajo real se realizó a través de la revisión de código. Y ese fue el modelo de trabajo durante unos tres años, como probablemente lo es para muchos de ustedes y todo el trabajo que hacen día a día en sus trabajos. Nos estábamos preparando para abrir el código de GraphQL en 2015. Y en el proceso de eso, hicimos algunos cambios bastante significativos. Y la forma en que hablamos sobre esos cambios fue como propuestas. Así que, escribiría una propuesta para cambiar la sintaxis de alguna manera significativa.

Gracias por tenernos aquí, y estoy realmente emocionado por esta masterclass. Creo que el tema es realmente interesante y algo que debería ser destacado más, y es realmente importante. Así que estoy realmente emocionado por la oportunidad. Voy a presentar a algunos de los increíbles panelistas que tengo aquí hoy, que espero hablar tanto como pueda o menos y darles el escenario. Primero que todo, Brielle Harrison es una Gerente Principal Senior en PayPal y ha estado trabajando con GraphQL desde que trabajó como ingeniera en Facebook desde 2013 hasta 2015. También forma parte del Comité de Dirección Técnica de GraphQL. Tenemos a Benji, es un desarrollador de código abierto fundado por la comunidad, mantenedor de PostGraphQL y miembro del Comité de Dirección Técnica de GraphQL. Lee Byron es uno de los co-creadores de GraphQL y el director de la Fundación GraphQL, así como un gerente de ingeniería en Robinhood. Y Sasha Salmon, ella es ingeniera de software del personal y co-líder técnico del equipo de plataforma en Twitter. También forma parte del Comité de Dirección Técnica y la Fundación GraphQL. Así que hay muchas personas increíbles aquí y tenemos mucho de qué hablar.

para nosotros que ahora está disponible públicamente. Así que, tuvimos que cambiar un poco la forma en que las personas estaban interactuando con nuestro proyecto de código abierto. ¿Puedes escribir lo que quieres hacer? Haz un documento de diseño. Haremos una revisión. Y el grupo de trabajo surgió de esto. Nos dimos cuenta de que algunas de esas cosas son bastante sencillas. Podríamos hacerlas todas de manera asíncrona. Podríamos comentar sobre tu diff.

Pero tu diff comenzaba con un gran bloque en la parte superior que describía lo que ibas a hacer. Otras personas necesitaban mucha más retroalimentación. Estableceríamos llamadas en vivo. De hecho, para algunos de esos, conduciríamos a donde fuera su oficina y hablaríamos con ellos en persona. Descubriríamos qué es lo que querían hacer. Estilo antiguo, entrar en una sala con una pizarra y un marcador y dibujar cosas hasta que todos estuviéramos seguros sobre qué problema estábamos resolviendo y por qué. Luego esto comenzó a escalar. Había muchas más personas que estaban contribuyendo. Había muchas más personas que estaban usando GraphQL y querían tener voz. Querían asegurarse de que si un cambio significativo iba a suceder, pudieran aportar su opinión y asegurarse de que funcionara. El núcleo de nosotros trabajando en GraphQL, queríamos asegurarnos de que cualquier cambio que hiciéramos, tuviéramos confianza de que no solo funcionaría para nosotros en nuestra empresa, sino que también funcionaría para todos los demás en sus empresas.

Comenzó a formalizarse más y más. Comenzó con una frecuencia un poco ad hoc. Lo haríamos cuando lo necesitáramos y creo que en algún momento tuvimos aproximadamente seis o siete de ellos al año. Decidimos fijarlos en el calendario y hacerlos cada mes. Creo que decidimos comenzar a hacerlos mensualmente hace tres años y medio o cuatro.

En este punto ahora, es una reunión saludable y de larga duración con un puñado de caras muy familiares, pero con una rotación constante de personajes de personas que tienen algo interesante en lo que están trabajando. Lo traen para jugar con nosotros. Gracias. Esto es realmente interesante y estoy muy propenso a unirme a algunas de esas reuniones. Me encantaría escuchar de otros. ¿Cuál fue tu experiencia cuando te uniste y qué obtuviste de ello? Brielle, tal vez puedas compartir la tuya. Claro, solo estoy verificando si estoy en silencio.

Así que tal vez comience con una pregunta básica, pero creo que es una muy interesante, que es ¿qué es realmente el grupo de trabajo de GraphQL y por qué lo necesitamos? ¿Alguien quiere tomar eso primero? Puedo comenzar con esto. Entonces, grupo de trabajo, ¿qué es? ¿Por qué lo necesitamos? ¿De dónde vino? El grupo de trabajo y el Comité de Dirección Técnica son en realidad dos cosas relacionadas pero diferentes. Y el grupo de trabajo es una sala, una sala virtual, así como esta, donde un grupo de personas que se preocupan por cómo se desarrolla GraphQL a lo largo del tiempo se reúnen una vez al mes y hablan sobre en qué están trabajando. Y tratamos de avanzar y trabajamos juntos para resolver problemas. Y, en última instancia, muchos de esos problemas se fusionan en la especificación de GraphQL y se reflejan en gran parte del software que todos ustedes utilizan. Pero ese no es el modelo que utilizan todos los proyectos de código abierto. Ciertamente no es el modelo que utilizan todos los proyectos. Y así, no era obvio que necesitaríamos esto. Así que, creo que es quizás un poco útil escuchar un poco de la historia del proyecto, tal vez a través de la lente de cómo se trabaja en lugar de lo que es. Así que, GraphQL se inició en 2012 y era solo una idea loca en ese momento. Así que, la forma de trabajo allí era como un par de personas escribiendo solicitudes de extracción o en Facebook, las llamamos diffs, y revisión de código. Así que, la mayor parte del trabajo real se realizó a través de la revisión de código. Y ese fue el modelo de trabajo durante unos tres años, como probablemente lo es para muchos de ustedes y todo el trabajo que hacen día a día en sus trabajos. Nos estábamos preparando para abrir el código de GraphQL en 2015. Y en el proceso de eso, hicimos algunos cambios bastante significativos. Y la forma en que hablamos sobre esos cambios fue como propuestas. Así que, escribiría una propuesta para cambiar la sintaxis de alguna manera significativa. Escribiría un documento. Y luego se lo daría a mis compañeros de trabajo y ellos me darían retroalimentación. Podrías hacer esto como documentos de diseño con tu equipo. Si vas a hacer un gran cambio en un proyecto en el que trabajas, quieres escribir lo que quieres hacer antes de hacerlo para poder obtener buenos comentarios. Y ese era un poco mi modelo mental en ese momento. Y no era el único escribiendo propuestas. A medida que hacíamos eso, y luego a medida que abrimos el código, tuvimos este tipo de cambio de fase donde ahora las personas estaban escribiendo solicitudes de extracción a nosotros. Teníamos todo el código en GitHub. Así que, recibiríamos estas solicitudes de extracción. Por favor, revisa mi diff. Ya habíamos progresado de, como, por favor revisa mi diff en 2012, hace tres años, a documentos de diseño con revisión formal internamente. Este era un proyecto interno importante para nosotros que ahora estábamos haciendo disponible públicamente. Así que, tuvimos que cambiar un poco cómo las personas estaban interactuando con nuestro proyecto de código abierto.

para su espacio local. El grupo de trabajo es realmente bueno, porque cuando tienes esto, puedes entrar y proponer lo que funciona realmente bien para ti, para tu propia empresa, y tratar de sacar esas ideas. Inevitablemente, casi siempre descubres que lo que funciona bien para ti no siempre funciona bien para todos los demás, y por eso ese tipo de grupo es realmente importante tenerlo. Creo que hay muchas historias anecdóticas de las que no tenemos tiempo para hablar aquí que tratan sobre las cosas que intentamos hacer y los obstáculos que hemos superado en ese proceso. Creo que el grupo de trabajo es un gran lugar para intentar evaluar algunas de esas ideas y ver qué es realmente universal y reutilizable y qué realmente no lo es.

¿Puedes escribir lo que quieres hacer? Haz un documento de diseño. Haremos una revisión. Y el grupo de trabajo surgió de esto. Nos dimos cuenta de que algunas de esas cosas son bastante sencillas. Podríamos hacerlas todas de manera asíncrona. Podríamos comentar sobre tu diff. Pero tu diff comenzaba con un gran bloque en la parte superior que describía lo que ibas a hacer. Otras personas necesitaban mucha más retroalimentación.

Estableceríamos llamadas en vivo. De hecho, para algunos de esos, conduciríamos a donde fuera su oficina y hablaríamos con ellos en persona. Descubriríamos qué es lo que querían hacer. Estilo antiguo, entrar en una sala con una pizarra y un marcador y dibujar cosas hasta que todos estuviéramos seguros sobre qué problema estábamos resolviendo y por qué. Luego esto comenzó a escalar. Había muchas más personas que estaban contribuyendo. Había muchas más personas que estaban usando GraphQL y querían tener voz.

Querían asegurarse de que si un cambio significativo iba a suceder, pudieran aportar su opinión y asegurarse de que funcionara. El núcleo de nosotros trabajando en GraphQL, queríamos asegurarnos de que cualquier cambio que hiciéramos, tuviéramos confianza de que no solo funcionaría para nosotros en nuestra empresa, sino que también funcionaría para todos los demás en sus empresas. Comenzó a formalizarse más y más. Comenzó con una frecuencia un poco ad hoc. Lo haríamos cuando lo necesitáramos y creo que en algún momento tuvimos aproximadamente seis o siete de ellos al año. Decidimos fijarlos en el calendario y hacerlos cada mes.

Benji, ¿cómo terminaste uniéndote al Grupo de Trabajo? Sí, buena pregunta. Creo que estaba trabajando en un proyecto en ese momento, se llamaba Post-GraphQL. Solo era un colaborador, era un usuario de esa pieza de software y a medida que empecé a usarlo más, me involucré más en su mantenimiento, desde entonces he asumido el papel de mantenedor. Mientras trabajaba en eso, había cosas que había notado en GraphQL mismo, en la especificación, que sentía que podrían mejorarse y quería involucrarme. Y lo que realmente me gustó de el Grupo de Trabajo de GraphQL es lo accesible que era. Hay muy buenas pautas sobre cómo involucrarse, una de ellas es participar. Así que si vas a asistir al Grupo de Trabajo de GraphQL, planea realmente participar en la discusión. Una de las formas más fáciles de involucrarse, si realmente solo querías ser un observador, que es donde fui para obtener mi confianza inicial, era simplemente ayudar tomando notas. Así que eso es, creo, cómo empecé. Asistí, comencé a tomar notas y a medida que pasaba el tiempo, empecé a involucrarme más y más en las discusiones. Y ahora he tenido varias solicitudes de extracción fusionadas en la especificación de GraphQL. Tengo otras en las que estoy trabajando, y todavía estoy allí cada mes tomando notas también.

Sí, suena como, para mí, suena como un llamado a la comunidad para que alguien más, tal vez, al menos en algún momento, ayude a Benji y también tome algunas notas. Así que hay mucha ayuda que necesitamos. Tal vez lo primero en la lista sea alguien que se una y tome notas. Benji se subestima aquí. No solo es uno de los colaboradores más significativos de la especificación, el mayor valor que proporciona son las notas que básicamente co-dirige nuestras reuniones. Y eso no es para subestimar el valor de las contribuciones reales a la especificación que ha hecho. Sí, el proceso en sí funcionando sin problemas es súper importante. Definitivamente. Sasha, ¿cómo fue tu experiencia al unirte?

Sasha, ¿cómo fue tu experiencia al unirte? Sí. Creo que terminé uniéndome cuando estaba trabajando en Medium cuando comenzamos a movernos a GraphQL y simplemente quería aprender más. Y habíamos visto algunos problemas internos que eran como, tal vez podríamos resolver estos y comencé a involucrarme en el grupo de trabajo. Y sí, quiero decir, lo que todos están diciendo es cierto, es como, fue, ya sabes, la comunidad es súper increíble. Así que unirme al grupo de trabajo fue simplemente, ya sabes, todos son realmente amables y acogedores. Y fue realmente genial poder tener un espacio para aprender de la comunidad de GraphQL en general, como, ya sabes, y todas las pequeñas empresas de todos estaban haciendo sus propias cosas. Y es realmente agradable salir y ver, bueno, ¿qué están haciendo otras personas? O ¿qué están pensando otras personas? Así que fue realmente genial poder unirme y ver eso. Y lo otro genial fue que puedes, una, puedes simplemente redactar un RFC y ponerlo ahí y ver qué piensan las personas. Y muchas veces las personas también están pensando en lo mismo, no puedo contar la cantidad de veces que he visto un RFC y también estaba pensando en eso o hice uno y otras personas estaban como, Oh, sí, necesitamos resolver este problema. Así que es una manera realmente genial de compartir ideas y hacer que las cosas avancen y hacer cambios realmente interesantes. Sí, siento lo mismo. Siento que para mí, al principio, cuando recién comencé, sentí que había algunas personas en algún lugar tomando decisiones. Y como, no tengo voz y no me conocen y yo no los conozco y todo eso. Y luego, cuanto más me metí en esto, más me di cuenta de que está completamente abierto. Como, y cuanto más, como podrías unirte, todo está grabado. Podrías aprender. Y sobre todo, cuanto más compartes, como dijiste, cuanto más compartes tus opiniones o cuanto más compartes tus preguntas, te das cuenta no solo de que podrías, te das cuenta de que tu voz está siendo escuchada y realmente puedes afectar las cosas. Pero también puedes aprender un montón. Como principalmente, ya sabes, hay personas con tanta experiencia y, y las discusiones son tan profundas que es como, simplemente es asombroso y te enseña tanto. Me pregunto, no sé, ¿cuál crees que sería la primera cosa si alguien quiere involucrarse y quiere profundizar más en el tema, cuál sería el primer paso para que las personas se unan allí? Tomaré esa si te parece bien. Así que sí, a menudo trato de alentar a las personas a involucrarse en el Grupo de Trabajo de GraphQL. Así que a menudo las personas se involucran con, por ejemplo, los problemas de la especificación de GraphQL o solicitudes de extracción. Plantearán esta característica que les gustaría ver o este cambio que les gustaría ver. Y básicamente lo que aconsejo a todos, realmente, es que se agreguen a la próxima agenda. Tenemos archivos de agenda en el repositorio de GitHub del Grupo de Trabajo de GraphQL. Y todo lo que necesitas hacer es agregar tu nombre, tu organización a esa lista. Y también necesitarás aceptar los acuerdos que tenemos que son parte de la Fundación GraphQL. Pero son solo un par de A4, firmarlo, y ya está. Si estás bajo una organización como Twitter, por ejemplo, que ya tiene un acuerdo, entonces si eres uno de los empleados allí, simplemente te unes bajo eso.

Y así, sí, simplemente participar en el proyecto de otra persona es otra gran cosa que hacer. Sí. También agregaré que no creo que hayamos mencionado esto aún. Grabamos todos estos. Y así, como los artefactos que mostramos en un par de lugares. Uno, por supuesto, son las notas de alta calidad de Benji. Él no es el único que toma notas. Otras personas también toman notas. Pero esas son una gran manera de revisar lo que ha sucedido. Además, toda la reunión se publica en YouTube. Tenemos un canal de YouTube y es literalmente automatizado. Tan pronto como termina nuestra reunión, Zoom hace su trabajo en segundo plano y un par de horas después, aparece en YouTube. Así que, si alguna vez quieres tener una idea de cómo es esa reunión o hacer un seguimiento y ver lo que se discutió, absolutamente puedes hacerlo. Sabes, uno de nuestros principios es operar con tanta transparencia como sea posible. Esa es una de las razones por las que hacemos eso. Pero si hay algo donde realmente quieres involucrarte en la discusión, lo que Benji dijo es exactamente correcto. Todos son bienvenidos. Conozco a un puñado de personas que ven el repositorio del Grupo de Trabajo de GraphQL solo para que puedan ver, ya sabes, básicamente los cambios importantes que suceden allí, si alguien tiene una idea, aparece como un archivo, o si alguien quiere agregar algo a la Agenda, aparece como una solicitud de extracción y si observas ese repositorio, entonces simplemente obtienes una idea de lo que está sucediendo y puedes decir, eso me interesa, me gustaría unirme a este y participar en esa conversación. También agregaré que en el sitio web de GraphQL.org ahora, hay como una sección de comunidad completamente renovada que fue realizada por Brian de la Fundación y allí creo que puedes encontrar todos los enlaces de los que estamos hablando aquí, así que es como un buen lugar donde puedes ir y encontrar el canal de YouTube, sus repositorios de GitHub y todo.

y todo. Así que ese es un buen lugar para comenzar. Me pregunto, ¿cuál sería como lo más, como para las personas que ahora quieren unirse, o tal vez podemos escuchar de cada uno de ustedes, ¿cuáles son las cosas más emocionantes que están sucediendo ahora en la masterclass? Solo para dar una idea de lo que está sucediendo y para entusiasmar a la gente a unirse. Está bien, quiero ir primero, si está bien. Porque estoy muy emocionado por la nulabilidad controlada por el cliente. Eso es como lo más genial. Hay un montón de cosas geniales que están sucediendo, pero como más recientemente he estado muy emocionado por eso porque esta es una de esas cosas de las que estábamos hablando internamente en Twitter. Y como, siento que muchas otras empresas están como enfrentando esto, como muchos lugares están lo suficientemente avanzados donde estás en el punto en el que estás como, espera un segundo, esto se está volviendo un poco molesto porque, como tenemos el servidor enviando algo de vuelta. Y cuando estamos recibiendo estas respuestas que como, sabes, el cliente no sabe qué hacer con eso porque, como, en realidad, sí, sí quería esta cosa que era requerida para mí, o como esta cosa en realidad puede ser, no, no me importa. Y realmente encaja con la historia de GraphQL, que es que el cliente decide lo que necesita y lo que quiere y cómo lo hace. Así que la nulabilidad controlada por el cliente es como el ejemplo perfecto de esto y tener como un operador para hacer eso, tenerlo todo integrado en GraphQL, sería como lo más genial. Así que estoy muy emocionado por eso. Y creo que, honestamente, cambiaría como un montón de cosas en Twitter para hacerlo como mucho, mucho mejor porque ahora mismo estamos como enfrentando problemas con eso, donde es como, sabemos, el cliente realmente necesita poder controlar eso. Y como, no podemos hacer eso ahora mismo. Y en realidad es un poco molesto.

Benji, ¿hay algo que te interese mucho o que te emocione? Quiero decir, hay tantas cosas que están surgiendo que estoy bastante emocionado. Creo que mencionaré una que no creo que nadie más vaya a mencionar, que son los argumentos de fragmento de GraphQL. Creo que eso es particularmente interesante. Una de las cosas que realmente me encanta de GraphQL son los fragmentos en sí. Creo que realmente necesitas usar fragmentos bastante a menudo para hacer GraphQL, particularmente para React o aplicaciones del lado del cliente, para hacerlo de una manera agradable. Realmente quieres especificar qué requisitos de datos tiene un componente particular justo al lado de ese componente. Los fragmentos son una excelente manera de hacer eso. Pero en este momento, las variables que usarías en tu documento de GraphQL son un poco globales para el documento. Si quieres hacer referencia a una variable de tamaño de avatar, eso sería compartido por todo. No es local ya. Y una de las cosas interesantes es este concepto que creo que Matt Mahoney de Facebook es el campeón de esto, es básicamente dar a estos fragmentos la capacidad de agregar argumentos de la misma manera que tu operación de GraphQL en sí puede aceptar variables. Y luego, cuando uses los fragmentos, puedes especificar variables a ese nivel, ya sean constantes como tamaño de argumento 17, o si hacen referencia a una variable de un nivel superior o algo así. Y, obviamente, todavía está en discusión lo que realmente va a ser. Pero, sí, creo que eso es bastante emocionante y ayuda a que esta localidad sea aún más poderosa.

¿Hay otras cosas que quieran mencionar sobre cosas nuevas y geniales que están sucediendo? Sí. Quería dejar que un par de otras personas hablen y me alegra que Sasha haya intervenido con tanta pasión sobre la nulabilidad controlada por el cliente porque estoy muy emocionado por eso. Sabes, muchas de las cosas que más me emocionan son aquellas en las que hemos estado trabajando durante mucho, mucho, mucho tiempo. Y creo que esta es una de las cosas que a veces sorprende a la gente. A menudo tienen una impresión negativa al principio sobre lo lento que nos movemos, pero nos movemos lentamente a propósito. Nuestro objetivo aquí es terminar con una especificación de GraphQL y tecnología que perdure. Y así queremos tomar decisiones que sean las correctas. Y por eso estamos más dispuestos a tomar decisiones lentas que sean correctas, en lugar de decisiones rápidas que tengamos que cambiar mucho, porque entendemos que el cambio es muy doloroso con la tecnología que se utiliza tan ampliamente como GraphQL. Así que para la nulabilidad controlada por el cliente, tuve la primera conversación sobre esa idea en 2014 o 2015 con uno de los miembros del equipo de Relay en ese momento. Y en ese momento, era como, esta es una idea interesante, pero no, no tiene sentido. No lo vamos a hacer. Es antitético a algunos de los principios de nuestro servidor. Surgió un par de veces más a lo largo del curso del grupo de trabajo incluso, pero el enfoque nunca fue del todo correcto. Y creo que parte de por qué estoy tan emocionado por ello ahora es que han sucedido dos cosas. Una es que hemos llegado a un consenso de que este es un problema que vale la pena resolver con información muy clara sobre por qué, lo que nos ha ayudado dramáticamente a centrarnos en la forma correcta de resolverlo. Y esa es la segunda parte, que la propuesta real esta vez está convergiendo en algo que casi todos en estas reuniones están de acuerdo en que es la dirección correcta. Por supuesto, todavía hay preguntas sin respuesta, pero esa es parte de la razón por la que estoy tan emocionado por ello.

sería un descuido si no hablara sobre Defer y Stream. Creo que para las personas que han visto mis charlas durante un tiempo, tal vez recuerden que di una charla en una conferencia en 2016 o 2017 sobre Defer y Stream. Y incluso en ese momento, estábamos hablando de un experimento bastante bien elaborado que era interno a Facebook, que falló, por cierto, como, no funcionó. Lo retrocedimos y dimos esa charla. Creo que, Yuri, compartiste el escenario conmigo en esa charla en particular si recuerdo correctamente. Nuevamente, trabajamos en estas cosas durante mucho tiempo y queremos finalmente hacerlas bien. Y esa también surgió de una conversación con el equipo de Relay. Y ayer fue la React Conf. Y si alguien aquí sintonizó en eso, hubo un orador del equipo de Relay que habló un poco sobre una directiva que ellos usan que es esencialmente nulabilidad controlada por el cliente y una directiva que ellos usan, que es esencialmente Defer y Stream, y todas estas son formas de primer principio de construir clientes de alta calidad que se integran con React suspense. Y así, independientemente de si estás usando React o no, creo que debemos apreciar cuánto de innovación proviene de ese equipo de Relay, que muchas de las ideas que ellos intentan retroceden a la especificación para que cualquiera, independientemente de la plataforma, las use. Así que estoy emocionado por Defer y Stream debido a la nueva capacidad. Estoy emocionado por ello porque comenzamos a tener la conversación sobre esas cosas en 2016, y finalmente ahora están alcanzando la reificación, pero también tengo que dar un enorme, enorme reconocimiento a los campeones de estos esfuerzos. Y quiero resaltar Defer y Stream en particular porque las personas en First Dibs, que es una empresa que está patrocinando este trabajo, Rob en particular, Rob y Lilian en esa empresa han puesto una enorme cantidad de trabajo para resolver cada caso límite y esquina, sabes, empujando experimentos, empujando solicitudes de extracción a nuestras implementaciones de referencia, trabajando en textos de especificaciones durante literalmente más de un año. Y el patrocinio de ese trabajo es la razón por la que va a llegar a la especificación. Y así, tanto para esa empresa, por patrocinarlo, como para esos humanos por hacer el trabajo, tengo una enorme gratitud. Así que quería asegurarme de mencionar eso.

Creo que es realmente interesante, ¿verdad? Porque cuando tomas algo como GraphQL, que es como ayuda a muchos de nosotros a hacer las cosas que queremos hacer en todos nuestros entornos de trabajo y los flujos a través de los cuales trabajamos y todo lo que estamos haciendo. Y sabes, a menudo encontramos cosas locales que nos molestan de vez en cuando. Como mencioné antes, que son específicas de las empresas y los problemas en los que estamos trabajando.

Pero el grupo de trabajo realmente nos permite unirnos y tener este tipo general de esto funciona, esto no, y solo un poco más de un ajuste aquí nos llevará al modo correcto. Y creo que, como dijiste, a veces las personas proporcionan, sabes, mencionan el tema de algo que necesita ser arreglado, pero no está del todo bien todavía. Y una vez que esas cosas finalmente comienzan a converger, pero han sido discutidas mucho y una y otra vez e incluso prototipadas en diferentes plataformas para diferentes necesidades, comenzamos a ver cómo todos pueden beneficiarse de ello y podemos centrarnos en esa realmente, realmente buena solución para todo lo que queremos. Y creo que este tipo de cosa, como si todos quisieran pasar a GraphQL y simplemente modificarlo para sus propios propósitos, causaría muy rápidamente problemas entre todos. Así que tenemos que tener cuidado, creo, a largo plazo sobre cómo estos cambios afectan a las personas y qué les hace a todos esos, sabes, cientos de miles o millones de implementaciones que la gente ha puesto juntas? Y no romper todas esas cosas hacia atrás. Y si vamos a romper algo, seamos muy, muy claros y asegurémonos de saber qué va a hacer eso a todos los que están ahí afuera.

Sí, estoy de acuerdo. Quiero decir, para mí, personalmente, siento que comenzar a unirme y estar expuesto a esto, al grupo de trabajo, básicamente me elevó un nivel en términos de cómo me veo a mí mismo realmente como desarrollador o como ingeniero. Sé que va a ser una gran frase o algo así, pero para mí, al observar cómo evoluciona el grupo de trabajo, GraphQL me enseñó mucho sobre cómo hacer cambios en general, porque hay una gran comunidad. Hay un gran esfuerzo. Hay tantas personas involucradas en ello. Tantas opiniones, tantas implementaciones, tantos incentivos diferentes y cosas así, y de alguna manera el grupo de trabajo es capaz de encontrar el equilibrio correcto. Y creo que cuanto más me involucro, más me impresiona lo bien que se gestiona y cuántas oportunidades ha tenido para básicamente... Tuvimos que arruinar esta cosa, y no es... Y es realmente, realmente impresionante. Así que solo, creo que, para mí personalmente, solo ser una mosca en la pared fue realmente una experiencia asombrosa, y todavía hoy creo que es muy, muy interesante. No solo cómo hacer cambios en GraphQL, sino también cómo opera el grupo de trabajo en sí. Creo que está cambiando constantemente y mejorando. Creo que es un esfuerzo grupal y comunitario increíble que se está liderando de una manera muy buena.

Así que sí, gracias a todos los que están involucrados en ello y realmente haciendo que sea así. Creo que no es obvio que sea así. Tengo otra pregunta tal vez extraña. O tal vez como una pregunta de nicho, pero, sabes, también está la Fundación GraphQL. ¿Cómo están, están esos dos relacionados? Como está el grupo de trabajo de GraphQL, está el comité directivo de GraphQL, y está la Fundación GraphQL. ¿Cómo, cómo están relacionados entre sí? Sí. Cubriré esto porque hay algunas matices aquí. Y de hecho creo que esta es una pregunta realmente importante porque la idea errónea más común que recibo es que solo puedes contribuir a GraphQL. Solo puedes presentarte a una de estas reuniones.

Se utilizan de maneras bastante diferentes, y especialmente GraphQL siendo una especificación que se implementa en muchos lenguajes diferentes es algo significativamente diferente que requiere un modelo operativo diferente, y de hecho requiere un modelo de propiedad intelectual diferente, como una manera diferente de proteger las ideas mismas. También hay muchas de las ideas para la fundación que nacieron de la controversia. El marco de código abierto temprano de Facebook fue, creo, novedoso pero no bien recibido. Y así como la licencia para las cosas cambió. De hecho, tengo una patente de algunas de las ideas fundamentales de GraphQL que escribí mucho antes de que pensáramos que sería un proyecto de código abierto. Y, por supuesto, hemos ofrecido una licencia gratuita a todos los que lo usan.

Pero también hemos mirado la historia de cómo han funcionado proyectos similares. Y sé que muchos de los que están viendo esto usan y aman Node, regresen y miren IOJS, y sumérjanse en el dolor que ocurrió en esa comunidad a través de eso. Creo que la salud de la comunidad GraphQL no es una conclusión natural. Se requiere mucho trabajo para asegurarse de que esta comunidad se mantenga bien alineada. Y hay muchos ejemplos en contra. Así que tenía muchas de estas cosas en mente cuando establecí la fundación.

Y la fundación hace un par de cosas realmente importantes también de las que hablar. Una es que en realidad nos da un marco legal para todo esto. Vengo de, sabes, estaba construyendo software. No soy abogado. Así que tuve que sentarme en esto mucho más de lo que alguna vez me gustaría. Pero ahora sé mucho más sobre la ley de código abierto de lo que sabía antes. Y ahora tenemos una fundación muy sólida que está basada en precedentes de muchos otros proyectos importantes. Construí esta cosa en asociación con la Fundación Linux. Ellos saben lo que hacen. No solo tomamos cosas de proyectos anteriores. Usamos sus lecciones aprendidas. Tengo un gerente de programa, Brian, con el que trabajamos muy de cerca. Él ha ayudado a gestionar muchos proyectos super importantes, incluida la Fundación OpenJS y ha aportado toda su experiencia para ayudarnos a establecer una fundación muy sólida para asegurarnos de que todos los que contribuyen lo hagan de buena fe y todo lo que hacen sea luego compartible con cualquier empresa que quiera usarlo. Eso es realmente importante hacerlo bien. Luego está el lado de la financiación. Puede que no pienses demasiado en esto. Y, por supuesto, muchos de los que están aquí son voluntarios, y eso es genial. Pero se requiere mucho para mantener las cosas funcionando bien.

Las empresas se unen a la fundación y contribuyen financieramente a eso. Tenemos una junta de la fundación. Ellos dirigen a dónde van esas finanzas. Y de hecho, una de las maneras más importantes en que usamos ese fondo de finanzas es un programa de subvenciones. De hecho, lanzamos este programa de subvenciones hace muy poco, hace un par de semanas. Puedes encontrarlo en GraphGo.org slash community dash grant, creo. Hay un enlace en la parte inferior del sitio web en el pie de página, donde otorgamos subvenciones bastante significativas a personas en la comunidad que están haciendo un trabajo importante enfocado en la comunidad. Así que esa es la Fundación GraphGo. Es algo basado en miembros. Los miembros pagan para ser parte de eso, y al hacerlo, obtienen el control sobre cómo se gasta ese presupuesto agrupado.

En paralelo a eso está el proyecto técnico de GraphQL. El proyecto técnico de GraphQL es la especificación en sí, la implementación de referencia, la herramienta gráfica y un puñado de otras cosas. La fundación tiene un marco que crea la estructura legal para esas cosas. Ellos poseen la propiedad intelectual de esas cosas, pero la junta de esa fundación GraphQL no tiene la capacidad de tomar decisiones técnicas. Ellos delegaron formalmente todas las decisiones técnicas al comité directivo técnico, que es este excelente grupo de personas que ven aquí. Somos nosotros quienes tomamos decisiones técnicas. Esa es una separación realmente importante entre estos dos para asegurarnos de que el conjunto de empresas que pueden tener intereses comerciales en vender GraphQL de una manera particular no tengan realmente la capacidad de hacerlo. Tal vez haya alguien que trabaja en una de esas empresas que esté en el comité directivo, pero tienden a ser miembros bien razonados. El comité directivo técnico es en realidad un asunto votado por la comunidad. La fundación ni siquiera puede elegir quién es ese comité directivo técnico.

Nosotros podemos auto seleccionar. Eso es realmente importante para hacer eso. El comité directivo técnico, este grupo de personas, es esencialmente el subconjunto de las personas que asisten a estas reuniones del grupo de trabajo que tienen control de voto explícito. Si alguna vez hay un caso en el que necesitamos tomar una decisión firme y queremos tener un voto contado, eso es realmente lo primero y más importante por lo que el comité directivo técnico es responsable. Lo otro es que somos los animadores o los campeones del grupo. Si algo importante necesita suceder, hay como, ¿quién lo va a hacer? Tiende a recaer en uno de los miembros del comité directivo. Luego está el grupo de trabajo. Hemos pasado mucho tiempo hablando sobre eso. Es una invitación abierta. Cualquiera puede venir, cualquiera en la comunidad que tenga una idea. El comité directivo técnico es el patrocinador y campeón de esa reunión. Ellos ayudan a operarla. Benji y yo en particular tendemos a co-dirigir esas reuniones, pero tendemos a delegar partes y piezas de eso a este grupo en su conjunto. Espero que eso le dé a la gente una mejor comprensión de los detalles del mundo, la mitad financiera y la mitad técnica.

Sí, exactamente. Creo que tu explicación ahora solo probó mi otro punto, que es cuánto pensamiento se está poniendo en crear una comunidad abierta que se mantenga abierta y siga progresando. Así que gracias tanto por crear todo esto. ¿Algo que alguno de ustedes quiera decir justo antes de que nos vayamos? No tenemos mucho tiempo para continuar esta discusión. ¿Alguna última palabra que piensen que es importante para que la gente escuche sobre el grupo de trabajo en general? Solo quiero decir un enorme gracias a todos los que están involucrados en los Working Groups. Como dice Lee, hay mucho de lo que es, tiempo de voluntariado que se dedica a avanzar en estas cosas y no es solo el caso de levantar una solicitud de extracción y esperar que se fusione. Se trata de tener en cuenta toda la retroalimentación de varias otras personas en eso y también me gusta mucho que no nos aferramos realmente a nuestras ideas iniciales. Como que tomamos en cuenta esa retroalimentación y avanza y creo que eso es realmente genial, pero requiere mucho esfuerzo. Así que gracias, un enorme gracias a todos los involucrados. Gracias y gracias a todos aquí en la discusión final. Gracias por participar y gracias por su trabajo general en el Working Group. Es simplemente, uh, es asombroso. Así que muchas gracias por unirse a mí y gracias a todos los que se unieron en línea y espero verlos a todos o al menos a algunos de ustedes en los próximos Working Groups. Muchas gracias. Y en el chat.

Creo que decidimos comenzar a hacer las reuniones mensuales hace tres años y medio o cuatro. En este punto ahora, es una reunión saludable y de larga duración con un puñado de caras muy familiares, pero con una rotación constante de personajes de personas que tienen algo interesante en lo que están trabajando. Lo traen para jugar con nosotros.

Gracias. Esto es realmente interesante y estoy muy probablemente también me uniré a algunas de esas reuniones. Me encantaría escuchar a otros. ¿Cuál fue tu experiencia cuando te uniste y qué obtuviste de ello? Brielle, tal vez puedas compartir la tuya.

Claro, solo estoy verificando si estoy en silencio. Es interesante. Tengo una opinión dividida sobre esto, habiendo trabajado en Facebook antes de que se abriera y luego tratando de implementarlo en una empresa después de que lo fue. Una de las cosas grandes aquí, creo, que es realmente importante es que cuando trabajas en algunas de estas empresas que adoptan, la gente siempre está tratando de integrar GraphQL en la infraestructura de su empresa. Tienen muchas ideas y opiniones diferentes sobre esto, especialmente si estaban muy centrados en REST o en cualquiera de los otros tipos de cosas que podrían haber sucedido allí. Cuando lo llevamos por primera vez a PayPal, hubo mucha discusión sobre, como, siempre manejamos errores de una cierta manera, pero GraphQL lo hace diferente. ¿Cómo deberíamos hacer que eso funcione? Hubo muchas discusiones muy acaloradas sobre cómo deberíamos implementar las cosas.

Una de las cosas que tuvimos que hacer allí es que casi tuvimos que formar un comité dentro de la empresa para tener, básicamente, algún tipo de cordura, porque había demasiadas personas de todos lados haciendo que esto avanzara, y todos querían resolverlo para su espacio local. La masterclass es realmente buena, porque cuando tienes esto, puedes entrar y proponer lo que funciona realmente bien para ti, para tu propia empresa, y tratar de llevar esas ideas adelante. Inevitablemente, casi siempre descubres que lo que funciona bien para ti no siempre funciona bien para los demás, y por eso ese tipo de grupo es realmente importante tenerlo.

Creo que hay muchas historias anecdóticas de las que no tenemos tiempo para hablar aquí que tratan sobre las cosas que intentamos hacer y los obstáculos que hemos superado en ese proceso. Creo que la masterclass es un gran lugar para intentar evaluar algunas de esas ideas y ver qué es realmente universal y reutilizable y qué realmente no lo es.

Benji, ¿cómo terminaste uniéndote a la masterclass? Sí, buena pregunta. Creo que estaba trabajando en un proyecto en ese momento, se llamaba Post-GraphQL. Solo era un colaborador, era un usuario de esa pieza de software y a medida que empecé a usarlo más, me involucré más en su mantenimiento, desde entonces he asumido el papel de mantenedor. Mientras trabajaba en eso, había cosas que había notado en GraphQL mismo, en la especificación, que sentía que podrían mejorarse y quería involucrarme. Y lo que realmente me gustó de la GraphQL Working Group es lo accesible que era.

Hay muy buenas directrices sobre cómo participar, una de ellas es participar. Así que si vas a asistir al GraphQL Working Group, planea realmente involucrarte en la discusión. Una de las maneras más fáciles de involucrarte si realmente solo querías ser un observador, que es donde fui a obtener mi confianza inicial, por así decirlo, fue simplemente ayudar tomando notas. Así que eso es, creo, cómo comencé. Asistí, comencé a tomar notas y a medida que pasaba el tiempo, empecé a involucrarme más y más en las discusiones. Y ahora he tenido varias solicitudes de extracción fusionadas en la especificación de GraphQL. Tengo otras en las que estoy trabajando, y todavía estoy allí cada mes tomando las notas también.

Sí, suena como, para mí, suena como un llamado a la comunidad para que alguien más, tal vez, al menos en algún momento, ayude a Benji y también tome algunas notas. Así que hay mucha ayuda que necesitamos. Tal vez lo primero en la lista sea alguien que se una y tome notas. Benji se subestima aquí. No solo es uno de los colaboradores más significativos de la especificación, el mayor valor que proporciona son las notas que básicamente co-dirige nuestras reuniones. Y eso no es para subestimar el valor de las contribuciones reales a la especificación que ha hecho.

Sí, el proceso en sí funcionando sin problemas es súper importante. Definitivamente. Sasha, ¿cómo fue tu experiencia al unirte? Sí. Creo que terminé uniéndome cuando estaba de vuelta trabajando en Medium cuando comenzamos a movernos a GraphQL y simplemente quería aprender más. Y habíamos visto algunos problemas internos que eran como, tal vez podríamos resolver estos y comencé a involucrarme en el grupo de trabajo. Y sí, quiero decir, lo que todos están diciendo es cierto, es como, era, era, ya sabes, la comunidad es súper increíble. Así que unirse al grupo de trabajo fue simplemente, ya sabes, todos son realmente amables y acogedores. Y fue realmente genial poder tener un espacio para aprender de la comunidad de GraphQL en general, como, ya sabes, y las pequeñas empresas de todos estaban haciendo sus propias cosas. Y es realmente agradable salir y ver, bueno, ¿qué están haciendo otras personas? O ¿qué están pensando otras personas? Así que fue realmente genial poder unirme y ver eso. Y lo otro genial fue que puedes, uno, puedes simplemente redactar un RFC y publicarlo y ver qué piensa la gente. Y muchas veces la gente también está pensando en lo mismo, no puedo contar la cantidad de veces que he visto un RFC y también estaba pensando en eso o hice uno y otras personas dijeron, Oh, sí, necesitamos como resolver este problema. Así que es una manera realmente genial de compartir ideas y hacer que las cosas avancen y hacer cambios realmente geniales. Sí, siento lo mismo. Siento que para mí, al principio, cuando solo comencé, sentí que había algunas, como algunas personas en algún lugar tomando decisiones. Y como, no tengo, no tengo voz y no me conocen y yo no los conozco y todo eso.

Y luego, cuanto más me metí en esto, más me di cuenta de que está completamente abierto. Como, y cuanto más, como podrías unirte, todo está grabado. Podrías aprender. Y sobre todo, cuanto más compartes, como dijiste, cuanto más compartes tus opiniones o cuanto más compartes tus preguntas, te das cuenta no solo de que podrías, te das cuenta de que tu voz está siendo escuchada y realmente puedes afectar las cosas. Pero también puedes aprender un montón. Como principalmente, ya sabes, hay personas con tanta experiencia y, y las discusiones son tan profundas que es como, simplemente es asombroso y te enseña tanto. Me pregunto, no sé, ¿cuál crees que sería la primera cosa si alguien quiere involucrarse y quiere profundizar más en el tema, cuál sería el primer paso para que las personas se unan allí? Tomaré esa si te parece bien. Así que sí, a menudo trato de alentar a las personas a involucrarse en el Grupo de Trabajo de GraphQL. Así que a menudo las personas se involucran con, por ejemplo, los problemas de la especificación de GraphQL o solicitudes de extracción. Plantearán esta característica que les gustaría ver o este cambio que les gustaría ver. Y básicamente lo que aconsejo a todos, realmente, es que se agreguen a la próxima agenda. Tenemos archivos de agenda en el repositorio de GitHub del Grupo de Trabajo de GraphQL. Y todo lo que necesitas hacer es solo agregar tu nombre, tu organización a esa lista. Y también necesitarás aceptar los acuerdos que tenemos que son parte de la Fundación GraphQL. Pero son solo un par de A4, firmarlo, y ya está. Si estás bajo una organización como Twitter, por ejemplo, que ya tiene un acuerdo, entonces si eres uno de los empleados allí, simplemente te unes bajo eso. Así que, es bastante fácil si eres parte de una de esas organizaciones. Pero incluso como un contribuyente individual, como yo, es muy fácil hacerlo. El bot verifica por ti para asegurarse de que se haya hecho, te da una marca verde cuando está hecho, y luego eso es todo. Puedes asistir. Y luego simplemente apareces y te involucras. Creo que es bueno tener una idea de en qué quieres estar involucrado en discutir. Así que, tal vez tengas tu propio tema. Pero a veces hay algo que se va a discutir como la nulabilidad controlada por el cliente o algo así, y piensas, oh, esto es relevante para mi caso de uso y quiero asegurarme de que esto se implemente de una manera que funcione para mí y para mi proyecto. Y así, sí, simplemente aparecer para estar involucrado en el proyecto de otra persona es otra gran cosa que hacer. Sí. También agregaré que no creo que hayamos mencionado esto aún. Grabamos todos estos. Y así, como los artefactos que mostramos aparecen en un par de lugares. Uno, por supuesto, las notas de alta calidad de Benji.

Él no es el único que toma notas. Otras personas también toman notas. Pero esas son una gran manera de revisar lo que ha sucedido. Además, toda la reunión se publica en YouTube. Tenemos un canal de YouTube y está literalmente automatizado. Tan pronto como termina nuestra reunión, Zoom hace su trabajo en segundo plano y un par de horas después, aparece en YouTube. Así que, si alguna vez quieres tener una idea de cómo es esa reunión o hacer un seguimiento y ver lo que se discutió, absolutamente puedes hacerlo. Sabes, uno de nuestros principios es operar con tanta transparencia como sea posible. Esa es una de las razones por las que hacemos eso.

Pero si hay algo donde realmente quieres involucrarte en la discusión, lo que Benji dijo es exactamente correcto. Todos son bienvenidos. Conozco a un puñado de personas que ven el repositorio del Grupo de Trabajo de GraphQL solo para que puedan ver, ya sabes, básicamente los cambios importantes que suceden allí, si alguien tiene una idea, aparece como un archivo, o si alguien quiere agregar algo a la Agenda, aparece como una solicitud de extracción y si observas ese repositorio, entonces simplemente obtienes una idea de lo que está sucediendo y puedes decir, eso me interesa, me gustaría unirme a este y participar en esa conversación. También agregaré que en el sitio web de GraphQL.org ahora, hay como una sección de comunidad completamente renovada que fue realizada por Brian de la Fundación y allí creo que puedes encontrar todos los enlaces de los que estamos hablando aquí, así que es como un buen lugar donde puedes ir y encontrar el canal de YouTube, sus repositorios de GitHub y todo. Así que ese es un buen lugar para comenzar.

Me pregunto, ¿cuál sería como lo más, como para las personas que ahora quieren unirse, o tal vez podemos escuchar de cada uno de ustedes, ¿cuáles son las cosas más emocionantes que están sucediendo ahora en el grupo de trabajo? Solo para dar una idea de lo que está sucediendo, y para entusiasmar a la gente a unirse. Está bien, quiero ir primero, si está bien. Porque estoy súper emocionado por la nulabilidad controlada por el cliente. Eso es como lo más genial. Hay un montón de cosas geniales que están sucediendo, pero como más recientemente he estado como súper emocionado por eso porque esta es una de esas cosas que estábamos hablando internamente en Twitter. Y como, siento que muchas otras empresas están como enfrentando esto, como muchos lugares están lo suficientemente avanzados donde estás en el punto en el que estás como, espera un segundo, esto se está volviendo un poco molesto porque, como tenemos el servidor enviando algo de vuelta. Y cuando estamos recibiendo estas respuestas que como, sabes, el cliente no sabe qué hacer con eso porque como, en realidad, sí, sí quería esta cosa que era requerida para mí, o como esta cosa en realidad puede ser, no, no me importa. Y realmente encaja con la historia de GraphQL, que es que el cliente decide lo que necesita y lo que quiere y cómo lo hace. Así que la nulabilidad controlada por el cliente es como el ejemplo perfecto de esto y tener como un operador para hacer eso, tenerlo todo integrado en GraphQL, sería como lo más genial. Así que estoy súper emocionado por eso. Y creo que, honestamente, cambiaría como un montón de cosas en Twitter para hacerlo como mucho, mucho mejor porque ahora mismo estamos como enfrentando problemas con eso, donde es como, sabemos, el cliente realmente necesita poder controlar eso. Y como, no podemos hacer eso ahora mismo. Y en realidad es un poco molesto. Así que estoy súper emocionado por ello.

Creo que eso es como lo más genial. Benji, ¿hay algo que te interese mucho o que te emocione? Quiero decir, hay tantas cosas que están surgiendo que estoy bastante emocionado. Creo que mencionaré una que no creo que nadie más vaya a mencionar, que son los argumentos de fragmento de GraphQL. Creo que eso es particularmente interesante. Una de las cosas que realmente me encanta de GraphQL son los fragmentos en sí. Creo que realmente necesitas usar fragmentos bastante a menudo para hacer GraphQL, particularmente para React o aplicaciones del lado del cliente, para hacerlo de una manera agradable. Realmente quieres especificar qué requisitos de datos tiene un componente particular justo al lado de ese componente. Los fragmentos son una gran manera de hacer eso. Pero en este momento, las variables que usarías en tu documento de GraphQL son como globales para el documento. Si quieres hacer referencia a una variable de tamaño de avatar, eso sería compartido por todo. No es local ya. Y una de las cosas interesantes es este concepto que creo que Matt Mahoney de Facebook es el campeón de esto, es básicamente dar a estos fragmentos la capacidad de agregar argumentos de la misma manera que tu operación de GraphQL en sí puede aceptar variables. Y luego cuando tú usas los fragmentos, puedes especificar variables a ese nivel, ya sean constantes como tamaño de argumento 17, o si hacen referencia a una variable de un nivel superior o algo así. Y obviamente todavía está bajo discusión lo que realmente va a ser.

Y, obviamente, todavía está en discusión lo que realmente va a ser. Pero, sí, creo que eso es bastante emocionante y ayuda a que esta localidad sea aún más poderosa. ¿Hay otras cosas que quieran mencionar, alguien quiere mencionar sobre cosas nuevas y geniales que están sucediendo? Sí. Quería dejar que un par de otras personas hablen y me alegra que Sasha haya intervenido con tanta pasión sobre la nulabilidad controlada por el cliente porque estoy muy emocionado por eso. Sabes, muchas de las cosas que más me emocionan son aquellas en las que hemos estado trabajando durante mucho, mucho, mucho tiempo. Y creo que esto es una de las cosas que a veces sorprende a la gente.

A menudo tienen una impresión negativa al principio sobre lo lento que nos movemos, pero nos movemos lento a propósito. Nuestro objetivo aquí es terminar con una especificación de GraphQL y tecnología que perdure. Y así queremos tomar decisiones que sean las correctas. Y por eso estamos más dispuestos a tomar decisiones lentas que sean correctas, en lugar de decisiones rápidas que tengamos que cambiar mucho, porque entendemos que el cambio es muy doloroso con la tecnología que se utiliza tan ampliamente como GraphQL. Así que para la nulabilidad controlada por el cliente, tuve la primera conversación sobre esa idea en tal vez 2014 o 2015 con uno de los miembros del equipo de Relay en ese momento. Y en ese momento, era como, esta es una idea interesante, pero no, no tiene sentido. No lo vamos a hacer. Es antitético a algunos de los principios de nuestro servidor.

Surgió un par de veces más a lo largo del curso del grupo de trabajo incluso, pero el enfoque nunca fue del todo correcto. Y creo que parte de por qué estoy tan emocionado por ello ahora es que han sucedido dos cosas. Una es que hemos llegado a un consenso de que este es un problema que vale la pena resolver con información muy clara sobre por qué, lo que nos ha ayudado dramáticamente a centrarnos en la manera correcta de resolverlo. Y esa es la segunda parte, que la propuesta real esta vez está convergiendo en algo que casi todos en estas reuniones están de acuerdo en que es la dirección correcta. Aún hay preguntas sin respuesta, por supuesto, pero esa es parte de la razón por la que estoy tan emocionado por ello. Además, sería negligente si no hablara sobre Defer y Stream.

Y incluso en ese momento, estábamos hablando de un experimento bastante bien elaborado que era interno a Facebook, que falló, por cierto, como, no funcionó. Lo retrocedimos y dimos esa charla. Creo que, Yuri, compartiste el escenario conmigo en esa charla en particular si recuerdo correctamente. Nuevamente, trabajamos en estas cosas durante mucho tiempo y queremos finalmente hacerlas bien. Y eso también surgió de una conversación con el equipo de Relay. Y ayer fue la React Conf. Y si alguien aquí sintonizó en eso, hubo un orador del equipo de Relay que habló un poco sobre una directiva que ellos usan que es esencialmente nulabilidad controlada por el cliente y una directiva que ellos usan, que es esencialmente Defer y Stream, y todas estas son como formas de primer principio en las que construyes clientes de alta calidad que integras con React suspense. Y así, independientemente de si estás usando React o no, creo que debemos apreciar cuánto de innovación proviene de ese equipo de Relay, que muchas de las ideas que ellos intentan retroceden a la especificación para que cualquiera, independientemente de la plataforma, las use.

Así que estoy emocionado por Defer y Stream debido a la nueva capacidad. Estoy emocionado por ello porque comenzamos a tener la conversación sobre esas cosas en 2016, y finalmente ahora están alcanzando la reificación, pero también tengo que dar un enorme, enorme reconocimiento a los campeones de estos esfuerzos. Y quiero resaltar Defer y Stream en particular porque las personas en First Dibs, que es una empresa que está patrocinando este trabajo, Rob en particular, Rob y Lilian en esa empresa han puesto una enorme cantidad de trabajo para trabajar en cada caso límite y esquina, sabes, empujando experimentos, empujando solicitudes de extracción en nuestras implementaciones de referencia, trabajando en textos de especificaciones durante literalmente más de un año. Y el patrocinio de ese trabajo es la razón por la cual va a hacer su camino en la especificación. Y así, tanto para esa empresa, por patrocinarlo, como para esos humanos por hacer el trabajo, tengo una enorme gratitud.

Así que quería asegurarme de mencionar eso. Creo que es realmente interesante, ¿verdad? Porque cuando tomas algo como GraphQL, que es como ayuda a muchos de nosotros a hacer las cosas que queremos hacer en todos nuestros entornos de trabajo y los flujos que trabajamos y todo lo que estamos haciendo. Y sabes, a menudo encontramos cosas locales que nos molestan de vez en cuando. Como mencioné antes, que son específicas de las empresas y los problemas en los que estamos trabajando. Pero el grupo de trabajo realmente nos permite unirnos y tener este tipo general de esto funciona, esto no, y solo un poco más de un ajuste aquí nos llevará al modo correcto. Y creo que, como dijiste, a veces las personas proporcionan, sabes, mencionan el tema de algo que necesita ser arreglado, pero no está del todo bien todavía.

Y una vez que esas cosas finalmente comienzan a converger, pero han sido discutidas mucho y una y otra vez e incluso prototipadas en diferentes plataformas para diferentes necesidades, comenzamos a ver cómo todos pueden beneficiarse de ello y podemos centrarnos en esa realmente, realmente buena solución para todo lo que queremos. Y creo que este tipo de cosa, como si todos quisieran pasar a GraphQL y simplemente modificarlo para sus propios propósitos, causaría muy rápidamente problemas entre todos. Así que tenemos que tener cuidado, creo, a largo plazo sobre cómo estos cambios afectan a las personas y qué les hace a todos esos, sabes, cientos de miles o millones de implementaciones que las personas han puesto juntas. ¿Y no rompemos todas esas cosas hacia atrás? Y si vamos a romper algo, seamos muy, muy claros y asegurémonos de saber qué va a hacer eso a todos los que están ahí afuera.

Sí, estoy de acuerdo. Quiero decir, para mí, personalmente, siento que comenzar a unirme y estar expuesto a esto, al grupo de trabajo, básicamente me elevó un nivel en términos de cómo me veo a mí mismo realmente como desarrollador o como ingeniero. Sé que va a ser una gran frase o algo así, pero para mí, al mirar cómo evoluciona el grupo de trabajo, GraphQL me enseñó mucho sobre cómo hacer cambios, porque hay una gran comunidad. Hay un gran esfuerzo. Hay tantas personas involucradas en ello. Tantas opiniones, tantas implementaciones, tantos incentivos diferentes y cosas así, y de alguna manera el grupo de trabajo es capaz de encontrar el equilibrio correcto. Y creo que cuanto más me involucro, más me impresiona lo bien que se gestiona y cuántas oportunidades tuvo para básicamente... Tuvimos que arruinar esto, y no es... Y es realmente, realmente impresionante. Así que solo, creo que, para mí personalmente, solo ser una mosca en la pared fue realmente una experiencia increíble, y todavía hoy creo que es muy, muy interesante.

No solo cómo hacer cambios en GraphQL, sino también cómo opera el grupo de trabajo en sí. Creo que está cambiando constantemente y mejorando. Creo que es un esfuerzo grupal y comunitario increíble que se está liderando de una manera muy bien. Así que sí, gracias a todos los que están involucrados en ello y realmente están haciendo que sea así. Creo que no es obvio que sea así. Tengo otra pregunta tal vez extraña. Yo o tal vez como una pregunta de nicho, pero, sabes, también está la fundación GraphQL. ¿Cómo están, están relacionados esos dos? Como está el grupo de trabajo de GraphQL, está el comité directivo de GraphQL, y está la fundación GraphQL. ¿Cómo, cómo están relacionados entre sí? Sí. Cubriré esto porque hay algo de matiz aquí. Y de hecho creo que esta es una pregunta realmente importante porque la idea errónea más común que recibo es que solo puedes contribuir a GraphQL. Solo puedes presentarte a una de estas reuniones. Si eres un miembro de la fundación o viceversa, que como presentarte a estas reuniones de alguna manera te convierte en parte de la fundación. Estas son en realidad como dos cosas paralelas. Así que la fundación GraphQL se formó a principios de 2019, y hasta ese momento, GraphQL era un proyecto de código abierto patrocinado por Facebook de manera similar a como React lo es todavía hoy. Y creo que hay diferentes restricciones en estos proyectos. Se utilizan de maneras bastante diferentes, y especialmente GraphQL siendo una especificación que se implementa en muchos lenguajes diferentes es algo significativamente diferente que requiere un modelo operativo diferente, y de hecho requiere un modelo de propiedad intelectual diferente, como una forma diferente de proteger las ideas mismas.

También hay muchas de las ideas para la fundación que nacieron de la controversia. El marco de código abierto temprano de Facebook fue, creo, novedoso pero no bien recibido. Y así como la licencia para las cosas cambió. De hecho, tengo una patente sobre algunas de las ideas fundamentales de GraphQL que escribí mucho antes de que pensáramos que sería un proyecto de código abierto. Y, por supuesto, hemos ofrecido una licencia gratuita a todos los que lo usan. Pero también hemos mirado la historia de cómo han funcionado proyectos similares.

Y sé que muchos de los que están viendo esto usan y aman Node, regresen y miren IOJS, y sumérjanse en el dolor que ocurrió en esa comunidad a través de eso. Creo que la salud de la comunidad GraphQL no es una conclusión natural. Mucho trabajo se dedica a asegurarse de que esta comunidad se mantenga bien alineada. Y hay muchos ejemplos en contra. Así que tenía muchas de estas cosas en mente cuando establecí la fundación.

Y la fundación hace un par de cosas realmente importantes también de las que hablar. Una es que en realidad nos da un marco legal para todo esto. Vengo de, sabes, estaba construyendo software. No soy abogado. Así que tuve que sentarme en esto mucho más de lo que alguna vez me gustaría. Pero ahora sé mucho más sobre la ley de código abierto de lo que sabía antes. Y ahora tenemos una base muy sólida que está basada en precedentes de muchos otros proyectos importantes. Construí esta cosa en asociación con la Fundación Linux. Ellos saben lo que hacen.

No solo tomamos cosas de proyectos anteriores. Usamos sus lecciones aprendidas. Tengo un gerente de programa, Brian, con el que trabajamos muy de cerca. Él ha ayudado a gestionar muchos proyectos super importantes, incluida la OpenJS Foundation y ha aportado toda su experiencia para ayudarnos a establecer una base muy sólida para asegurarnos de que todos los que contribuyen lo hagan de buena fe y todo lo que hacen sea luego compartible con cualquier empresa que quiera usarlo. Eso es realmente importante hacerlo bien.

Luego está el lado de la financiación. Puede que no pienses demasiado en esto. Y, por supuesto, muchos de los que están aquí son voluntarios, y eso es genial. Pero se requiere mucho para mantener las cosas funcionando bien. La fundación GraphGo se forma en realidad a partir de un grupo de empresas. Las empresas se unen a la fundación y contribuyen financieramente a eso. Tenemos una junta de la fundación. Ellos dirigen a dónde van esas finanzas.

Y, de hecho, una de las maneras más importantes en que usamos ese fondo de finanzas es un programa de subvenciones. De hecho, lanzamos este programa de subvenciones hace muy poco, hace un par de semanas. Puedes encontrarlo en GraphGo.org slash community dash grant, creo. Hay un enlace en la parte inferior del sitio web en el pie de página, donde otorgamos subvenciones bastante significativas a personas en la comunidad que están haciendo un trabajo importante enfocado en la comunidad. Así que esa es la fundación GraphGo. Es algo basado en miembros. Los miembros pagan para ser parte de eso, y al hacerlo, obtienen el control sobre cómo se gasta ese presupuesto agrupado.

En paralelo a eso está el proyecto técnico de GraphQL. El proyecto técnico de GraphQL es la especificación en sí, la implementación de referencia, la herramienta gráfica y un puñado de otras cosas. La fundación tiene un marco que crea la estructura legal para esas cosas. Ellos poseen la propiedad intelectual de esas cosas, pero la junta de esa fundación GraphQL no puede tomar decisiones técnicas. Ellos delegaron formalmente todas las decisiones técnicas al comité de dirección técnica, que es este excelente grupo de personas que ven aquí. Somos nosotros quienes tomamos decisiones técnicas.

Esa es una barrera realmente importante entre estos dos para asegurarnos de que el conjunto de empresas que pueden tener intereses comerciales en vender GraphQL de una manera particular no tengan realmente la capacidad de hacerlo. Tal vez haya alguien que trabaja en una de esas empresas que esté en el comité de dirección, pero tienden a ser miembros bien razonados. El comité de dirección técnica es en realidad un grupo votado por la comunidad. La fundación ni siquiera puede elegir quién es ese comité de dirección técnica. Nosotros tenemos la capacidad de auto-selección. Eso es realmente importante para hacerlo.

El comité de dirección técnica, este grupo de personas, es esencialmente el subconjunto de las personas que asisten a estas reuniones de masterclass que tienen control de voto explícito. Si alguna vez hay un caso en el que necesitamos tomar una decisión firme y queremos tener un voto contado, eso es realmente lo primero y más importante de lo que es responsable el comité de dirección técnica. Lo otro es que somos los animadores o los campeones del grupo. Si algo importante necesita suceder, hay como, ¿quién lo va a hacer? Tiende a recaer en uno de los miembros del comité de dirección.

Luego está el masterclass. Hemos pasado mucho tiempo hablando sobre eso. Es una invitación abierta. Cualquiera puede venir, cualquiera en la comunidad que tenga una idea. El comité directivo técnico es el patrocinador y campeón de esa reunión. Ellos ayudan a operarla. Benji y yo en particular tendemos a co-dirigir esas reuniones, pero tendemos a delegar partes y piezas de eso a este grupo en su conjunto.

Espero que eso le dé a la gente una mucho mejor comprensión de los detalles del mundo, la mitad financiera y la mitad técnica. Sí, exactamente. Creo que tu explicación ahora solo probó mi otro punto, que es cuánto pensamiento se está poniendo en crear una comunidad abierta que se mantenga abierta y siga progresando. Así que gracias tanto por crear todo esto.

¿Algo que alguno de ustedes quiera decir justo antes de que nos vayamos? No tenemos mucho tiempo para continuar esta discusión. ¿Alguna última palabra que piensen que es importante para que la gente escuche sobre el grupo de trabajo en general? Solo quiero decir un enorme gracias a todos los que están involucrados en los Working Groups. Como dice Lee, hay mucho de lo que, tiempo de voluntariado que se dedica a avanzar en estas cosas y no es solo el caso de levantar una solicitud de extracción y esperar que se fusione.

Se trata de tener en cuenta toda la retroalimentación de varias otras personas en eso y también me gusta mucho que no nos aferramos realmente a nuestras ideas iniciales. Como que tomamos en cuenta esa retroalimentación y avanza y creo que eso es realmente genial, pero requiere mucho esfuerzo. Así que gracias, un enorme gracias a todos los involucrados. Gracias y gracias a todos aquí en la discusión final. Gracias por participar y gracias por su trabajo general en el Working Group. Es simplemente, uh, es asombroso. Así que muchas gracias por unirse a mí y gracias a todos los que se unieron en línea y espero verlos a todos o al menos a algunos de ustedes en los próximos Working Groups. Muchas gracias. Y en el chat. Oh sí, todos vamos a continuar en el chat así que pueden unirse a nosotros y preguntarnos.