Duda de arquitectura/diseño

B

Hola a todos, acudo a vuestra sabiduría para que me digáis la mejor forma de montar esto.

Hicimos un proyecto que conecta dos aplicaciones con diferentes bases de datos, una hace llamadas a la API de la otra para integrar los datos entre ambos sistemas. Al principio iba a ser algo muy sencillo para un solo cliente pero se ha convertido en un proyecto estratégico que ya tienen varios clientes y algunos con una versión antigua de la aplicación en la que no es posible traspasar la lógica.

Mi jefe me ha preguntado si podemos hacerlo de tal forma que desde una aplicación que construyamos desde 0 podamos comunicar las dos plataformas, teniendo en cuenta además que debería ser multicliente y que cada uno requiere de personalizaciones para adaptar a su negocio.

¿Cómo se hace esto en el mundo real?

Yo había pensado en montar algo intermedio que haga de puente entre las dos, pero no sé ni qué tecnología ni cuál sería la forma correcta de hacerlo.

Se agradecen consejos, me interesa llevarlo a cabo para aprender tecnología actual de paso que hago lo que me piden.

Un saludo.

Leos

#1 Creo que lo que buscas es un api gateway

1 1 respuesta
B

.

1 respuesta
JuAn4k4

#3 Creo que el concepto que buscas es ETL (extract, transform, load)

El problema de versionado es gordote, en stripe lp solucionaron con Upcast/Downcast de los datos mediante capas (v1 -> v2 -> ... -> vN) Es decir, Código que mapea de una versión a la siguiente. Y tu app solo trabaja con latest.

Pero claro, aquí hablas de datos, por lo que no paras en latest sino en la vX que sea y tendrás que tener una fosa de guardar cada una de las versiones en el store. Muerte.

1
1 mes después
modena

Aquí tienes varias posibilidades:

  • Como te han comentado por encima, un API Manager seria un gateway que decidiera a que backend ir. Podrías tener diferentes versiones de la misma api (con diferentes métodos, campos, etc) y cada uno obtendría los datos que necesitaras. A traves de routing-rules, puedes hacer que al identificarse cada cliente en este gateway, redirijas a uno u otro backend sin necesidad de que la URL de invocación cambie para el cliente.
  • Utilizar el patrón Backend For Frontend (BFF). Digamos que son aplicaciones construidas para cada uno de los canales invocantes y que de esta forma el backend core sería el mismo, pero en cada BFF agruparías o devolverías la información como la necesitase cada cliente (o incluso realizar llamadas adicionales que puede requerir un cliente y otro no, de esta forma solo modificarías los necesarios). Esto te permite desacoplar los clientes del core, pero en contraposición, debes mantener tantos BFFs como clientes (o tantos como clientes "iguales").

En arquitecturas "reales" como comentas, normalmente se suelen utilizar la unión de las 2 opciones, una para desacoplar el core (BFF), y otra para temas de autenticación y scopes de ejecuciones y redirecciones a versiones de APIs diferentes sin que el cliente "se entere" si hay cambios. (gateway).

Mi recomendación es que si preveeis que esa arquitectura crezca, montarlo bien desde un inicio para que a futuro sea escalable o puede penalizaros a medio plazo.

2

Usuarios habituales