Header Ads Widget

Ticker

6/recent/ticker-posts

Equilibrio entre complejidad y simplicidad en el diseño de API

 

equilibrio-simplicidad-complejidad-api-design-nordic-apis-ronnie-mitra-01

Los productos que nos entusiasman hoy son sencillos .

Tomemos como ejemplo los elegantes diseños de productos de Apple, el espacio negativo de la página de búsqueda de Google o las aplicaciones de función única que usamos a diario.

La idea de eliminar el desorden también se impregna en la discusión sobre las API o las interfaces de programación de aplicaciones. Por ejemplo, SOAP ha sido etiquetado una y otra vez como complejo, lo que motiva a los desarrolladores a recurrir a diseños RESTful . En el espacio de la API, la funcionalidad, la arquitectura y más pueden verse limitadas a raíz de ideales de diseño simples.

Aunque una tendencia hacia la simplicidad ha encapsulado la comunidad de productos tecnológicos y diseño web, no debemos permitir que tenga un efecto fascinante. Para muchas API, la complejidad es un ingrediente inherente fundamental para funcionar y sobrevivir en un mercado competitivo. Entonces, para encontrar un equilibrio, al diseñar API para un consumidor desarrollador , debemos recordar constantemente que la complejidad es el precio que pagamos por la utilidad .

Dado que el diseño y la experiencia del desarrollador son componentes críticos para una API exitosa, debemos dar un paso más y preguntarnos quién está pagando el precio por la complejidad de nuestras API. La complejidad es inherente al software: la ley de conservación de la complejidad de Tesler establece que cada aplicación tiene una cantidad inherente de complejidad irreducible. Entonces, la única pregunta es: ¿quién tendrá que lidiar con eso?

Complejidad dentro del dominio API

En la discusión sobre las API, la idea de complejidad resurge con bastante frecuencia. Según Ronnie Mitra de API Academy , la complejidad posee los siguientes atributos:

  • Compuesto por muchas partes
  • Intrincado, elaborado, interconectado
  • Difícil de procesar, requiere muchos recursos

También hay diferentes categorías de complejidad. La complejidad de la interfaz y la complejidad del sistema, por ejemplo, ofrecen diferentes perspectivas sobre cómo abordar el diseño de API, desde la perspectiva de la experiencia del usuario y desde la perspectiva de la arquitectura.

Complejidad de la interfaz

Grandes mentes han explorado los principios del diseño para describir nuestra mentalidad hacia la complejidad cognitiva en el diseño de productos. En Living With Complexity , Donald A. Norman postula que la complejidad es un elemento natural de la naturaleza y no debe extinguirse en sí misma:

"La complejidad en sí misma no es buena ni mala: es la confusión lo que es malo".

Dentro de Las leyes de la simplicidad , John Maeda llega a un punto similar, diciendo:

"La simplicidad consiste en restar lo obvio y agregar lo significativo".

volante bmw

La complejidad de la interfaz es un ejemplo directo de cómo la simplicidad y la complejidad se mezclan. Compare dos volantes: uno diseñado para un Mercedes Benz y otro para un automóvil de carreras de Fórmula 1. El volante estándar de Mercedes Benz es menos complejo: los fabricantes privilegian la usabilidad y la estética para satisfacer las necesidades de un conductor promedio. Dentro de un auto de carreras de Fórmula 1, por otro lado, muchos botones compiten por el espacio, los gatillos y la forma de la rueda están optimizados para una funcionalidad intrincada, un diseño intencionalmente complejo que personifica la complejidad cognitiva .

Por tanto, la complejidad se vuelve más una cuestión de percepción . Un problema solo surge cuando un elemento complejo, en su percepción y caso de uso únicos, todavía se concibe como confuso .

Gestión de la complejidad dentro del diseño de API

Entonces, ¿qué significan estos principios de diseño para las API? Mitra sostiene que el trabajo del diseñador de API es administrar la complejidad mejorando la capacidad de aprendizaje y la usabilidad , y reduciendo la confusión. Esto no significa necesariamente que la complejidad en sí deba sacrificarse.

"Diseñe la interfaz, pero adopte la complejidad inherente a su dominio empresarial"

Mira a Ronnie Mitra presente en la gira mundial de APIs nórdicas 2015

Pagar el precio de los servicios públicos

