Sesión de preguntas y respuestas con Lee Byron

Entonces, sí, gracias, Lee, por unirte. Estoy realmente emocionado por AMA. Y permíteme comenzar con tal vez la primera pregunta, que probablemente eres uno de los mejores, si no el mejor, persona para responder esto. ¿Cómo comenzó GraphQL? ¿Cuál es la historia original de esto? ¿Y cómo terminamos todos aquí en esta extraña conferencia? Sí. Esto es un retroceso, porque esto fue, en este momento, hace más de 10 años, lo cual es algo loco. Para establecer el escenario, dos cosas estaban sucediendo en Facebook en este momento. Una era nuestra base de código monolítica que servía a Facebook.com estaba haciendo una migración desde una base de código PHP temprana a una más estructurada con una gran infraestructura de producto. Tenemos una especie de capa similar a ORM que termina y estamos comenzando a introducir sistemas de tipos en la base de código y eso estaba creando esta especie de abstracción increíble lejos de los sistemas subyacentes y el almacenamiento de datos, y tú simplemente podías interactuar con estos objetos de alto nivel para obtener los datos que necesitabas para poner juntos cualquier producto basado en web en particular que estuvieras haciendo. Esto era genial. Otra cosa que estaba sucediendo era el cambio a móvil. Entonces, Facebook, por supuesto, comenzó como una plataforma web de escritorio solo en 2003-2004, y desde allí lentamente se abrió camino hacia el móvil. Los primeros intentos en móvil fueron, si recuerdas, WAP, la variante de HTML que era completamente en blanco y negro y no tenía imágenes. Algo así como para teléfonos con tapa, creo que esa fue la primera versión de Facebook para móvil. Y luego eso evolucionó a medida que los dispositivos evolucionaron y siguieron la inercia de eso, y eso significaba que todo el desarrollo móvil en Facebook durante muchos años fue solo web. Había una aplicación de iOS, pero era muy limitada. Básicamente solo podías ver tu feed de noticias y eso era todo. Y eventualmente incluso eso fue reemplazado por la aplicación web completa. Había una especie de envoltura alrededor de ella. Y era malo. No era genial, como el rendimiento era malo. Intentamos hacer cosas realmente geniales, como animaciones en el navegador interno, y simplemente consumía toda la RAM de tu dispositivo, y eso se bloqueaba. Entonces era lento, tenía errores, se bloqueaba mucho y básicamente, la tecnología web, al menos en ese momento, no estaba creciendo y escalando, desarrollándola al ritmo que necesitábamos. Así que creamos un proyecto para volver al desarrollo nativo. Y esto fue en 2012, que todavía era relativamente temprano para el desarrollo móvil nativo, pero como una pizarra en blanco, un nuevo proyecto al estilo de Xcode, comenzamos a crear una nueva aplicación de iOS. Un pequeño equipo de tres o cuatro personas, desarrolladores de iOS, construyendo esto. Y se dieron cuenta de que simplemente no podían obtener los datos correctos que necesitaban, porque todo el desarrollo de Facebook hasta ese momento era básicamente solo cosas que sucedían detrás de escena en PHP, y luego HTML salía por el otro lado para servir una página web. Y no se había pensado mucho en una API, no como algo de asociaciones. Teníamos socios desarrolladores en Facebook que usaban una API de desarrollador. Pero no habíamos pensado en una API de producto. Como, ¿cómo sería construir un verdadero producto de Facebook sobre una API?

Entonces, resulta que en ese momento estaba apoyando a este equipo. Eran ingenieros que estaban trabajando en mi equipo. Y se encontraron con este problema y dijeron: bueno, vamos a investigar y ver qué podemos encontrar. Y comenzamos a analizar varias APIs que habíamos construido antes, y todas eran un poco decepcionantes. Y había una nueva que habíamos construido llamada FQL, que era una especie de variante de SQL, pero se basaba en este nuevo sistema ORM que habíamos construido, estos ENTs. Era realmente emocionante, pero si alguna vez has tenido que escribir una unión entre seis tablas, es como si el cerebro se derritiera. Básicamente, escribíamos estas consultas FQL que solo quizás dos personas en toda la empresa podían interpretar. Y eran como cientos de líneas de SQL para escribir estas consultas de unión. Pensé, esto es una locura. No creo que SQL sea la herramienta adecuada

