Header Ads Widget

Ticker

6/recent/ticker-posts

Arquitectura de un backend de API

 

Arquitectura de un backend de API


Hemos hablado en profundidad del negocio de API, las técnicas de monetización y la importancia de mejorar la experiencia para nuestro consumidor desarrollador objetivo. Pero en el fondo, ¿cómo se ve realmente la arquitectura de una plataforma API ? Así como los desarrolladores que usan una API confían en ella para impulsar sus aplicaciones, puede existir un ecosistema similar que alimente los componentes que componen una API en sí. Una API puede aprovechar varios servicios para respaldar su propio backend , lo que hace que la arquitectura sea engañosamente compleja.

La arquitectura de una API a menudo imita cómo se mantiene y lo que logra el servicio. En este artículo presentamos distintas arquitecturas API  de diversa complejidad categorizadas por función y nivel de acceso. Guiados por Johannes Lundberg , fundador y director ejecutivo de 46elks , definiremos las estructuras de backend de API en función de su dependencia de bases de datos externas / internas y el tipo de funcionalidad ofrecida, describiendo las pilas de arquitectura fundamental que componen varias API.

Cuatro tipos de API

Lundberg ve la esencia de una API como:

"Convirtiendo la complejidad tradicional en simplicidad programática".

Para seguir esta máxima, el trabajo del proveedor de API es disfrazar la complejidad cuando sea posible para favorecer la facilidad de uso. Dado que el diseño afecta íntimamente al comportamiento, Lundberg organiza las API según cuatro criterios de comportamiento distintos. Las dos primeras categorías se refieren al servicio en sí: "acceso a datos" y "efectos secundarios".


Vea cómo Johannes Lundberg de 46elks describe las diferentes arquitecturas de API

Las API de acceso a datos brindan acceso para recuperar o manipular cualquier tipo de datos. Los ejemplos incluyen iniciativas de datos abiertos, API de redes sociales como Instagram o Twitter, o API de transporte público como OneBusAway . Estos servicios pueden contener una base de datos compleja o pueden ser tan simples como un solo archivo CSV. Su principal valor es el intercambio de datos.

Las API de efectos secundarios , por otro lado, están más orientadas a ofrecer funcionalidad como servicio. El propósito de estas API es almacenar datos en un entorno de nube, facilitar pagos en línea, ofrecer infraestructura como servicio , comunicaciones en la nube y más.

Puede categorizar aún más las API web por tipo de acceso: ¿las dependencias se controlan interna o externamente? Las API autónomas tienen todo lo necesario para que el proveedor preste servicio a su API internamente; no se depende de componentes externos. Esto se opone a que dependa del proveedor , donde el software depende en gran medida de la funcionalidad o los datos de una empresa de terceros u organismo gubernamental.

Diagramas de arquitectura de backend de API

1) Acceso a datos: Arquitectura API autónoma

Supongamos que posee una aplicación de financiación colectiva y está exponiendo una API de información de usuario que permite a los desarrolladores acceder a la información de la cuenta de usuario. Funciona a través de HTTP y devuelve el formato JSON. Como tiene el control total, puede replicar este mismo backend y hacerlo escalable para otras situaciones también. Como posee los datos y controla la limitación de llamadas, hacer API listas para la nube es un proceso simple con una composición básica de backend como tal:

Acceso a datos: arquitectura de API autónoma API nórdicas Doerrfeld

2) Acceso a datos: arquitectura de API dependiente del proveedor

Supongamos que su aplicación agrega cuentas de usuario de muchas plataformas de financiación colectiva diferentes para proporcionar una única GUI a un usuario final. En este escenario, el proveedor de API se basa en los datos entrantes de plataformas de financiación colectiva de terceros. Para cualquier API que se base en la integración de proveedores, el rendimiento puede convertirse en un problema. También tiende a ocuparse más de integraciones heredadas donde las incompatibilidades pueden causar perturbaciones. Estos factores se pueden mitigar, pero con estas dependencias, pierde el control sobre la limitación de llamadas y las actualizaciones. Debido a estos factores, la arquitectura se estructura de manera diferente:

Acceso a datos: arquitectura de API dependiente del proveedor-02

3) Efectos secundarios: Arquitectura API autónoma

Las API orientadas a la funcionalidad implican de forma inherente factores más complicados que una simple API de acceso a datos. Por ejemplo, si usted es una empresa de impresión que ofrece una API para automatizar las órdenes de impresión, es probable que involucre  maquinaria  en su backend. En un entorno autónomo, usted controla ambos y, por lo tanto , involucra su producto íntimamente en el backend de su API:

Arquitectura de API autónoma de efectos secundarios

4) Efectos secundarios: Arquitectura de API dependiente del proveedor

Los servicios como la API de Printchomp pueden especializarse únicamente en el componente de software, un middleware que conecta al usuario final con varias integraciones finales. Más que solicitar datos, una API orientada a servicios con dependencias podría implicar realizar una llamada telefónica real, enviar un mensaje de texto, realizar un pago, analizar una imagen o más. El backend de un servicio como este se organiza fundamentalmente como tal:

Efectos secundarios: arquitectura de API dependiente del proveedor-02

En realidad

