Desacoplamiento de API con API First [ES]

8 min readMar 16, 2020

Introducción

Los valores y principios de la Arquitectura Orientada a Servicios (SOA) han influido en mi vida.

En caso de que no hayas seguido la serie SOA que escribí:

Por ahora, es una serie escrita solo en portugués, pero si algún lector de inglés o español está interesado, puede escribirme en esta publicación.

Tengo la intención de mantener los otros temas que he escrito como prioridad, pero hay muchas cosas que ya escribí en mi Medium que necesito traducir, solo necesito saber qué traducir primero.

Como se indicó en el primer artículo, cuando entré en el mundo SOA, pensé que Orientación a Servício tenía un JAR, algo así como AspectJ es para Orientación de Aspecto. En mi opinión, todo era tecnología y programación.

Todas estas primeras impresiones las puedes seguir a través de los artículos anteriores.

Para profundizar un poco más en la historia, me gustaría compartir con ustedes a la persona que me sacó de mi ignorancia de que Java resolvería todo, el hombre, la leyenda, el mito: Valério Aymoré Martins.

Valério es el caballero más más a la derecha, y fue él quien me ayudó en mis primeros pasos con Arquitectura orientada a Servicios, en un instituto de investigación conocido como el Instituto Brasileño de Tecnología e Innovación, IBTI.

Después de hacer contacto con SOA, inculcar tanto en mi cabeza que el desacoplamiento de las capas de servicio era correcto, que tuve dificultades para entrar en un mundo diferente de SOAP, REST.

Servicio de desacoplamiento de capas

El problema con mi transición no fue SOA ni SOAP. Era un desarrollador Java Pleno en ese momento, sin embargo, solo era un desarrollador SOA Junior.

Cuando me enteré de Contract-First y sus ventajas, fue como si todo para mí tuviera que ajustarse a esta premisa. No me importa si puedo hacer una API REST fácilmente con NodeJS o Spring Boot, si no se pudo hacer con Contract-First para mí fue de una manera incorrecta.

Era muy joven para darme cuenta de que estaba perdiendo muchas cosas y conocimiento en REST, dada mi inmadurez.

Al comienzo de esta historia, puedes leer aquí con mi historia sobre RAML, y aquí, cuando comencé mi conocimiento con Swagger.

No voy a entrar en gran parte del mérito de si estoy de acuerdo en que REST debe o no seguir siempre un enfoque API First, pero me gustaría compartir con ustedes un escenario en el que hemos visto que API First encaja muy bien , Viaje del cliente.

Viaje del cliente

Trabajé en IBTI, y más tarde en Core Consulting, en ambas compañías con SOA, y necesito mencionar a otra persona que me influenció mucho principalmente en temas de soft skills, André Toffanello. Gracias al sesgo más técnico de Valério con la vista fuera de la caja de Toffanello, pude comenzar mi mentalidad con lo que SOA define como alineación entre el negocio y la TI.

Esto me ayudó más tarde en AIS Digital con personas como Isaac Canan y Rafael Lucyk. Con una mentalidad SOA, podría proponer ideas para generar innovación, buscar autonomía y poder discutir puntos de vista.

Sobre AIS, todavía tengo la intención de escribir otro post algún día. Volvamos a SOA y al viaje del cliente.

Contract-First y API First son cosas por las que aprecié mucho. Dado que siempre trabajé como back-end, vi esto como una ventaja significativa en el desacoplamiento, y la posibilidad de poder desarrollar cosas como mock después del contrato propuesto, con eso, el peso en el equipo de back-end ha disminuido.

Sin embargo, trabajar en una empresa de tecnología especializada en productos digitales me ayudo a comprender algo inesperado.

Era posible abordar el contexto funcional y la granularidad de mis servicios, así como su gobernanza si me acercara a un equipo que nunca pensaría que algún día abordaría: el equipo de UI, UX y Design.

API First, UI, UX y Design, ¿cómo nunca he visto esto?

Si desea hablar con alguien que aprecia los servicios en una Arquitectura Orientada a Servicios, aquí hay algunas palabras que pueden ganar puntos con él: granularidad, gobernanza, autonomía, composición, entre otros.

Una de las dificultades más importantes para los profesionales en esta área es el tamaño de grano que un servicio debe tener para ser considerado lo más agnóstico posible, lo que genera más Retorno de la Inversión (Return of Investiment, ROI).

Cuando hablamos de servicios agnósticos, estamos hablando de servicios que podemos usar en varios contextos en las composiciones de servicios. Por lo tanto, no se centran en un escenario específico.