para esto. Tiene que haber una mejor manera. Así que fuimos al autor de ENT, que era Nick Shrock, quien estaba desarrollando esta idea de que ¿qué pasaría si pudieras escribir PHP que no fuera PHP, pero se pareciera a PHP, y luego enviarlo al servidor? Y como era casi PHP, básicamente podías evaluarlo, pero no era realmente PHP, por lo que no había riesgos de seguridad. Básicamente, estaba inventando un nuevo lenguaje de programación para hacer comunicación a través de Internet, casi como un RPC de varias fases. Esto fue muy emocionante. Lo llamó Supergraph.

Y también estábamos construyendo una nueva versión de Facebook. Estábamos trabajando en News Feed primero. Así que fuimos al líder técnico de News Feed, que era Dan Schafer. Y él estaba en medio de migrar News Feed, que era uno de los códigos más antiguos de la empresa en ese momento, a esta nueva capa de Ent, adoptando las nuevas mejores prácticas dentro de la empresa. Y mi equipo estaba tratando de resolver el tema de la parte móvil. Así que los tres nos metimos en una sala y dijimos: bueno, tiene que haber elementos de las tres cosas en las que estamos trabajando que se alineen. Y básicamente no nos fuimos a casa durante una semana entera. Simplemente no podíamos parar. Nos emocionamos mucho con esto. Y en un par de semanas, teníamos un prototipo funcional que era básicamente la mitad de lo que se usa en GraphQL hoy en día, con un lenguaje, un analizador y un evaluador, y se basaba en Ents. Y en ese sentido, tenía funciones de resolución. Y funcionaba. Y se lo entregamos a nuestros ingenieros de iOS y estaban muy emocionados al respecto. Comenzaron a usarlo y hacía todo lo que necesitábamos que hiciera. Lanzamos esa nueva versión de la aplicación iOS con News Feed sobre ella, perfil y el resto, y en realidad esa base de código, esa línea de descendencia de la aplicación iOS es la que existe hasta el día de hoy. Si usas la aplicación de Facebook, esa es la misma base de código original que están utilizando. Y obviamente la infraestructura de GraphQL ha evolucionado considerablemente durante ese tiempo, pero hasta el día de hoy, GraphQL es la forma en que se sirven todos los datos en esa aplicación. Esa es la historia de origen. Ahí es donde viene GraphQL. Es una historia increíble. Para mí, aunque conozco un poco de la historia, creo que siempre es muy interesante porque creo que también habla mucho. También hay mucho que aprender para la comunidad. Hay mucho que aprender de esa historia hoy en día. Porque creo que todo lo que describiste sobre exponer datos de una manera estructurada para el producto, y sobre cualquier fuente de datos que no estaba necesariamente destinada a ser expuesta, y cómo lo resolviste, creo que hoy en día probablemente es una de las razones por las que GraphQL es tan popular. O al menos, ya sabes, lo que también puedo ver, como en

en el día a día, la gente está realmente emocionada por GraphQL debido a eso. Básicamente, sabes, te propusiste resolver esto tal vez específicamente para Facebook, y terminaste resolviéndolo para, creo, innumerables empresas en todo el mundo. Así que gracias, esto es realmente emocionante.

