Header Ads Widget

Ticker

6/recent/ticker-posts

Por qué los controladores basados ​​en estándares ofrecen una mejor integración de API

 Por qué debería utilizar controladores para integrarse con fuentes de datos dispares


A medida que las empresas crecen, también lo hace el número y la variedad de fuentes de datos que utilizan para impulsar el negocio. La empresa promedio usa al menos dieciséis aplicaciones SaaS y tiene datos en al menos esa cantidad de almacenes de datos locales y aplicaciones internas.

Con datos tan dispares, cada uno vinculado a una API única, la integración, la gestión y el mantenimiento de integraciones para todos los datos de una empresa crea un conjunto completamente nuevo de desafíos. Afortunadamente, existen soluciones que permiten a las empresas confiar en los datos para impulsar el negocio sin causar una tensión indebida. En este artículo, exploraremos y compararemos las diferentes opciones para resolver el problema de integración de datos y explicaremos por qué debería utilizar controladores basados ​​en estándares para abstraer sus integraciones de API.

Opciones comunes para la integración de API

A medida que busca resolver el desafío de la integración, se le presentan muchas opciones. Los más populares tienden a lo siguiente:

  • Integración directa : realizar llamadas directas a una API o servicio directamente
  • SDK : bibliotecas y enlaces específicos del idioma
  • Middleware : ESB, productos ETL o un programador empresarial

La mejor opción para usted depende en gran medida de cómo está usando los datos ahora (y cómo planea usar los datos en el futuro), sus propias limitaciones de tiempo y dinero y el contexto de sus necesidades de integración.

Si tiene un caso de uso sencillo, como verificar el éxito o el fracaso de una operación o mostrar una respuesta simple, cualquiera de las soluciones anteriores funcionará.

Sin embargo, a medida que los flujos y requisitos de su negocio se vuelven más amplios, es posible que se encuentre buscando un enfoque centrado en los datos para su integración. En este caso, se presenta una nueva opción de integración: controladores basados ​​en estándares . Con los controladores, sus tareas de desarrollo se simplifican a través de una interfaz unificada.

¿Qué es un controlador basado en estándares?

Probablemente esté familiarizado con los controladores para bases de datos (piense en tecnologías como JDBC, ODBC, ADO.NET, etc.). Gracias a la tendencia hacia datos dispares, muchas empresas están comenzando a crear o encargar controladores basados ​​en las tecnologías establecidas que hacen que las API parezcan bases de datos, traduciendo consultas SQL en solicitudes de API. Por ejemplo, NetSuite ha creado sus propios controladores JDBC y ODBC y un proveedor ADO.NET para usar en su plataforma Suite Analytics. Además, empresas como CData Software a menudo crean controladores basados ​​en estándares de terceros en nombre de las empresas (por ejemplo, HarperDB y SlicingDice ).

Modelado de una API a través de SQL

  • Las tablas y vistas corresponden aproximadamente a colecciones de recursos (pedidos, cuentas, usuarios, etc.)
  • Los elementos individuales de un recurso generalmente corresponden a una fila, con campos asignados a columnas.
  • Las subcolecciones pueden tener una relación de clave externa con las colecciones principales (pedidos y elementos de línea de pedido)
  • Las operaciones CRUD se traducen aproximadamente a declaraciones SQL:
SOLICITUD HTTPSQL EQUIVALENTE
OBTENERSELECCIONE
ENVIARINSERTAR
PONER, PARCHEACTUALIZAR
ELIMINARELIMINAR
  • Las operaciones y entidades que no se representan fácilmente se implementan mediante procedimientos almacenados.

Ahora que hemos explicado los conceptos básicos de un controlador basado en estándares, exploremos los enfoques comunes para la integración de datos y los beneficios y consideraciones que rodean a cada uno.

Enfoques de integración comunes

Integración directa

PROSCONTRAS
Mayor controlIntegración más larga
Integración simplificadaMantenimiento de por vida
Reutilización limitada entre fuentes de datos

La integración directa de API es excelente para los casos de uso más sencillos, como verificar el éxito o el fracaso de una operación. La integración directa le brinda el mayor control sobre cómo se autentica un usuario o aplicación, cómo se mantiene la seguridad y cómo se solicitan y procesan los datos.