La complejidad es un precio que paga por la utilidad. En otro ejemplo, Mitra enfrenta el mouse de Apple con un solo clic contra el mouse de jugador de ultra acción, ¿cuál ganará? Bueno, tener un solo clic es simple, sí, pero su utilidad es limitada, ya que la complejidad adicional permite una funcionalidad adicional.

En su artículo titulado “No Silver Bullet”, Fred Brooks señala que la complejidad dentro del software debe considerarse como “una propiedad esencial, no accidental. Por lo tanto, las descripciones de una entidad de software que abstraen siempre su complejidad a menudo abstraen su esencia ".

Entonces, con el objetivo de crear API más elegantes y fáciles de usar , ¿qué deberíamos buscar? La respuesta es buscar la complejidad accidental, una complejidad superflua que se puede eliminar y que puede ser completamente innecesaria.

Diseño de API como producto: imitación y paginación

El diseño implica decidir si pagará el precio como proveedor o se lo dejará al desarrollador de la aplicación cliente. Esto implica visualizar el ciclo de vida del producto API como un todo para rastrear cómo surge la complejidad y cómo se aborda a lo largo de las principales etapas de la vida.

La etapa de análisis de una API comienza con la identificación de objetivos y el esbozo de un plan para el éxito. La ley de Conway establece que los sistemas de comunicación comerciales a menudo imitan la estructura de la organización. Para igualar este nivel de complejidad, Mitra recomienda que durante la preparación consideremos la segunda abstracción: que las interfaces (API) a menudo imitan estos sistemas.

Los desarrolladores se ocupan de la complejidad de la aplicación del entorno en el que trabajan. Un ejemplo de complejidad en el diseño se encuentra en la paginación de API. En una API diseñada con paginación , cuando envías una solicitud a la API, las respuestas se escuchan en fragmentos manejables. Sin embargo, en una estrategia sin paginación, devolver una gran cantidad de datos no estructurados significa que el desarrollador de la aplicación cliente paga el precio de la complejidad.

Teniendo en cuenta los enfoques de la paginación, si tomamos una metodología de compensación y recuento que utiliza la entrada que proporciona el cliente, el desarrollador aún necesita mantener una buena cantidad de complejidad. Si usamos un estilo de paginación de tamaño de página fijo , donde de manera predeterminada se devuelve una porción paginada de datos con enlaces e hipermedia de una solicitud, se pone menos estrés en el cliente. Yendo más allá, la paginación inteligente podría involucrar la cantidad correcta de datos devueltos para sus necesidades específicas en función de su aplicación, las solicitudes que ha realizado en el pasado y otras variables. Mitra enfatiza tener empatía por el desarrollador y considerar el mejor diseño de paginación que ofrece la menor cantidad de complejidad injustificada.

Recorrido por la publicación del blog CTA 5-01

Complejidad del sistema

Bandada de aves

Considere una bandada de pájaros. ¿Puedes predecir cómo vuela toda la bandada cuando está junta? En esta situación, la complejidad no es lineal y es difícil de predecir. Mitra señala que existen tanto Sistemas Físicos Complejos , como los sistemas meteorológicos complejos, como Sistemas Adaptativos Complejos , compuestos no de elementos, sino de agentes que cambian su comportamiento con el tiempo. Un ejemplo de un sistema adaptativo complejo es el mercado de valores. Desde el punto de vista de la complejidad, los humanos pueden tomar decisiones irracionales y su comportamiento cambia en el mercado. El sistema se vuelve más difícil de predecir y el equilibrio se vuelve más difícil de alcanzar.

Estructura del agente

John Holland , profesor estadounidense y pionero en algoritmos genéticos, describe una teoría sobre la estructura de agentes con distintos niveles de coherencia. Los agentes primero determinan su desempeño basándose en una determinada decisión: comprarán acciones. En segundo lugar, revisan su comportamiento y lo evalúan, lo que se conoce como asignación de crédito , que ocurre con el tiempo y se califica. Esto conduce al descubrimiento de reglas , en el que los agentes son llevados a crear nuevas reglas basadas en lo que han aprendido después de la experimentación.

Comportamiento emergente y adaptativo

Dentro de un sistema como el mercado de valores, comenzamos a ver especialización y diversidad a medida que los agentes se especializan en realizar determinadas tareas. Notamos que el comportamiento se descentraliza; el sistema en su conjunto tiene su propio comportamiento y puede adaptarse al cambio; el sistema en su conjunto demuestra un comportamiento emergente .

Definición de emergencia :