Trabajé en un proyecto en AIS en el que el equipo de UI, UX y Design me ayudó a darme cuenta de que tienen un papel vital con el cliente, ayudándome con mi API.

Siguiendo los dos dibujos, es posible notar las capas que son más o menos agnósticas, así como las capas que están más cerca de los procesos y el viaje del cliente.

En AIS comenzamos a hacer algo muy interesante, poner a las personas con la capacidad de especificar API junto con personas que están diseñando viajes actuales y nuevas de clientes.

UI, UX, y Design: Top-Down o Bottom-Up

¿Y cómo influyen Top-Down o Bottom-Up?

Cuando hablamos de soluciones con aplicaciones heredadas, el profesional que especifica las API puede plantear dificultades con el equipo de UI, UX y Design. El diseño de algunos prototipos de pantalla, que muestra que puede no ser posible lograr la máxima usabilidad y experiencia del usuario dado el legado existente, apuntando así a un enfoque de Bottom-Up.

En escenarios greenfield, podemos enfocar las innovaciones y abstracciones que guían el viaje.

En los escenarios de Top-Down y Bottom-Up, ¿qué queremos nosotros como especificadores de API en un enfoque API First? Que cuando el desarrollador front-end o el back-end den vida a las definiciones de creación de prototipos, no tendremos sorpresas como: “oh, esta pantalla no podrá implementarse así, porque nuestro back-end no ofrece esta funcionalidad “.

De acuerdo, pero ¿qué pasa con el código?

No sé si Linus Torvalds dijo esa famosa frase, recuerdo esa otra famosa frase:

De todos modos, sé que usted desarrollador que me acompaña debe estar pensando que me estoy metiendo, después de todo, dije antes de hablar en esta publicación sobre la implementación del proyecto que ya está en mi GitHub.

Creo que es importante alinear estos problemas comerciales antes. Algunos proyectos me muestran que cuanto más nosotros, como desarrolladores, nos distanciamos del negocio, menos nos valoramos y menos personas ven el impacto de nuestras acciones en los productos y los viajes.

Aunque comencemos a discutir algunos puntos más técnicos para dar una dirección sobre lo que hablaremos en la próxima publicación, esta más técnica, esta vez, lo prometo.

¿Qué base de datos debo usar en API First?

¡Muchas gracias Igor Vieira por este gif épico! jajajajajajajajajajaja

Uno de los errores que más vemos cuando se trata del viaje del cliente es que nosotros, como desarrolladores, ya hemos comenzado a definir definiciones SQL o NOSQL en este punto, cómo conectarse con la columna X, Y, Z y otras cosas que van juntos.

El punto es que, si ya comenzamos a mirar y dirigir nuestras API en una estrategia en API First con nuestra base de datos, naturalmente estaremos interrumpiendo el viaje del cliente. Limitaremos al cliente a una experiencia de algo logrado de alguna manera, cinco, seis, diez años o más. Es difícil creer que nuestro sistema heredado esté alineado con el viaje del cliente que estamos descubriendo ahora.

¡En un enfoque digital, creemos que el cliente está en el centro!

Hablaremos más sobre esto en la próxima publicación. Hay una frase famosa que lo expresa: “No siempre se puede ganar”, para desacoplar el contrato con el back-end, terminaremos necesitando desacoplar las capas del modelo API con las capas del modelo de persistencia.

Otro punto interesante es que a veces tendremos que disminuir la experiencia del cliente en detrimento de nuestros legados. Sin embargo, este no debería ser el punto de partida, esa es la idea.

En APIX 2019, Kleber Bacili, CEO de Sensedia, asociada de AIS y representante brasileño en Gartner y Forrester Wave en la categoría API Manager, dijo algo interesante:

Aunque Sensedia tiene un conector y se integra directamente con una base de datos, esto termina trayendo un acoplamiento que quizás no queramos vincular directamente con nuestra capa API.

¿Y qué hay de APIX 2020? Para aquellos que no saben, las inscripciones para este año ya están abiertas.

Puedes ver APIX 2019 en el canal de Sensedia en Youtube en la lista de reproducción en inglés y en la lista de reproducción en portugués. También hay algunos videos en español.

¡AIS Digital también estuvo allí! Puede consultar las pautas que dirigieron esta publicación, Samuel Corado, y hablé sobre Transformando su estrategia de canales con APIs:

En la próxima publicación, hablaremos sobre OpenAPI 3.0, Spring Boot, Maven, Gradle y Kotlin. Nos vemos más tarde…