¿En qué momento nos llenamos de APIs?

Las APIs son una alternativa accesible para el desarrollo de nuestros proyectos, pero ¿realmente las necesitamos? ¿Son la mejor opción? Te ayudamos a entender sus ventajas y desventajas, además de tener nociones para evaluar cuándo son la mejor alternativa.

Preparando el Workshop sobre APIs , quisimos hablarles a quienes ven en las APIs una herramienta para mejorar la experiencia de sus usuarios y no solo a quienes la desarrollan. Por eso, queremos llegar a quienes necesitan tener ciertos conocimientos mínimos para liderar un proyecto que aborde una integración mediante una API. A ellos queremos compartirles nuestras reflexiones y experiencia.

Nos llenamos de APIs

A diario usamos Slack, Google Suite, Jira y una larga lista de aplicaciones web que se comunican entre sí. Constantemente, casi sin reflexionar, otorgamos autorizaciones a cuanta “aplicación” nos solicita permisos para acceder a nuestros datos; con la promesa de que obtendremos una mejor experiencia de uso. Uber, Waze y Spotify, por mencionar ejemplos cercanos a todos, nos facilitan y personalizan la experiencia si las integramos con Google o Facebook.

Al cabo de unos pocos años pasamos de aplicaciones monolíticas de escritorio -que prometían hacerlo casi todo- a plataformas web fragmentadas en cientos de pequeñas integraciones de servicios. Hoy la tendencia en programación es la de construir micro servicios que se van integrando para construir herramientas más potentes y versátiles.

Y más aún, sin darnos cuenta, las APIs se tomaron un espacio que no para de crecer, llegando, por ejemplo, a nuestros hogares con Google Home o Amazon Echo . Herramientas que nos permiten conectar una variada gama de “ smartthings “, las que van desde ampolletas y parlantes hasta electrodomésticos como estufas y aspiradoras. Hoy todo es “conectable” y lo podemos controlar con nuestro teléfono o con un simple “Ok Google”.

En ese contexto, nos llenamos de APIs. No las vemos pero están ahí, con lo positivo y negativo que ello trae. Nuestros datos circulan por la red, podríamos decir que nos siguen para facilitarnos las cosas, permitiéndonos identificarnos y personalizar con poco esfuerzo una aplicación.

Por ejemplo, hace un par de semanas migré en dos click mi colección de música desde Google Play Music (QEPD) a Youtube Music. Eso incluyó todo mi historial y el resultado es que hoy las sugerencias de artistas y playlist son mucho más asertivas.

La promesa de la seguridad

En este uso, hay riesgos que no debemos ignorar, como la publicidad hipersegmentada de Facebook y el escándalo de Cambridge Analytica . Nuestros datos y actividades en Internet convergen sobre unas pocas grandes plataformas que conocen hasta la hora en que apagamos la luz o pasamos la aspiradora.

Particularmente en IDA no solo nos toca usar APIs de forma intensiva, sino que también nos ha tocado desarrollar para integrar distintas plataformas. Como indicaba más arriba, la tendencia hoy en programación y en SRE es construir o levantar micro servicios, que en muchos casos podemos entender como pequeñas APIs de usos muy específicos y que se van combinando en plataformas para construir herramientas con utilidades más amplias. Slack y son casos muy representativos de este tipo de plataformas.

Más beneficios

Son varias las ventajas de construir aplicaciones o plataformas basadas en una Arquitectura Orientada a Servicios (SOA); las principales son modularidad, escalabilidad, flexibilidad, agilidad, versatilidad y entrega continua.

Sin querer entrar en el detalle de cada una, destaco la modularidad y la escalabilidad, por cuanto implican robustez y redundancia. Es decir, a diferencia de una aplicación monolítica, si un componente o servicio falla, la aplicación podrá seguir funcionando, primero, porque el servicio caído no afecta el funcionamiento de los otros y, segundo, porque se puede reparar y reponer más rápidamente que en un sistema monolítico, que falla completamente al producirse un error en alguno de sus componentes.

