Beneficios de usar servidores API y UI separados para aplicaciones web

En el trabajo, tenemos una gran aplicación interna que ha estado en desarrollo durante casi 2 años; Me acabo de unir al proyecto recientemente y parte de la arquitectura me tiene un poco perplejo, así que espero que alguien aquí pueda dar algún consejo antes de salir a hacerles a los arquitectos estas mismas preguntas (para poder tener una discusión informada con ellos). )

Mis disculpas si el siguiente es un poco largo, solo quiero tratar de pintar una buena imagen de lo que es el sistema antes de hacer mi pregunta :)

• La forma en que se configura el sistema es que tenemos una aplicación web principal (asp.net, AngularJS) que en su mayoría solo agrega datos de varios otros servicios. Básicamente, es un host para una aplicación AngularJS; Hay literalmente un controlador MVC que arranca el lado del cliente, y luego cada otro controlador es un controlador WebAPI.

• Las llamadas desde el lado del cliente son manejadas por estos controladores, que siempre se implementan en cajas que no hacen más que alojar la aplicación web. Actualmente tenemos 4 de esas cajas.

• Sin embargo, las llamadas finalmente se enrutan a través de otro conjunto de aplicaciones WebAPI (por lo general, estas son por área comercial, como seguridad, datos de clientes, datos de productos, etc.). Todos estos WebAPI se implementan juntos en cajas dedicadas también; También tenemos 4 de estas cajas.

• Con una sola excepción, estas WebAPI no son utilizadas por ninguna otra parte de nuestra organización.

• Finalmente, estos WebAPI realizan otro conjunto de llamadas a los servicios "back-end", que son típicamente servicios asmx o wcf heredados que se superponen a varios sistemas ERP y almacenes de datos (sobre los cuales no tenemos control).

• La mayor parte de la lógica empresarial de nuestra aplicación se encuentra en estas aplicaciones web, como la transformación de datos heredados, sumarlos, ejecutar reglas comerciales, el tipo habitual de cosas.

Lo que me ha confundido es cuál es el posible beneficio de tener tal separación entre la Aplicación Web y las WebAPI que la sirven. Como nadie más los está usando, no veo ningún beneficio de escalabilidad (es decir, no tiene sentido poner otros 4 cuadros API para manejar una mayor carga, ya que una mayor carga en los servidores API debe significar que hay una mayor carga en los servidores web, por lo tanto, debe haber una relación 1: 1 de servidor web a servidor Api)

• Tampoco veo ningún beneficio en absoluto de tener que hacer una llamada HTTP adicional Browser => HTTP => WebApp => HTTP => WebAPI => HTTP => Servicios de backend. (esa llamada HTTP entre WebApp y WebAPI es mi problema)

• Por lo tanto, actualmente estoy buscando presionar para que las WebAPI actuales pasen de soluciones separadas a proyectos separados dentro de la solución WebApplication, con referencias simples de proyectos intermedios y un solo modelo de implementación. Entonces, en última instancia, se convertirían en bibliotecas de clases.

• En cuanto a la implementación, esto significa que tendríamos 8 cuadros web de "pila completa", en lugar de 4 + 4.

Los beneficios que veo del nuevo enfoque son

• Aumento del rendimiento porque hay un ciclo menos de serialización / deserialización entre la aplicación web y los servidores WebAPI
• Toneladas de código que se pueden eliminar (es decir, no es necesario mantener / probar) en términos de DTO y mapeadores en los límites salientes y entrantes de los servidores de aplicaciones web y WebApi respectivamente.
• Mejor capacidad para crear pruebas de integración automatizadas significativas, porque simplemente puedo burlarme de los servicios de fondo y evitar el desorden en torno a los saltos HTTP de nivel medio.

Entonces la pregunta es: ¿estoy equivocado? ¿Me he perdido alguna "magia" fundamental de haber separado los cuadros de WebApplication y WebAPI?

He investigado algunos materiales de arquitectura de N-Tier, pero parece que no puedo encontrar nada en ellos que pueda dar un beneficio concreto para nuestra situación (ya que la escalabilidad no es un problema, por lo que puedo ver, y esta es una aplicación interna, así que la seguridad en términos de las aplicaciones WebAPI no es un problema).

Y también, ¿qué estaría perdiendo en términos de beneficios si tuviera que reorganizar el sistema a mi configuración propuesta?

Una de las razones es la seguridad - if (! Jaja cuando ) un hacker obtiene acceso a su servidor web front-end, que tiene acceso a todo lo que se tiene acceso. Si ha colocado su nivel medio en el servidor web, entonces él tiene acceso a todo lo que tiene, es decir, su base de datos, y lo siguiente que sabe es que simplemente ejecuta "select * from users" en su base de datos y se lo quitó fuera de línea descifrado de contraseñas

Otra razón es el escalado: el nivel web donde las páginas se construyen y destruyen y se procesan XML, y todo eso requiere muchos más recursos que el nivel medio, que a menudo es un método eficiente para llevar datos desde el DB al nivel web. Sin mencionar la transferencia de todos los datos estáticos que residen (o se almacenan en caché) en el servidor web. Agregar más servidores web es una tarea simple una vez que haya pasado 1. No debería haber una relación 1: 1 entre los niveles web y lógico: he visto 8: 1 antes (y una relación 4: 1 entre lógica nivel y DB). Sin embargo, depende de lo que hagan sus niveles y de la cantidad de almacenamiento en caché.

Los sitios web realmente no se preocupan por el rendimiento de un solo usuario, ya que están diseñados para escalar, no importa que haya una llamada adicional que desacelere un poco las cosas si eso significa que puede atender a más usuarios.

Otra razón por la que puede ser bueno tener estas capas es que obliga a una mayor disciplina en el desarrollo donde se desarrolla una API (y se prueba fácilmente ya que es independiente) y luego la IU se desarrolló para consumirla. Trabajé en un lugar que hizo esto: diferentes equipos desarrollaron diferentes capas y funcionó bien, ya que tenían especialistas para cada nivel que podían producir cambios muy rápidamente porque no tenían que preocuparse por los otros niveles, es decir, un desarrollador de UI javscript podría agregar una nueva sección al sitio simplemente consumiendo un nuevo servicio web que otra persona haya desarrollado.

Creo que no hay una respuesta correcta / incorrecta aquí. ¿Has preguntado a tus colegas sobre el propósito de esta arquitectura?

Por cómo entiendo sus descripciones, el " WebAPI " en su Arquitectura sirve como una clase de Middleware hecho a sí mismo. Ahora puede investigar qué ventajas hay en el uso de un Middleware. Básicamente, su Webapp nunca necesitaría ser adoptada si cambiara su sistema de backoffice (siempre y cuando la interfaz de WebAPI se mantenga igual).

Para ir más allá: imagine que tiene una base de datos de clientes (servicio de fondo) y tiene 5 aplicaciones web que se comunican con esa base de datos. Si reemplaza el sistema de base de datos del cliente con un nuevo sistema (como el de otro proveedor y no puede influir en las interfaces del servicio web), lo más probable es que necesite cambiar la capa de comunicación de las 5 aplicaciones web. Si se comunica a través de su WebAPI , solo tendría que cambiar la capa de comunicación de WebAPI .

Básicamente, la arquitectura de capa se considera hoy en día como tanto: Patrón como Anti-Patrón. (Ver: Código de lasaña ) Si solo tiene 1 sistema sin planes para expandir esto en los próximos años, preferiría considerar esto como un antipatrón. Pero esto sería un juez poco realista, ya que no sé las circunstancias / situación exactas :)