Sin embargo, la creación de una integración directa es probablemente la más difícil, sobre todo si está creando integraciones para fuentes de datos dispares. Cada fuente puede usar protocolos diferentes o incluso aprovechar protocolos similares de manera diferente. Una vez que haya creado la integración, seguirá siendo responsable de optimizar el rendimiento en lo que respecta al procesamiento de datos (sin mencionar las pruebas, la mitigación de la redundancia / conmutación por error, etc.). Además, debido a que las API de SaaS crecen y cambian constantemente, usted será responsable de actualizar y mantener la integración directa durante su vida útil.

La integración directa con una API ofrece ventajas en lo que respecta al control granular de la integración, pero el costo del mantenimiento de por vida puede superar esos beneficios.

SDK

PROSCONTRAS
Acceso a datos estrictamente limitadoFalta de modelo de datos compartidos
Integración simplificadaSoporte limitado de proveedores
Reutilización limitada entre fuentes de datos

Los SDK ofrecen una de las formas más rápidas de integrar datos de las aplicaciones cliente y las API gracias a las bibliotecas de desarrollador específicas de la tecnología. Con los SDK, a menudo obtiene un acoplamiento lógico entre el SDK y la API subyacente. Por ejemplo, una entidad de "documento" en el nivel de API probablemente estará representada por un objeto o estructura de "documento" en el nivel de SDK.

Si bien puede desarrollar rápidamente una integración con un SDK, puede encontrarse con problemas con una complejidad no deseada en su código. Y dado que los SDK son administrados y mantenidos por la comunidad o el proveedor de API y rara vez se ven similares en todas las fuentes de datos, hay pocas oportunidades para que transfiera el conocimiento adquirido al integrarse con una fuente en una integración con otra.

Además, el uso de un SDK abre la puerta al "infierno de la dependencia", donde su aplicación a menudo requiere actualizaciones, recompilaciones y redespliegue en función de los cambios en las definiciones del SDK.

Si es un desarrollador con la tarea de trabajar en un idioma o entorno específico, con una cantidad relativamente pequeña de fuentes de datos (o una mayor cantidad de fuentes con SDK similares), entonces usar un SDK puede ser la opción correcta. La pregunta que debe hacerse es si el acceso a los datos estrechamente ligado vale la pena el potencial de recompilación y redespliegue basado en un SDK actualizado.

Middleware de integración

PROSCONTRAS
Conectividad de datos abstractosAlto costo
Modelo de datos compartidosMayor complejidad
Dependencia de un proveedor
Mínimo control del revelador
Integraciones de fuentes de datos limitadas

Para muchas empresas, el middleware de integración, como un bus de servicio empresarial (ESB) o una solución de extracción, transformación y carga (ETL), se ha convertido en una pieza fundamental del back-office. Las soluciones ESB y ETL permiten la integración entre sistemas dispares y normalmente permiten a las empresas configurar y mantener su propia extracción y automatización de datos.

Desafortunadamente, estas soluciones tienden a ser grandes, complicadas y costosas. Y las soluciones ESB y ETL generalmente terminan trasladando la carga (y el control) de la integración lejos de usted como desarrollador a las manos de la TI corporativa. Una vez allí, la solución puede exigir tecnología e inversión monetaria para configurar, asegurar y mantener. Una vez que la solución de integración esté fuera de sus manos, es posible que descubra una capacidad limitada para manipular datos para satisfacer las necesidades de las aplicaciones que se le ha encomendado desarrollar e implementar.

Con el middleware de integración, a menudo verá los beneficios de un modelo de datos abstracto pero compartido, lo que alivia la carga de la integración dentro de la aplicación. Sin embargo, es posible que se encuentre luchando con una solución engorrosa con capacidades de integración limitadas que se encuentran fuera de su capacidad para configurar y mantener directamente.

Controladores basados ​​en estándares

PROSCONTRAS
Curva de aprendizaje bajaNo apto para operaciones basadas en eventos
Documentación mínimaCapa adicional de abstracción
API común
Aislamiento de cambios de API

Como desarrollador, siempre que integre datos de varias fuentes en su aplicación, a menudo querrá solicitar y agregar datos, recopilar puntos de datos relacionados o resumir datos de otro modo. Si bien la agregación de datos es posible a través de varias API y SDK, los controladores basados ​​en estándares le ofrecen la capacidad de trabajar con todos sus datos utilizando una única interfaz: SQL.