Por otra parte, al tener la capacidad de incorporar servicios descentralizadamente, se convierten en herramientas más versátiles y atractivas para sus usuarios, incorporando nuevas capacidades mediante verdaderos marketplaces, donde puedo testear y comparar una misma funcionalidad implementada por dos proveedores distintos. Lo que nos permite quedarnos con aquella implementación que ofrezca mejores atributos.

¿Cuánto las necesitamos?

En esta realidad llena de APIs y servicios es altamente probable que tengamos que enfrentar constantemente la situación de evaluar si nuestro negocio o sitio requiere verdaderamente integrarse con algún proveedor de servicios. En muchos casos, no tendremos alternativas y en ese contexto necesitamos saber a qué nos enfrentamos.

La figura del iceberg sirve perfecto para ejemplificar que los usuarios solo aprecian la facilidad de usar una API, pero bajo eso hay un gran volumen de definiciones, protocolos, información y formatos que deben ser abordados para que esta “facilidad de uso” se logre.

¿Necesitamos un API realmente?

APIs como un puente

Partamos por verbalizar que API significa “Interfaz de Programación de Aplicaciones”. Sin entrar a detallar todos los aspectos técnicos es suficiente explicarla como un “puente” que permite la comunicación entre dos plataformas, aplicaciones o programas y entender que “este puente” define un protocolo o un estándar sobre cómo traspasar información entre un programa y otro. Es decir, qué y cómo se envía un conjunto de datos, qué esperamos que se haga con ellos y qué respuesta tendremos de vuelta.

Quienes estamos relacionados con proyectos digitales hemos visto en las API la solución a muchos de nuestros problemas, pero no a todos. Por lo tanto, siempre es importante verificar si existe una necesidad real de usarlas, y para eso, compartimos estos siete puntos que pueden orientar en esta verificación.

Verifica estos puntos:

Facilita el acceso

¿Aumentan significativamente los usuarios que podrán acceder a mi servicio o sitio simplificando el proceso de autenticación y registro de cuentas?

¿Cuál es la relación de tiempo, esfuerzo y costo para el desarrollo de esta integración?

Ampliar posibilidades funcionales

¿Agregar nuevos servicios que mejoran la experiencia de tus usuarios o son funcionalidades accesorias y de bajo impacto? ¿Tienes métricas que demuestren la necesidad de los usuarios para estas funcionalidades? O ¿Es un requerimiento levantado desde la gerencia sin argumentos fundamentados en test de usabilidad, encuestas o estudios de usuarios?

Centralizar información

¿Necesito alimentar una plataforma con muchas fuentes de datos? ¿El volumen de datos es significativamente alto para trabajarlos de forma descentralizada? ¿Necesito analizar y comparar de manera integrada estos datos?

Transformar datos en información

Este punto está relacionado con el anterior pero enfocado en determinar la necesidad de visualización de datos o de generar información consolidada en forma de reportes.

Analizar datos con machine learning

¿Tengo o genero datos estructurados para poder abordar procesos de análisis de machine learning?

Controlar dispositivos

¿Cuento con dispositivos que necesitan ser controlados de forma remota?

Automatizar procesos

¿Necesito ejecutar procesos de forma planificada y reiterada? ¿Necesito activar o generar acciones puntuales al cumplirse condiciones específicas?

En general se puede también analizar los tiempos, costos y complejidad de realizar integraciones a servicios existentes en contraste con desarrollar las funcionalidades requeridas.

Es de alguna obviedad verificar que esos servicios efectivamente existen o están disponibles, y en el caso contrario, verificar la viabilidad real de comenzar un desarrollo de alta complejidad. Por ejemplo podemos usar Webpay de Transbank, mas no construir desde cero una herramienta que haga lo mismo solo para usarla en mi e-commerce.

Hacer lo que ya está hecho, es mejor y tiene mejor soporte