“La acción del todo es más que la suma de las acciones de las partes”

Con esto en mente, Mitra sugiere que los desarrolladores creen sistemas que consideren el comportamiento adaptativo de los consumidores y también que amplíen lo que consideramos un límite. En lugar de diseñar sistemas con la noción de que la aplicación cliente es una entidad completamente separada, Mitra prevé una descomposición continua de los límites de la aplicación, aumentando nuestra capacidad de cambiar constantemente y exhibiendo un verdadero comportamiento emergente.

OAuth 2.0 y complejidad

¿ OAuth 2.0 es complejo? Muchos dirían que ciertamente lo es. Dentro de la versión 2.0, se ha agregado mucha utilidad. El marco contiene cuatro flujos, una gran cantidad de partes móviles; es intrínsecamente complejo. Sin embargo, OAuth es una parte de facto de la pila de seguridad de la API . Entonces, ¿por qué la complejidad está bien en este caso?

Una forma de entender esto es imaginar si pudiera medir la distribución de la complejidad de OAuth 2. Lo que vemos es que la persona que paga el precio por la complejidad es el implementador del servidor , no el cliente. De repente, el tiempo y el costo de la integración son justificables ya que el proveedor paga el precio. Dejar una implementación de seguridad sin resolver puede parecer un pequeño problema, pero los usuarios pagarán un precio perjudicial por la utilidad. Según Mitra:

"El diseño y la arquitectura de repente se centran en encontrar cuál es la complejidad esencial y luego moverla".

Complejidad en microservicios

La estructura monolítica tradicional se está descomponiendo, separada en microservicios más pequeños En un monolito , los mantenedores de código se ven obligados a realizar actualizaciones exhaustivas y elaboradas en todo un sistema, lo que aumenta el precio que pagan y la complejidad involucrada. Se puede argumentar que el papel de los mantenedores del sistema, por otro lado, se reduce, ya que de manera integral, el sistema tiene menos piezas con las que lidiar.

Dentro de la arquitectura de microservicios ocurre lo contrario y los encargados del mantenimiento del sistema ahora pagan el precio. La capacidad de aprendizaje mejora, los cambios de código se realizan en lotes más pequeños y, por lo tanto, más fluidos, sin embargo, el responsable del sistema tiene partes móviles adicionales con las que lidiar.

Con la contenedorización, la implementación y el descubrimiento ahora prominentes en la arquitectura de microservicios, se produce una gran transición y se realiza una compensación. Un servicio se volverá menos confuso, pero la complejidad del sistema holístico aumentará. Estamos viendo que vale la pena pagar el costo por esta complejidad .

Entonces, ¿todo bien en microservicios?

Mitra sostiene que se encuentra una advertencia de la arquitectura de microservicios durante la implementación. Quizás este enfoque no piensa lo suficiente en la aplicación cliente. Puede haber diferentes modelos de datos entre microservicios, aumentando el tipo y la cantidad de llamadas que se realizan. Esta complejidad tiene un costo para los desarrolladores de aplicaciones cliente, no lo que desea si está desarrollando API dentro de un mercado competitivo.

Para evitar esto, los proveedores están cambiando la complejidad al SDK. Pero, ¿es este un resultado final? Mitra cree que el proceso a menudo no borra la complejidad del sistema, sino que expande los límites del sistema, creando dependencias adicionales y complejidad del sistema para el usuario.

Conclusión: la complejidad adaptativa como un conjunto de características

El consumo de API es un proceso único que implica la interacción entre el ser humano , que exhibe actividades que no son en tiempo de ejecución y comportamientos adaptativos, y la máquina , con actividades en tiempo de ejecución y un comportamiento determinista. Con tantas variables en juego, Mitra prevé una complejidad escalable como un destino futuro para los diseñadores de API. Para resumir nuestros puntos sobre la complejidad, recuerde las siguientes lecciones:

  • La complejidad es parte natural de la vida y es especialmente inherente a los procesos de software: ¡abrázala!
  • Evite la confusión en el lado del cliente mejorando la capacidad de aprendizaje y la usabilidad.
  • Utilice la paginación inteligente para exponer los datos de una manera que le facilitará la vida.
  • Oculte la complejidad en el lado del servidor siempre que sea posible.
  • Tenga una perspectiva abierta al futuro de la descomposición y considere cómo incorporar las teorías de la complejidad del sistema dentro del diseño de API.

Publicar un comentario

0 Comentarios