Header Ads Widget

Ticker

6/recent/ticker-posts

Entrevista con el cocreador de GraphQL, Lee Byron

 Recientemente, nos reunimos con el co-creador de GraphQL, Lee Byron, para conocer la historia y el futuro de GraphQL. ¡Espero que lo disfrutes!

Los orígenes y el futuro de GraphQL

Hace diez años, Lee Byron era un ingeniero gráfico que diseñaba gráficos de noticias interactivos en el New York Times cuando un amigo se le acercó para unirse a una pequeña empresa de redes sociales con sede en San Francisco, California. La compañía era Facebook, que acababa de superar a MySpace como el sitio web de redes sociales más visitado del mundo en ese momento. Cuatro años más tarde, Byron se encontró dirigiendo el equipo que trabajaba en la aplicación iOS nativa de Facebook cuando se plantaron las primeras semillas para lo que luego evolucionaría a GraphQL .

Las aventuras de SuperGraph

“Comenzamos este pequeño proyecto de skunkworks donde dos ingenieros de mi equipo y dos ingenieros que eran relativamente nuevos en la compañía comenzaron a construir lo que se convertiría en la aplicación nativa de iOS para News Feed”, dijo Byron.

El equipo produjo un prototipo funcional de alta calidad. Sin embargo, no estaban fuera de las malas hierbas. Cuando Byron descubrió que faltaban historias de News Feed porque habían utilizado una API de socio de plataforma no compatible de tres años de antigüedad, se dio cuenta de que tendrían que crear una nueva desde cero.

“Eso hizo que las cosas entraran en crisis ... Pensaron que casi habían terminado y resultó que les quedaba un montón de cosas por hacer, así que comencé a concentrarme en esos problemas y dije: 'Está bien, necesito crear una sección de noticias API de alguna manera. ¿Quiénes son las personas con las que necesito hablar? ¿Cómo debe hacerse eso? Un gran problema es que News Feed es increíblemente complicado y la tecnología API típica probablemente no haría el trabajo correcto, así que comencé a esbozar cómo se vería una buena API. Definitivamente no era lo que GraphQL es ahora, pero fue como comenzar a tener indicios en esa dirección ".

Añadió: “Mientras tanto, otro de los co-creadores de GraphQL, Nick Schrock, acababa de pasar los últimos años trabajando en una gran cantidad de infraestructura de datos en nuestro servidor y había pasado un poco de tiempo exponiendo algo de eso a través de API, no GraphQL, pero un tipo diferente de API, y tenía una idea de cómo se podría hacer esto mucho, mucho más simple, así que le doy el crédito a Nick Schrock con el primer prototipo que realmente se parecía a GraphQL. Lo llamó SuperGraph ".

Un miembro del equipo de Byron le presentó a Schrock y Dan Schafer, aclamado como el mejor ingeniero de News Feed en Facebook en ese momento, y el trío comenzó a trabajar en una versión inicial de GraphQL.

"Los tres nos pusimos manos a la obra para tratar de descubrir cómo construir una mejor API de News Feed y llegamos muy lejos", dijo Byron. "Creo que solo uno o dos meses de mejoras iterativas en lo que comenzó como un prototipo que envolvía todas nuestras ideas, terminó siendo la primera versión de GraphQL".

El lanzamiento de la aplicación nativa de iOS, ayudado por la introducción de GraphQL, fue un éxito y la emoción en torno a GraphQL y sus capacidades hizo que otros equipos de Facebook se interesaran en usarla. Como resultado, Byron y el primer equipo de GraphQL continuarían desarrollando un ecosistema completo alrededor de GraphQL; cómo se integró con las aplicaciones de iOS y Android, cómo se integró en el servidor y GraphiQL , el IDE en el navegador.

La fase final del proyecto fue la decisión de utilizar GraphQL de código abierto en 2015, algo que fue impulsado en parte por el lanzamiento exitoso de React , la biblioteca de JavaScript de código abierto de Facebook, y también por el deseo de Relay de código abierto, la biblioteca abierta de Facebook. marco JavaScript de origen, que estaba inherentemente vinculado a GraphQL.