En ese contexto, en IDA hay varios casos en los que con el tiempo hemos ido reemplazando el desarrollo propio, por la integración a APIs de servicios de terceros. Básicamente porque ahorramos tiempo y porque con menos esfuerzo obtenemos mucho más de lo que podríamos llegar a desarrollar.

Es decir, hay plataformas completas que se especializan, por ejemplo, en el envío de emails y que han resuelto problemas complejos. Es el caso de Mailgun que permite automatizar y programar -sin estrés del servidor-, el envío de emails masivos desde un sitio. Algo similar ocurre con Mailchimp y Sendinblue en el caso de los newsletters.

Otro caso similar es el de Hubspot. Construir un CRM es una tarea titánica y MS Dynamics es una prisión, pero integrarse con Hubspot llega a ser sorprendentemente fácil; tanto que al comienzo hasta asusta ver lo mucho que ganas en información sobre tus prospectos.

Chequea tus pros y contras

Siempre es sano analizar los pro y contra de cada caso. En cada caso, podemos hacernos las siguientes preguntas:

• ¿Existe un API de terceros o debemos desarrollarla?
• ¿Quiero solo consumir datos o necesito disponer información para que otros se integren a mi servicio?
• Siguiendo el ejemplo del CRM, ¿el equipo de desarrollo tiene conocimiento y experiencia para desarrollar una solución de esta complejidad?
• ¿Podremos construir una herramienta de primer nivel, con todas las prestaciones más innovadoras del mercado?
• ¿Tengo el presupuesto y tiempo para hacerlo? ¿O, finalmente, es más simple y ventajoso integrarme a uno de los líderes del mercado?

Buenas prácticas

Una vez confirmada la necesidad de integrarse vía API, lo primero es definir los alcances del proyecto. Es fundamental hacerlo y que sea de la manera más detallada posible. No es responsabilidad del desarrollador definir esos alcances. Esta es una tarea que debe hacer el mandante o el Jefe de Proyecto.

Siguiendo con el ejemplo del CRM, no basta con decir “necesitamos conectarnos vía API al CRM”. Esa es una definición tan amplia y simplista que es altamente probable que la solución se vuelva un obstáculo, producto de la falta de definiciones claras al respecto.

Necesitamos identificar claramente “los datos” que deseamos integrar. Si hay interacciones o micro-interacciones que puedan afectar la lógica de los datos que buscamos ingresar al CRM, por ejemplo, definiendo workflows distintos según la segmentación del prospecto o según el producto que se está cotizando.

Construir tu propia API

En el caso de tener que construir una API para que otras áreas o equipos externos de desarrollo consuman mi servicio, es absolutamente imprescindible considerar dentro de los alcances, la necesidad de documentar tanto la forma de usar la API como de documentar los métodos desarrollados. De esta forma, en caso de errores y futuras correcciones, será más fácil identificar y estimar los esfuerzos de una modificación. A su vez, con las obvias diferencias del caso, este punto también es válido cuando nos integramos a una API ya creada.

En este mismo sentido, también es parte del alcance considerar tiempos para realizar testeos e iteraciones de las funcionalidades desarrolladas. No detectar y corregir errores u omisiones de casos de usos durante la etapa de desarrollo, resultará siempre en correcciones posteriores de mayores costos, tiempos y esfuerzos.

Recuerda: Un error en producción puede salir por lejos más caro que un error detectado en forma temprana en Desarrollo o QA.

Finalmente, es necesario también considerar el factor “seguridad”. No es por asustar, pero generar un API, en muchos casos, expone información sensible que con sólo un “poco de fuerza bruta” y algo de ingeniería inversa, alguien obtendrá información confidencial sobre nuestros clientes o prospectos.

En conclusión, puede resultar obvio, pero considerar todos estos factores, marca una diferencia importante en términos de tiempos y costos de un proyecto que sí se hace cargo de cumplir con estos mínimos, versus uno que no. Lo barato muchas veces termina saliendo más caro.

Originally published at https://blog.ida.cl on September 23, 2020.