Con los controladores basados ​​en estándares, simplemente necesita conocer SQL y los marcos o bibliotecas necesarios para trabajar con bases de datos SQL en su idioma de elección para obtener datos dispares. Dado que los puntos finales y los recursos de la fuente de datos se pueden descubrir mediante consultas estándar para metadatos, podrá dedicar más tiempo a conectarse a los datos y menos a buscar en la documentación.

Existen otros beneficios para los controladores basados ​​en estándares que se encuentran fuera del alcance del desarrollo, pero que aún merecen mencionarse, incluida la conectividad más fácil (¡y sin código!) Para datos dispares de herramientas populares de BI, informes y ETL, además de los cambios y actualizaciones de API. (gracias a que los controladores están siendo desarrollados y mantenidos por un tercero) y un marcado aumento en la accesibilidad de la API.

Ventajas de los controladores SaaS

Los controladores basados ​​en estándares para software como servicio (y otras plataformas que no son de base de datos) otorgan beneficios clave sobre los SDK nativos u otros métodos comunes de consumo de API. Es probable que ya sepa cómo trabajar con datos de bases de datos en sus idiomas y entornos preferidos. Los pasos del procesamiento de datos, como abrir una conexión, enviar consultas, procesar resultados y cerrar la conexión, son triviales, lo que significa que con los controladores estándar, ya sabe cómo trabajar con todos sus datos.

Dado que los controladores se basan en estándares ubicuos, puede navegar y trabajar fácilmente con los datos de su aplicación SaaS en IDE. Con el controlador instalado, podrá trabajar en entornos como Eclipse, IntelliJ, Visual Studio y en productos populares como MS Excel y MS Access.

“Si bien HarperDB incorpora interfaces REST amigables para los desarrolladores para la integración de desarrolladores, era fundamental que nuestra plataforma ofreciera controladores basados ​​en estándares para extender nuestro acceso al mundo más amplio de BI, Analytics, Reporting e integración ETL”.
- Kyle Bernhardy, director de tecnología, HarberDB

El acceso SQL simple a todos sus datos proporciona ventajas cuantificables cuando se trata de tiempo dedicado a la integración con los datos. Una vez que considere operaciones complejas, como consultar una aplicación SaaS de comercio electrónico como Magento para generar una lista de sus clientes con mayores gastos en cada estado, las ventajas de SQL frente a los enlaces de idiomas nativos se vuelven aún más evidentes. Con SQL, puede realizar JOINs, GROUP BYs, SUMs para agregar sus datos, usar ORDER BY para ordenar y usar cláusulas WHERE para filtrar. Con los enlaces de idioma nativo, usted sería responsable de codificar la lógica, que se verá diferente para cada fuente de datos. Con SQL, obtiene la misma funcionalidad en prácticamente todas las fuentes de datos sin necesidad de replicar los datos en una base de datos.

Muchos controladores SaaS admiten el almacenamiento en caché, ya sea en memoria o en una base de datos común, lo que significa que obtiene un rendimiento optimizado para consultas repetidas (el controlador activará la API para la primera solicitud y luego irá al caché para solicitudes repetidas posteriores).

A medida que avanza en su pila de desarrollo, a menudo se encuentra pasando de un idioma a otro, todo dentro de una sola aplicación, lo que resalta aún más los obstáculos de usar API específicas del idioma. Con los controladores, sus datos tienen el mismo aspecto y se puede acceder a ellos mediante las mismas consultas, independientemente de si trabaja con ADO.NET, JDBC u ODBC.

¿Qué es la comida para llevar?

Al final, tomará la decisión de integración en función de sus propias necesidades y contexto. Para algunos desarrolladores, la integración directa de API o el uso de SDK tienen más sentido, gracias a las necesidades de datos sencillas, los entornos de desarrollo comunes y la necesidad de un control granular sobre la integración. Para otros, el uso de middleware de integración es la elección correcta, según su configuración de TI corporativa, back-end o su necesidad de recopilar o consolidar sus datos fuera del entorno de desarrollo.

Sin embargo, para muchos desarrolladores, los controladores estándar presentan una solución sólida para sus necesidades de integración de datos. Gracias a una interfaz uniforme entre las fuentes de datos y los entornos de desarrollo, los estándares ubicuos, la documentación autodescriptiva (a través del descubrimiento de metadatos) y el aislamiento de los cambios y actualizaciones de API, los desarrolladores pueden concentrarse en lo que hacen mejor, creando soluciones que impulsan el negocio.

Publicar un comentario

0 Comentarios