Header Ads Widget

Ticker

6/recent/ticker-posts

Entrevista con el ponente: William Lyon de Neo4j

 Entrevistamos a William Lyon de Neo4j, un orador en la próxima  Austin API Summit 2019 .


William Lyon es un ingeniero de relaciones con desarrolladores en Neo4j, la base de datos de gráficos de código abierto. Con experiencia trabajando en varias startups ágiles, el trabajo actual de William se centra en integraciones GraphQL; de hecho, se unirá a nuestro LiveCast “Diving into GraphQL” a finales de este mes.

Actualmente, estoy trabajando en integraciones GraphQL para Neo4j, con un enfoque en facilitar a los desarrolladores la creación de API GraphQL sobre Neo4j. Como resultado de este trabajo, mantengo
neo4j-graphql.js y soy colaborador de GRANDstack.io .

Vea a William en el Austin API Summit

Si está interesado en el tema de GraphQL, le alegrará saber que William dedicará su sesión en la Austin API Summit 2019 a eso: crear y consumir API GraphQL. No hace falta decir que es un tema que le apasiona bastante.

Hablaré sobre la creación y el consumo de API GraphQL, con un enfoque en el uso de servicios sin servidor y en la nube para crear API GraphQL escalables, básicamente cómo hacer GraphQL fullstack. Cubriré algunas lecciones que he aprendido sobre el trabajo con GraphQL en los últimos años y por qué es un cambio de juego completo para quienes crean API y para los desarrolladores que crean aplicaciones que consumen API. Es realmente una nueva forma de pensar sobre los datos en el contexto de las API.

Esta charla debería ser interesante para aquellos que están considerando construir una API GraphQL, o cualquiera que haya oído hablar de GraphQL pero aún no entienda de qué se trata todo el bombo. También hablaré sobre algunas de las herramientas emergentes que facilitan la creación de API GraphQL y cómo puede aprovecharlas.

Nuestra integración Neo4j-GraphQL es solo una pequeña parte de esa comunidad, hay muchas herramientas increíbles disponibles para crear servicios GraphQL en muchos lenguajes y marcos diferentes, así como herramientas del lado del cliente increíbles para crear aplicaciones en GraphQL.

Avanzando con las API

Continuando, le preguntamos a William sobre las tendencias de diseño de API que está buscando en 2019. No hace falta decir que GraphQL es bastante alto en su lista, ¡y una gran parte de eso se debe a los esfuerzos de la comunidad para impulsar el desarrollo!

Bueno, ciertamente estoy entusiasmado con GraphQL y cómo está evolucionando el ecosistema GraphQL.
GraphQL es todavía bastante nuevo y ciertamente hay un interés creciente en torno a él, pero el ecosistema de herramientas en la comunidad GraphQL también se ha disparado. Cuando Facebook creó GraphQL en código abierto en 2015, rápidamente quedó claro que la comunidad estaba interesada en crear herramientas para simplificar el trabajo con GraphQL. Hemos visto herramientas para facilitar la creación de API GraphQL sobre bases de datos, agregar autenticación e incluso formas de extender GraphQL sin dejar de ser compatible con las herramientas del ecosistema.

En términos de las estrategias que podemos utilizar para impulsar las API en industrias emergentes como IoT e IA, no hay una respuesta única. William analiza el ejemplo de IoT y explica cómo la compatibilidad de los dispositivos y la velocidad de la red deberían ser dos de las consideraciones más importantes al desarrollar API para este mercado:

Para IoT, el control de versiones y la compatibilidad con versiones anteriores de las API se volverán aún más críticos a medida que la cantidad de dispositivos obsoletos que no se actualizan aumenta exponencialmente. Es mucho más difícil garantizar que los clientes de una API estén actualizados cuando hablamos de tostadoras inteligentes conectadas a través de una red celular heredada. Ser capaz de mantener la compatibilidad con versiones anteriores de API para garantizar que estos dispositivos sigan funcionando según lo previsto incluso años después de recibir actualizaciones es clave para la evolución del espacio de IoT.

Un punto relacionado para IotT es que creo que es especialmente importante tener en cuenta primero los entornos fuera de línea y los entornos de red pobre al diseñar API, ya que los dispositivos no siempre están conectados a redes rápidas. De hecho, estas consideraciones estuvieron a la vanguardia del diseño inicial de GraphQL: minimizar la cantidad de solicitudes de red y reducir los datos enviados a solo exactamente lo que solicita el cliente, para optimizar el rendimiento de la aplicación móvil en redes inalámbricas de baja calidad.

Austin-API-Summit-2019-Registrarse

Cuando le preguntamos a William su opinión sobre hacia dónde se dirige la economía de las API, llamó nuestra atención sobre el perfil cambiante del uso de datos personales. William dice que las empresas que anteriormente dependían de los datos de los usuarios para su modelo de negocio ahora tendrán que actuar con cuidado.

Creo que veremos impactos en este espacio por la mayor conciencia y preocupación por la privacidad de los datos y una mayor regulación (como GDPR). Las empresas se han dado cuenta desde hace un tiempo de que pueden monetizar los datos de los usuarios empaquetando y vendiendo el acceso (piense en la API Graph ahora neutralizada de Facebook) o construyendo servicios sobre estos datos (como publicidad dirigida), pero la reacción es La privacidad de los datos y el aumento de los costos de cumplir con la regulación hacen que estas prácticas sean potencialmente menos valiosas y más riesgosas.

Para estas empresas que ofrecen acceso a los datos del usuario como parte de la economía API, deben reconsiderar cómo extraer valor de estos datos. ¿Vale la pena vender el acceso, incluso a nivel agregado? ¿Podrían, en cambio, encontrar valor utilizando estos datos internamente? Como resultado, creo que veremos más API reduciendo la cantidad de datos de usuario que expondrán, en lugar de elegir tener el control directo de cómo se monetizan estos datos.