“Estábamos entusiasmados con eso. Quiero decir, compartir cosas con la comunidad siempre es bueno, pero sería mucho trabajo y no estábamos totalmente seguros de que las personas fuera de Facebook se preocuparan o encontraran valor en él. Pensamos que tal vez esto era algo que solo resuelve un problema de Facebook y no era una solución genérica, pero el equipo de Relay nos tenía emocionados, así que seguimos ese camino y estoy muy feliz de haberlo hecho. GraphQL ahora tiene una comunidad realmente grande fuera de Facebook ".

Lanzamiento y adopción de GraphQL

La adopción de GraphQL tomó mucho menos tiempo de lo que el equipo predijo inicialmente. Hablando en la primera cumbre GraphQL en octubre de 2016, Byron dijo que esperaba que GraphQL fuera recogido por las grandes empresas dentro de cuatro años y alcanzara la ubicuidad en cinco años. Byron se rió al reflexionar sobre la precisión de esas predicciones.

“Creo que sobrestimé el tiempo que tardarían las grandes empresas en adoptarlo y subestimé la ubicuidad. Probablemente se deba a que la "ubicuidad" es un poco vaga, pero ciertamente sigo hablando con toneladas de personas que trabajan en el espacio API y, en el mejor de los casos, dicen "Oh GraphQL, creo que he oído hablar de eso antes, pero realmente no sé lo que es". Ciertamente es mejor este año que el año pasado y mejor que el año anterior ".

Añadió: “Recuerdo haber ido a una conferencia de APIDays poco después de la primera GraphQL Summit y, literalmente, no hubo charlas sobre GraphQL. Después del siguiente, hubo una pista completa hablando de GraphQL. El siguiente GraphQL apareció en una de las notas clave y no había una pista específica, pero GraphQL estaba disperso. Así que definitivamente está cobrando impulso. Creo que hay un progreso visible hacia una ubicuidad si queremos hablar de ubicuidad como conocimiento. Las personas conocen la tecnología, lo que hace y por qué deberían usarla o no ".

Relacionado: ¿GraphQL se está moviendo hacia la ubicuidad?

Una de las mayores sorpresas para Byron fue ver a Github convertirse en uno de los primeros en adoptar la tecnología , especialmente porque los considera un líder de API.

“Me sorprendió mucho ver que un año después de que GraphQL fuera de código abierto, Github decidió que su API pública sería GraphQL. Eso fue particularmente significativo porque ayudaron a popularizar RESTSabes que REST ha existido por un tiempo, pero en realidad no era la forma dominante y popular de crear API hasta que Github decidió crear su API y usaron REST e hicieron un gran negocio al respecto y escribieron un montón de publicaciones de blog y todos prestaron atención. Pensé: "Vaya, esta API está muy bien construida, debe ser gracias a REST" y fue en gran medida, pero también porque la gente de Github es realmente inteligente y construyó una API realmente excelente. Es realmente emocionante para mí que considero a Github como una especie de líder de API y ellos se lanzaron a eso primero y ya no son los únicos ".

Las API GraphQL y REST pueden coexistir

Aunque GraphQL ha sido alabado como el sucesor natural de la tecnología REST, Byron es modesto acerca de sus capacidades y cree que los dos pueden coexistir .

“Ciertamente no soy una de esas personas que piensan que he inventado la bala de plata aquí y que todo debería ser GraphQL y no hay lugar para nada más. Creo que sería un poco imprudente. Creo que REST es una tecnología increíble, así que me entristecería mucho verla desaparecer ".

Últimamente hemos comparado las diferencias entre REST, GraphQL, gRPC, webhooks y más en el blog y encontramos fortalezas únicas entre los formatos para varios escenarios. De manera similar, Lee ve muchas cosas que REST hace mejor que GraphQL y viceversa. Específicamente, ve que la dicotomía representada en API públicas vs. privadas.

“Creo que a medida que GraphQL continúe expandiéndose en alcance, veremos un equilibrio mucho más saludable entre los dos. Mi expectativa era que las API públicas seguirían siendo REST porque era más simple y más familiar donde las API internas , por lo que para construir el propio producto de su empresa, usaría GraphQL porque, si bien aportaba más complejidad, también aportaba más expresividad y capacidad ".

A medida que GraphQL continúa creciendo, una de las cosas que Byron está emocionado de ver es que más API públicas adoptan la tecnología , como lo han hecho las empresas con REST.