Hemos delineado diagramas muy introductorios que describen los posibles backends de API. En realidad, sin embargo, una plataforma API podría ser mucho más compleja, uniendo sistemas de socios externos, bases de datos internas y maquinaria autocontrolada.

Realidad-API-Arquitectura-API nórdicas

Alineación del conjunto de funciones con la arquitectura API

¿Cuál es tu característica principal? La arquitectura está ahí para facilitar este propósito. Si está diseñando una API desde cero y no está seguro acerca de la oferta principal, comience por definir cómo se diseñará la arquitectura de API de acuerdo con estos cuatro tipos. Si no encaja de inmediato en ninguno de estos diagramas, Lundberg aconseja tomar un poco de sabiduría del mundo de las startups: primero el prototipo .

Como los costos de desarrollo son altos, prototipo primero en lugar de diseñar una aplicación robusta con una arquitectura compleja. En una etapa de análisis , es mejor comenzar con lean con las pruebas iniciales del usuario y luego iterar en función de la demanda del consumidor. Haga que sus consumidores utilicen su API: lo que hay debajo del capó les importa menos. Lundberg aconseja a cualquier nuevo proveedor de API que cree un servicio que primero satisfaga las necesidades básicas de sus usuarios y luego se ajuste para cumplir con las condiciones reales del mercado siguiendo estos pasos:

  1. Diseño de producto
  2. Especificaciones
  3. Mantenibilidad
  4. Escalabilidad
  5. Característica Fluencia

"La regla de oro del diseño de API: en caso de duda, ¡déjela fuera!"

Lundberg nos recuerda que cuando se establece un parámetro, no hay retorno fácil. Ningún consumidor quiere cambiar sus implementaciones de código y una dependencia de API podría estar ejecutándose durante 10 a 15 años. En lugar de crear un servicio sólido desde el principio, aumente las operaciones de sus canales de soporte y escuche. Sus consumidores se comunicarán con usted.

Consulte: Razones detrás de las principales retiradas de API

Próximo

Una vez que se deciden los objetivos comerciales y la funcionalidad básica, surgen naturalmente cuestiones técnicas que afectan a la arquitectura. Algunos ejemplos incluyen:

  • XML / JSON : la mayoría de la comunidad de desarrollo de API aconseja utilizar JSON.
  • Servidores vs IaaS : ¿Está utilizando sus propios servidores o está subcontratando estos datos?
  • PUSH o PULL : ¿Su API permite la recuperación y manipulación?
  • OAuth o Basic : use mecanismos de seguridad avanzados para proteger su fortaleza API .
  • Coherencia frente a fiabilidad : siempre puede corregir los datos más tarde, pero no puede recuperar dos horas de tiempo de inactividad.

Diseño eventual

Una vez que desarrollas un prototipo y lo pruebas, terminas con algo como el siguiente esquema. Existe un mecanismo a prueba de fallas que permite un centro de datos de respaldo, y los flujos internos incluyen su equilibrador de carga, servidores web, bus de mensajes, trabajadores, bases de datos y procesos en segundo plano como facturación. La plataforma API en su conjunto puede interactuar con datos / funcionalidad de proveedores externos o maquinaria interna. Si conserva una oferta externa similar, es posible que la API no tenga que cambiar mucho en las etapas ficticias hasta la versión completa, ya que lo que está haciendo es hacer que la plataforma sea más fácil de mantener y escalable.

Arquitectura de backend final

Estudio de caso de 46elks: Complejidad oculta necesaria

En este artículo simplemente hemos arañado la superficie, ya que la creación de API debería ser compleja. Tome la API JSON europea 46elks Voice SMS / MMS . Desde una perspectiva externa, todo lo que los consumidores notan es una plataforma API con un diseño estable y de fácil acceso. Debajo del capó, sin embargo, hay un esquema muy ocupado lleno de muchas interrelaciones necesarias, almacenamientos de datos separados e interacciones de módulos de ida y vuelta.

“Es un montón de cosas con las que trabajar y seguir funcionando y mantener y mantener escalable, y en nuestro caso, cuando tenemos muchos, muchos operadores con los que estamos trabajando, tenemos que hacer acoplamientos redundantes para cada uno de estos operadores para cada uno de nuestros centros de datos. Pero vale la pena: esta es la complejidad que está eliminando para su consumidor ".

Los proveedores de API deben tomar la complejidad y hacer que parezca simple: ese es el valor real para el consumidor desarrollador, como lo demuestran Lundberg y muchos profesionales de API . Concéntrese en mejorar la arquitectura lo antes posible, ya que esta devoción conducirá a un valor futuro. Lundberg imparte los siguientes consejos generales para proveedores de API:

  • Realice el control de versiones.
  • Use JSON : hay muy pocas razones para usar XML hacia afuera.
  • Hable con sus consumidores de API : prototipo, agregue funciones básicas y luego agregue más en función de su respuesta.
  • Utilice la regla 80/20 para ofrecer funcionalidad a la mayor parte de los consumidores, en lugar de a todos los casos de uso.
  • Seleccione los proveedores con cuidado : evalúe críticamente al responsable de mantenimiento; como ocurre con la mayoría del software de código abierto, no habrá un servicio corporativo con un equipo de soporte dedicado.

Publicar un comentario

0 Comentarios