Sí, lo último nos sorprendió mucho. Creo que lo vimos como algo emocionante, pero nos pareció complicado. Y tenía sentido para, en cierto modo, las superficies de producto que estábamos construyendo, que de hecho eran bastante complicadas. Y requirió cierta persuasión, y mucha energía simplificadora se invirtió en las variantes que finalmente se hicieron de código abierto, lo cual es mucho mejor que el que teníamos al principio hace 10 años. Sí, bastante sorprendente. Sí, creo, sí. No solo has creado algo tan valioso, sino también has logrado hacerlo de código abierto, lo cual nunca es fácil en casi cualquier empresa. Entonces, ya sabes, una vez que lo hiciste de código abierto, me pregunto, ya sabes, GraphQL básicamente explotó. Y hoy en día hay muchas empresas y diferentes soluciones, y diferentes cosas que nuestra enorme comunidad está utilizando. Me pregunto, ya sabes, cuando ves todo lo que ha sucedido, ¿cuáles son las cosas que realmente predijiste o pensaste, Oh sí, eso se suponía que iba a suceder? Y ¿cuáles son las cosas que te sorprendieron, como, Whoa, no esperaba que nada de esto realmente sucediera, o como, ya sabes, y eso podría incluir dónde terminó, o incluso casos de uso que, como nunca pensaste que existirían. Creo que me ha impresionado y sorprendido la mayoría del crecimiento del proyecto y todos los que lo están utilizando. Y todos lo están utilizando de formas realmente interesantes y formas que inicialmente pensé que serían tal vez desaconsejables o un poco locas, pero en realidad resultaron ser muy interesantes. Hubo algunas charlas sobre la aplicación de GraphQL en bases de datos de gráficos. Y esto era como un temor que tuvimos que aclarar muy temprano, ya que la gente veía GraphQL y pensaba, Oh, porque tiene QL en el nombre, debe ser un lenguaje de base de datos. Y ya tengo una base de datos, como no me hagas reemplazar mi base de datos. No, no, no, no, no, no queremos reemplazar tu base de datos. Es solo una orquesta pura. Todo lo que hace es llamar a funciones en el fondo. No hay base de datos aquí. Y tan pronto como escuchamos que la gente iba a usar esto en bases de datos de gráficos, pensamos, esto se está moviendo en la dirección opuesta al temor que estamos tratando de aclarar. Y parecía probablemente no muy bueno, pero en realidad resultó ser increíblemente interesante. Y hay una línea de pensamiento separada en torno a cuando hicimos de código abierto React y no mucho después de eso, vimos Ohm, que fue una especie de combinación de React y el entorno de ClojureScript. Y ClojureScript está lleno de ideas súper interesantes que realmente merecen salir de ese ecosistema, pero a veces les cuesta hacerlo simplemente porque el entorno es tan, como el entorno Lisp es tan diferente. Pero una de ellas es esta idea de consultas de extracción. Y no fue hasta después, quiero decir, por supuesto, GraphQL es algo nuevo en su paquete, pero tiene muchas ideas que no son nuevas. Y esa fue una que estaba sorprendentemente alineada. Y otra cosa muy interesante que estamos viendo son las influencias entre las dos. Otra es ver la cantidad de personas que están adaptando y expandiendo GraphQL a nuevos

nuevos lenguajes, nuevos dominios, nuevos entornos, nuevos casos de uso. Quiero decir que esperaba eso, esperaba ver eso, y la velocidad a la que ocurrió fue más rápida de lo que pensaba que sucedería, lo cual es genial. Entonces, como alguien que dirige y como mencioné en la introducción, básicamente administra la Fundación GraphQL y los Grupos de Trabajo GraphQL, ¿qué cosas son las más interesantes, las más emocionantes que están sucediendo actualmente en GraphQL y cómo pueden las personas unirse o saber más al respecto?

Sí. La Fundación GraphQL es muy divertida porque hay dos formas de involucrarse. Puedes involucrar a tu empresa, lo cual es una excelente manera de tener un poco de influencia sobre la dirección general del proyecto en su conjunto. Hay un elemento financiero en eso. Así es como ayudamos a financiar el proyecto para que sea saludable y exitoso. Pero también puedes participar como individuo, lo cual es completamente gratuito, no tienes que hacer nada. Solo asistes a nuestras reuniones de Grupos de Trabajo y puedes participar en el desarrollo de nuevas características para el lenguaje GraphQL en su conjunto. Te daré una respuesta aburrida y luego una respuesta emocionante a esta pregunta. Y tal vez esto sea algo de mi obsesión, pero una de las cosas que encuentro muy emocionantes es el entusiasmo que las personas aportan a los problemas más pequeños. Porque los problemas más pequeños multiplicados por una cantidad increíblemente grande de desarrolladores que usan GraphQL es realmente muy importante. Y las personas están prestando atención a los detalles y asegurándose de que la calidad de R sea extremadamente alta. Verás que surgen temas que desempaquetan pequeñas discrepancias en la especificación que se manifestarían a través de un error que encontraron. Como, encontraron un error en algún lugar, y retrocedieron hasta el punto en el que se dieron cuenta de que había ambigüedad sobre cuál debería haber sido la respuesta correcta. Y luego lo corrigieron en la especificación y luego lo volvieron a implementar. Me encanta eso. Eso es lo que me emociona. Pero en términos de nuevas áreas de GraphQL, tiene que ser defer y stream. Esto convierte a GraphQL de ser algo transaccional a ser algo en vivo que ocurre con el tiempo. Y tenemos una versión de esto, que son las suscripciones. Y esto fue probablemente el cambio más grande desde que se hizo de código abierto, y eso sucedió hace varios años. Pero eso se trata más de, dado un flujo de eventos que ocurre en algún lugar en el fondo, ocurre un evento, y luego aún haces algo transaccional. Como, ejecutas una consulta GraphQL cada vez que ocurre un evento en algún flujo de eventos en el fondo. Pero defer y stream, digamos, dado un conjunto particular de datos que necesitas, una consulta GraphQL, puedes obtenerla transmitida a lo largo del tiempo. Un conjunto de cosas podría regresar en fragmentos, o podría haber un fragmento que digas, como, necesito esto, pero no de inmediato. Entonces, si lleva un poco de tiempo prepararlo, puedo diferirlo. Y eso es extremadamente difícil de hacer correctamente. La asincronía crea muchos casos especiales, y las personas que han estado trabajando en esto han estado haciendo un trabajo fantástico presionando los límites y asegurándose de que sea excelente. Y estoy muy, muy emocionado de ver qué hace esto en términos de desbloquear nuevos modelos de desarrollo, especialmente mientras observo el desarrollo de React y otras bibliotecas de código abierto para el frontend, que también están adoptando esta idea de entrega continua de datos y representación continua de la interfaz de usuario como algo que se fusiona. Estas dos cosas van de la mano, y estoy

