Header Ads Widget

Ticker

6/recent/ticker-posts

La necesidad de una capa de composición de API

 


Hoy en día, puedes encontrar API web dondequiera que mires, y los desarrolladores crean más cada día. Por un lado, eso es algo bueno: muestra que estamos viviendo en una era de interoperabilidad. Por otro lado, el cambio hacia plataformas fuertemente basadas en API conlleva una gran carga técnica. Los desarrolladores ahora enfrentan las altas complejidades de los sistemas informáticos distribuidos. La solución a esto, dice Tina Huang, cofundadora y directora de tecnología de Transposit, es composición de API . Al empaquetar el complejo tedio de la integración de API y servicios en una capa separada, podemos permitir que los desarrolladores se concentren en la funcionalidad mientras minimizan la fricción del desarrollo.

Basamos este artículo en una presentación de Tina Huang en nuestra Cumbre API de Austin 2019. Tina tiene una amplia experiencia en la creación de plataformas y servicios para gigantes tecnológicos como Google, Twitter y Apple.

Diapositivas

El problema: creciente complejidad en los ecosistemas de API

Impulsadas en parte por el auge de la industria SaaS, las organizaciones de todo el mundo buscan adherirse a las estrategias de API primero. De hecho, las razones para hacerlo son numerosas: desacoplar los sistemas tecnológicos, permitir que los equipos operen de forma independiente y atender a un número creciente de dispositivos de los clientes, entre otros. El resultado de esto es que todas las aplicaciones web se están convirtiendo efectivamente en plataformas. Las aplicaciones no solo deben compartir datos con otros, sino que también deben consumir datos de una variedad de fuentes externas. Por lo tanto, cada vez menos desarrolladores crean aplicaciones desde cero. En cambio, el trabajo de los desarrolladores está cada vez más dominado por la necesidad de conectar y combinar las API existentes en nuevas aplicaciones (y nuevas API). Desafortunadamente, conectar las API rara vez es tan fácil como “juntar bloques LEGO”, dice Tina. Cada API es un poco diferente:un copo de nieve , se podría decir. Los desarrolladores tienen que dedicar más tiempo a leer documentación esencial sobre cómo funciona una API en particular antes de poder comenzar a usarla. Además de la documentación, varios matices técnicos hacen que cada API sea única:

  • Cómo se separan los datos en los puntos finales (p. Ej., El problema N + 1)
  • Cómo se gestiona la paginación; por ejemplo, la API de Slack usa la friolera de cinco mecanismos diferentes para la paginación
  • Cómo se realiza la autenticación
  • Límites de tasa, reintentos, etc.

Estos matices causan fricción y aumentan el tiempo de incorporación. En última instancia, generan una gran complejidad, no dentro de la lógica central de una aplicación, sino en las interacciones de docenas de servicios y API. Si hace una pausa y lo piensa, esto significa que todos los desarrolladores de aplicaciones en el ecosistema de API deben ser expertos en computación distribuida. Deben poder codificar contra redes no confiables, administrar latencias largas y evitar invocar límites de velocidad. Nuestra industria ya enfrenta una escasez de desarrolladores. Tina dice que estos nuevos estándares solo elevan el listón de lo que se necesita para ser un desarrollador eficaz en el mundo de las API.

La solución: composición de API

Tina define la composición de API como todo el trabajo técnico necesario para conectar y combinar fuentes de datos. Si está familiarizado con las bibliotecas para desarrolladores, piense en la composición de la API como el mismo principio, eliminando la sobrecarga técnica de la adopción de la API, a mayor escala. Así es como Tina define la composición de la API:

“Una plataforma de composición de API abstrae esos detalles mecánicos de trabajar con diferentes API y permite a los desarrolladores centrarse en la lógica de la aplicación central. Permite a los desarrolladores expresar su intención a un nivel superior, por ejemplo, el desarrollador puede especificar la cantidad y los criterios para los resultados, y la plataforma de composición de API pagina y filtra los datos automáticamente ".

