Esta semana, MuleSoft agregó una capacidad de DataGraph a su plataforma Anypoint para integrar aplicaciones que emplean el lenguaje de consulta GraphQL para descubrir, acceder y servir instantáneamente datos de múltiples API existentes con una sola consulta sin escribir ningún código adicional.
Al mismo tiempo, MuleSoft agregó conectores adicionales Automation Anywhere, Google Sheets, JIRA, Netsuite y Stripe, junto con una instancia de MuleSoft Accelerators para conectarse a aplicaciones SAP utilizando conectores y mejores prácticas definidas por MuleSoft.
Entre esas mejores prácticas para desarrolladores de API se incluyen:
- Crear expectativas: Mantenga sus líneas de comunicación abiertas y claras. Dígales a los desarrolladores lo que espera de ellos y del proyecto, proporcione plazos claros y aborde cualquier punto débil que la funcionalidad API debería resolver.
- Mensajería de servicio: Todas las API y los servicios deben alinearse con los objetivos comerciales y liderar los servicios destinados a brindar valor para los productos y servicios nuevos y existentes.
- Estudios de caso: Use estudios de casos para proporcionar evidencia e ilustrar las mejoras que la adopción de API traerá al proyecto.
- Documentación: Asegúrese de que las herramientas de documentación estén implementadas para que el equipo de desarrolladores pueda documentar con precisión su progreso en la adopción de la API.
- SDK y bibliotecas: Proporcione recursos como códigos y procesos reutilizables (incluidos SDK y bibliotecas) para ayudar a acelerar el desarrollo y la implementación.
Finalmente, MuleSoft ahora está haciendo que Anypoint Runtime Fabric esté disponible por primera vez en plataformas Kubernetes como Azure Kubernetes Service, Amazon Elastic Kubernetes Service y Google Kubernetes Engine. Anypoint Runtime Fabric hace posible implementar de manera consistente la plataforma Anypoint encapsulada dentro de un contenedor.
Anypoint DataGraph emplea las mismas capacidades básicas de GraphQL que MuleSoft incorporó anteriormente en las aplicaciones de software como servicio (SaaS) proporcionadas por la empresa matriz Salesforce. Ahora esas capacidades están disponibles más ampliamente para otras aplicaciones a través de un conjunto de herramientas de código bajo en la plataforma Anypoint que permite a los desarrolladores emplear GraphQL de manera más amplia como una alternativa a las API REST, dice Shaun Clowes, vicepresidente senior de gestión de productos en Mula Suave.
Ese enfoque simplifica a los desarrolladores la integración de sus aplicaciones con otras fuentes de datos, independientemente de si la aplicación que crean está construida utilizando código de procedimiento o una plataforma de código bajo. Incluso cuando los desarrolladores prefieren escribir su aplicación usando código procedimental, todavía tiene sentido emplear una herramienta de código bajo para crear una integración más rápida, señala Clowes.
Los desarrolladores de hoy necesitan poder consumir datos de manera flexible a través de múltiples API a medida que las iniciativas de transformación de negocios digitales continúan expandiéndose y evolucionando, agrega Clowes. En efecto, se requiere que los desarrolladores compongan aplicaciones rápidamente para permitir que sus organizaciones respondan hábilmente a los requisitos comerciales que cambian rápidamente, dice Clowes.
Los tipos de desarrolladores que emplean herramientas de integración de código bajo también están comenzando a expandirse. Los llamados desarrolladores ciudadanos están comenzando a crear aplicaciones que necesitan consumir datos a través de API. La sofisticación de esas aplicaciones naturalmente varía dependiendo de las habilidades de esos desarrolladores.
“El desafío con los desarrolladores ciudadanos es cuán ciudadanos son”, dice Clowes.
Independientemente de quién construya las aplicaciones, cada vez es más fácil para los desarrolladores con diferentes conocimientos reutilizar las API. Los desarrolladores profesionales, por ejemplo, podrían crear una biblioteca de API examinadas que otros desarrolladores podrían reutilizar. Lo que se requiere es un enfoque centralizado para construir e implementar API que brinde un marco de gobernanza muy necesario, ya que la responsabilidad de construir y mantener los cambios de API se inclina más hacia los desarrolladores, señala Clowes. Eso es fundamental no solo desde una perspectiva de cumplimiento, sino también porque no es poco común que los desarrolladores trabajen en un proyecto separado para crear API redundantes.
En el futuro, está claro que las API están en el centro del desarrollo de aplicaciones a medida que continúa evolucionando. Las aplicaciones basadas en microservicios de próxima generación dependen de que cada servicio tenga su propia API. La cantidad de API que las organizaciones pueden encontrar pronto podría ascender a miles. GraphQL proporciona un eje fundamental que falta para hacer frente a todos ellos. El desafío ahora es encontrar la mejor manera de implementarlo junto con las API REST heredadas que no desaparecerán en el corto plazo.