Estoy realmente emocionado por eso. Gracias. Sí, esto es realmente, realmente emocionante, creo. Tengo la oportunidad de hablar contigo mucho. Escucho muchas charlas tuyas. Y siempre me pregunto, estabas en Facebook haciendo todo esto y creándolo e inventándolo , abriéndolo al mundo, pero ahora también tienes la experiencia después de haber pasado a Robinhood y ahora en Watershed como líder de ingeniería de productos, ¿cómo es tu experiencia personal con GraphQL? Y estás haciendo, creo que todos, hablaste un poco sobre lo que está sucediendo y cómo manejas la community y las cosas importantes que están sucediendo fuera en la community. Pero es interesante para mí escuchar también tu experiencia personal después de ahora, después de dejar Facebook y pasar por diferentes fases. ¿Cómo es tu día a día con GraphQL hoy, cómo te va? ¿Qué estás usando? ¿Qué ves? Si es que lo usas, o- Sí, usamos GraphQL en Watershed. Es la forma en que movemos datos entre nuestro servicio backend y nuestro cliente frontend. Y es genial. Es un caso de uso muy diferente al de Facebook, que tiene este esquema masivo y es muy desafiante. Requiere mucha infraestructura. En Watershed, estamos tratando de abordarlo de manera mínima. Tenemos un archivo que define todo nuestro esquema y un archivo que incluye todos nuestros resolvers, y eso es todo. Sin embargo, se siente más complicado de lo que quiero que sea, incluso en el enfoque de tratar de hacer la infraestructura mínima posible a su alrededor. Está funcionando muy bien para nosotros, pero una de las cosas que creo que es un problema aún sin resolver en este espacio. Y realmente espero que alguien pueda resolverlo, es sacar la cogeneración del rompecabezas. Usar GraphQL con cogeneración es fantástico. Puedes generar tus tipos de TypeScript, o tus tipos de Swift, o cualquier entorno de cliente frontend que estés usando, pero introduce este paso y es difícil editar el código en un archivo y luego ver inmediatamente cómo se actualiza tu entorno en otro archivo, y hay esta otra cosa que tienes que hacer que se siente como algo único. Y no sé cómo resolver ese problema, pero ese es el que si alguien tiene una idea súper ambiciosa y loca, es cómo integrar GraphQL en tu entorno de IDE y hacer que el paso de cogeneración desaparezca en segundo plano. Creo que eso haría que las cosas se sintieran mucho más fluidas. Sí, estoy completamente de acuerdo, creo que esto también es para nosotros, por cierto, trabajando, este es un problema o algo en lo que estamos investigando tanto en el backend como en el frontend, ¿verdad? En el backend tienes bibliotecas CodeFirst, creo que la última que nos emociona más en el mundo de JavaScript y TypeScript es POTUS, no sé si has tenido la oportunidad de verlo, pero es muy emocionante y en realidad se salta el proceso de generación de código y en el frontend, creo que hay muchas cosas nuevas, como cosas que también son CodeFirst. Hay todo tipo de soluciones diferentes y estamos investigando activamente las posibilidades. Pero también estamos investigando algunas de las limitaciones de TypeScript, pero creo que hay algunos trabajos en ello, así que sí, también me uno a tu llamado, así que si alguien está explorando esto, sí, hay promesa y si alguien quiere trabajar en esto, creo que tanto yo como Lee podemos hacerlo. Gracias Lee, esto fue fascinante. Y muchas gracias por unirte, para las personas en casa, también pueden ir al canal de Andromeda en Discord y hacer preguntas y estaremos allí también. Sí, muchas gracias y de vuelta a ti Cecilia. Gracias Lee por unirte. Gracias a todos.