William cree que este cambio en la forma en que compartimos los datos de los usuarios podría conducir a la desaparición de más aplicaciones de pequeña escala a menos que los desarrolladores estructuran su relación con los proveedores de API en un nivel más profundo y consciente del negocio.

Esto tiene un impacto significativo para los consumidores y desarrolladores de API que se basan en API de terceros. Hemos visto que cuando los proveedores optan por bloquear estas API (por ejemplo, LinkedIn y Twitter han tenido restricciones significativas en sus API a lo largo de los años), muchos desarrolladores han visto cómo sus aplicaciones dependían de estas API cerradas. Eso hace que sea peligroso para los desarrolladores construir sobre estas API de terceros sin relaciones comerciales formales, lo que significa que las organizaciones deberían considerar hacer una inversión en el desarrollo de un ecosistema de socios robusto para solidificar estas relaciones comerciales.

Cuando le preguntamos sobre el papel de las API en la arquitectura de nube de nivel empresarial, William respondió lo siguiente:

Las API son críticas para la arquitectura de la nube porque las API desacoplan la tecnología de implementación y el modelo de datos del método de acceso; sin ellos, los usuarios externos tendrían que saber demasiado sobre la tecnología y los datos subyacentes para que los servicios en la nube sean útiles. A medida que trasladamos más y más infraestructura a la nube, las API se convierten en una forma de unir estos servicios.

Mencionaré GraphQL nuevamente como una forma de lograr esto. Se ha convertido en un patrón común utilizar una API GraphQL como una forma de unir datos de varios servicios y dominios en una organización. El concepto de la idea de GraphQL de "One Graph" con implementación federada, popularizado por Principled GraphQL de Apollo, proporciona un marco para esta idea de unir servicios dispares a través de GraphQL.

Cree mejores API

Suficiente sobre hacia dónde se dirige el panorama de las API: hablemos de cómo podemos construir y consumir mejores API en la actualidad. Parte de eso comienza con ofrecer una experiencia de desarrollador fantástica, que según William se encuentra en la documentación:

Una buena documentación es clave. Puedo recordar algunos días muy malhumorados que pasé trabajando para integrar nuestra aplicación con nuevas API y estar tan frustrado con la mala documentación. Por no señalar con el dedo, pero las industrias de bienes raíces y finanzas no son exactamente conocidas por construir APIs bellamente documentadas . Una documentación deficiente puede hacer que los desarrolladores tomen mucho tiempo para construir con su API o solucionar problemas cuando las cosas se ponen difíciles.

Solo para que esté completamente consciente de lo incondicional que es un fan de GraphQL, William explica cómo GraphQL facilita la documentación:

Y esta es una de las razones por las que amo tanto GraphQL. Se dice que las API de GraphQL se autodocumentan, a través de la función de introspección de GraphQL. El esquema GraphQL se convierte en la especificación y documentación para la API y con herramientas como GraphiQL y GraphQL Playground se puede buscar y explorar fácilmente. El sistema de tipos de GraphQL también garantiza que el cliente reciba exactamente lo que espera.

En cuanto a la seguridad de API, William sugiere que pasemos a utilizar servicios de seguridad y administración de API dedicados para que podamos dedicar más tiempo a los productos en sí:

Una consideración aquí es apoyar el cambio a servicios administrados. Para la mayoría de las empresas, la implementación de la seguridad (o la gestión de la infraestructura) ofrece muy poco valor comercial único; esa es solo una característica estándar que debe cuidarse.

Dejar que las organizaciones que eligen hacer de la seguridad y la gestión de la infraestructura su actividad principal garantiza que los expertos se ocupen de estas funciones y que podamos volver a centrarnos en la creación de servicios, aplicaciones y resolución de problemas empresariales. Por ejemplo, aproveche las ofertas de bases de datos como servicio como Neo4j Cloud y proveedores de servicios de identidad como Auth0, ya que hay poco valor comercial agregado al administrarlos internamente.

API inútiles

Es hora de relajarse un poco: ¿cuál es la API "inútil" favorita de William? No es otro que An API of Ice and Fire , la API inspirada en Game of Thrones que expone datos sobre los personajes de la fantasía, las batallas, etc.

En Neo4j somos grandes admiradores de trabajar con datos de Game of Thrones como ejemplo para el modelado de datos, visualización y cómo aplicar algoritmos de gráficos. Con esta API, podría, por ejemplo, extraer datos sobre interacciones de personajes, ejecutar PageRank para encontrar a las personas más influyentes y detección de comunidades para inferir lealtades. Ser capaz de demostrar ese tipo de análisis de datos en los datos de una serie de televisión es divertido y atractivo, pero también es un gran indicador de cómo esos mismos procesos se pueden aplicar a datos comerciales "aburridos" para ofrecer valor en el mundo real.

Cerrando

Para concluir nuestra entrevista con William, queríamos volver al tema de nuestra Cumbre API 2019 en Austin , donde está emocionado de conocer gente nueva y comer tacos.

Por supuesto, estoy deseando conocer a muchos amigos nuevos en la API Summit y estoy seguro de que aprenderé mucho sobre las API, pero Austin es una ciudad muy divertida. Y, por supuesto, espero con ansias la barbacoa y los tacos de desayuno, pero una cosa que quiero hacer este año es ver a los murciélagos volar desde debajo del puente de Congress Ave sobre el río al atardecer. Pienso en esto cada vez que llego a Austin, ¡pero nunca lo he hecho!

Publicar un comentario

0 Comentarios