“Creo que el espacio de las API públicas o las API de socios es particularmente interesante porque creo que la gran mayoría de la adopción de GraphQL hasta ahora ha sido para los proyectos internos de una empresa. Por ejemplo, Walmart usa GraphQL pero lo usan para la aplicación Walmart. Sería realmente interesante que GraphQL comience a usarse para estas API públicas y asociadas para que tengamos empresas que estén trabajando entre sí. Entonces, no se trata solo del diseño de API y el modelo mental dentro de esa empresa, sino entre empresas.

Creo que podría ser realmente interesante porque podría ayudar a comenzar a construir un gráfico conceptual de toda la información. No creo que GraphQL vaya a ser la tecnología que nos lleve allí, pero ese es uno de los grandes sueños de Internet es que podríamos tener Internet de datos únicos, pero debemos comenzar a tener algunas conversaciones serias a lo largo de ese camino si alguna vez lo hacemos. quiero llegar allí. Creo que GraphQL podría ser un trampolín realmente útil en ese camino ".

Descargue nuestro libro electrónico GraphQL GRATUITO: GraphQL o Bust

Esperanzas para el futuro de GraphQL

A pesar de estar contento con su creciente popularidad y el desarrollo de código abierto que lo rodea, Byron espera ver un mayor crecimiento en las herramientas e integraciones de GraphQL .

“Es un poco triste que exista el Apollo Client para iOS y Android y luego eso es todo”, dijo. “Es necesario que haya muchas piezas en competencia allí y eso es cierto para cualquier tipo de tecnología que haya alcanzado la ubicuidad y que tenga al menos dos, si no más cerca de una docena de opciones diferentes sobre cómo implementarlo. Si quisiera crear un servidor web, hay cientos de formas de crear un servidor web en docenas, si no cientos de idiomas, y ahí es donde también quiero llegar con GraphQL ".

Byron dejó Facebook después de una década de servicio para convertirse en jefe de ingeniería web en la startup FinTech Robinhood a principios de este año, citando el deseo de trabajar en una empresa más pequeña y su visión refrescante como algunas de sus razones para irse.

“Robinhood tiene hoy aproximadamente el mismo tamaño que Facebook cuando me uní y realmente lo extrañaba. Me di cuenta de que uno de los mejores trabajos que hice en Facebook fue cuando eran un poco más pequeños. No es que Facebook no sea un gran lugar para trabajar ahora, es solo que realmente aprecié tener un entorno de trabajo más pequeño y estaba feliz de tener eso de vuelta ".

“También me interesan las finanzas en general, por lo que es un nuevo espacio para aprender que ha sido bastante divertido y luego tienen un montón de desafíos técnicos y de personas realmente interesantes. Ese es mi pan y mantequilla. Me encantan los problemas técnicos y los problemas de personas. También me interesan los problemas del producto, pero es nuevo para mí, así que hay espacio para aprender ".

Además de eso, sigue siendo el editor de la especificación GraphQL y dirige las reuniones del grupo de trabajo para garantizar que GraphQL continúe mejorando y al mismo tiempo mantenga la estabilidad.

“Uno de mis objetivos para GraphQL es que sea estable porque Amazon, Twitter, Pinterest, Airbnb, Facebook, Walmart y muchas otras empresas han apostado su futuro por GraphQL. Si GraphQL cambia demasiado rápido, los directores de ingeniería de esas empresas pueden sentirse conmovidos y cuestionar la elección de usar esa tecnología. Al mismo tiempo, quiero asegurarme de que haya espacio para que GraphQL crezca y mejore y que esas mejoras no tengan que venir de mí. No creo que sea la persona más inteligente de la sala. Quiero asegurarme de que las experiencias de personas de muchas empresas y entornos diferentes puedan ayudar a influir en esa dirección ".

GraphQL sigue siendo una tecnología nueva. Ha inspirado a una gran comunidad de código abierto y la adopción ha sido impresionante en un corto período de tiempo.

“GraphQL es todavía nuevo. Estoy realmente impresionado con cuánto ha construido la comunidad de código abierto y cuánta adopción ha ocurrido dentro de la comunidad de código abierto, especialmente en las grandes empresas. Quiero decir, hay un montón de grandes empresas que están usando GraphQL y eso es sólo tres años después del código abierto, creo que es bastante increíble, pero siempre hay espacio para crecer ".

Publicar un comentario

0 Comentarios