Ya que algunosLa lógica de composición a menudo se comparte dentro e incluso entre las organizaciones, puede comenzar a consolidar este código en exceso a medida que pasa el tiempo. Tina dice que hacerlo puede ayudar a amortizar los costos de desarrollo de la construcción contra API en múltiples desarrolladores. Un enfoque de lógica compositiva compartida tiene varios beneficios. Al utilizar una única caché compartida, la lógica de composición permite que las aplicaciones funcionen mejor. También mejora la confiabilidad al garantizar que no presione las limitaciones técnicas de las API individuales. Tina proporciona un ejemplo de la vida real de cómo este tipo de solución podría ser útil en el contexto de la limitación de velocidad. Una vez habló con una empresa cuyo producto principal dependía de la API de Salesforce. En otra parte de la organización, un contratista había estado construyendo una integración Marketo-SalesForce. Desafortunadamente, el contratista superó sus límites de tarifas, eliminando así el servicio de producción central de la organización. Entonces, ¿cómo empezar con la composición de API?

Sus opciones para la composición de API

Tina dice que tiene algunas opciones cuando se trata de su solución de composición de API.

Bibliotecas y módulos

El enfoque más ligero para la composición de API es el uso de bibliotecas y módulos. Sin embargo, no resolverá todos sus problemas. Un problema es la falta de gobernanza, que con el tiempo significa que terminará con muchas versiones de la misma biblioteca, sin una forma fácil de desaprobar las versiones anteriores. Si no existe un método sencillo para actualizar las bibliotecas de sus diferentes productos, esto podría convertirse en un problema bastante serio cuando hay un error de seguridad que corregir. Tina menciona algunas historias de terror asociadas con las bibliotecas, como cuando el autor de un paquete simple de NPM llamó left-padinédito su trabajo, rompiendo miles de proyectos en la web. O cuando un pirata informático secuestró brevemente la biblioteca de Eventstream. Los cambios sutiles en una biblioteca en un lado pueden tener consecuencias masivas para las aplicaciones que los utilizan. Por supuesto, estos son ejemplos extremos, pero demuestran problemas potenciales asociados con las bibliotecas.

Microservicios

Otra solución para la composición de API es una arquitectura de microservicios. El uso de una capa de administración para microservicios puede proporcionar un lugar centralizado para el almacenamiento en caché, la limitación de velocidad y la implementación de correcciones de seguridad. Tina cree que esto es excesivo para muchos problemas. Tomar esta ruta de administración de microservicios requiere que los desarrolladores creen una sobrecarga aún más técnica: asignar nueva infraestructura, configurar la implementación y configurar el monitoreo para cada nuevo servicio. Si solo tiene unos pocos microservicios, probablemente lo esté haciendo bien: utilizando microservicios para encapsular bases de datos internas y representar su infraestructura central. Sin embargo, si tiene cientos o miles de microservicios, es una señal de que podría estar utilizándolos también para albergar la lógica de composición.

Sin servidor

Una alternativa más liviana es un enfoque sin servidor , también conocido como Funciones como servicio arquitectura de . En este caso, utiliza servidores que no ejecuta ni administra usted mismo. Serverless permite a los desarrolladores concentrarse en su código con una "limpieza" mínima. Esto tiene sus propias complejidades: tener que enrutar las solicitudes al código correcto para una puerta de enlace o, si usa una solución como AWS Lambda, tener en cuenta la latencia de poner en marcha un nuevo servicio. También existe el problema de no poder almacenar el estado dentro de las funciones. En definitiva, esta es la solución que recomienda Tina. Siempre que la plataforma permita a los desarrolladores concentrarse en su código mientras se encarga del "trabajo pesado" de la composición, está haciendo su trabajo.

Si aún no está listo ...

Si aún no está listo para implementar o crear una solución de composición de API, Tina tiene algunas sugerencias para usted. El problema de más API y más gastos técnicos es inevitable, y el primer paso es aceptarlo. Entonces, el consejo de Tina es el siguiente:

  • Adopte estándares internos sobre cómo crea API (autenticación, paginación)
  • Adopte estándares y especificaciones como OpenAPI
  • Verifique las soluciones de Funciones como servicio en su proveedor de nube existente
  • Gestiona tus API como productos, siempre pensando en la experiencia del usuario

Pensamientos finales

Hay un número de API en rápido crecimiento en la naturaleza, y conectarse con ellas se está volviendo muy complicado. Tina dice que podemos eliminar una gran cantidad de esta complejidad con las soluciones de composición de API, que absorben la tediosa lógica de integración de los ecosistemas de API y permiten a los desarrolladores centrarse en la funcionalidad principal de su aplicación. Entre bibliotecas, arquitecturas de microservicios y el enfoque sin servidor / Functions as a Service, Tina cree que esta última es la mejor solución para muchos de nosotros.

Publicar un comentario

0 Comentarios