Ventajas de usar servidores de IU y API separados para la aplicación web

14

En el trabajo, tenemos una gran aplicación interna que ha estado en desarrollo durante casi 2 años; Recientemente me uní al proyecto y parte de la arquitectura me ha dejado un poco perplejo, por lo que espero que alguien aquí pueda brindarme algunos consejos antes de salir a preguntarles a los arquitectos estas mismas preguntas (para poder tener una discusión informada con ellos). ).

Le pido disculpas si lo de abajo es un poco largo, solo quiero tratar de hacer una buena idea 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 otros servicios. Así que, básicamente, es un host para una aplicación AngularJS; hay literalmente un controlador MVC que arranca el lado del cliente, y luego todos los demás controladores son un controlador WebAPI.

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

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

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

  • Finalmente, estas WebAPI realizan otro conjunto de llamadas a los servicios "back-end", que suelen ser servicios legados asmx o wcf sobre varios sistemas ERP y almacenes de datos (sobre los cuales no tenemos control).

  • La mayor parte de la lógica comercial de nuestra aplicación se encuentra en estos WebApis, como la transformación de datos heredados, la agregación, la ejecución de reglas empresariales, el tipo habitual de cosas.

  

Lo que me ha confundido es el posible beneficio que existe al tener tal separación entre la Aplicación Web y las WebAPI que la sirven. Ya que nadie más los está usando, no veo ningún beneficio de escalabilidad (es decir, no tiene ningún sentido colocar otras 4 cajas 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, tiene que haber una proporción 1: 1 de servidor web a servidor api)

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

  • Por lo tanto, actualmente estoy tratando de presionar para que las WebAPI actuales pasen de soluciones separadas a proyectos separados dentro de la solución de aplicación web, con referencias de proyectos simples en medio y un solo modelo de implementación. Así que en última instancia, simplemente se convertirían en bibliotecas de clase.

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

Los beneficios que veo del nuevo enfoque son

  • Incremento en el 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 asignadores en los límites de entrada y salida de la aplicación web y los servidores de WebApi, respectivamente.
  • Mejor capacidad para crear pruebas de integración automatizadas significativas, porque simplemente puedo burlarme de los servicios de back-end y evitar el desorden en los saltos HTTP de nivel medio.
  

Entonces la pregunta es: ¿Me equivoco? ¿Me he perdido alguna "magia" fundamental de haber separado las cajas de Aplicación Web y WebAPI?

He investigado algunos materiales de arquitectura N-Tier pero parece que no puedo encontrar nada en ellos que pueda brindar un beneficio concreto para nuestra situación (ya que la escalabilidad no es un problema, por lo que puedo decir, y esto es un problema). La aplicación interna, por lo 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 para mi configuración propuesta?

    
pregunta Stephen Byrne 10.10.2015 - 00:07

2 respuestas

22

Una de las razones es la seguridad: si un hacker obtiene acceso a su servidor web front-end (jaja! cuando ), obtiene acceso a todo lo que tiene acceso. Si ha colocado su nivel intermedio 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 "seleccionar * de los usuarios" en su base de datos y lo quitó de la conexión. descifrado de contraseñas.

Otra razón es la escala: el nivel web en el que las páginas se construyen y manipulan y procesan XML, y todo eso requiere mucho más recursos que el nivel medio, que a menudo es un método eficiente para obtener datos de la base de datos 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 el 1. No debería haber una proporció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 caché que haya en ellos.

Los sitios web no se preocupan realmente por el rendimiento de un solo usuario, ya que están diseñados para escalar, no importa que haya una llamada adicional que reduzca un poco la velocidad 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 tener más disciplina en el desarrollo donde se desarrolla una API (y se prueba fácilmente ya que es independiente) y luego se desarrolla la interfaz de usuario para consumirla. Trabajé en un lugar que hizo esto: diferentes equipos desarrollaron diferentes capas y funcionó bien, ya que contaban con especialistas para cada nivel que podían realizar cambios muy rápidamente porque no tenían que preocuparse por los otros niveles, es decir, un dev de javscript de UI. podría agregar una nueva sección al sitio simplemente consumiendo un nuevo servicio web que otra persona haya desarrollado.

    
respondido por el gbjbaanb 10.10.2015 - 20:47
2

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

De la forma en que entiendo sus descripciones, el " WebAPI " en su Arquitectura sirve como un tipo de Middleware hecho por sí mismo. Ahora puedes investigar qué ventajas hay en los usos de un Middleware. Básicamente, su Webapp nunca tendría que ser adoptada si cambiara su sistema de backoffice (siempre y cuando la interfaz WebAPI se mantenga igual).

Para ir más lejos: imagine que tiene una base de datos de clientes (servicio backend) y tiene 5 aplicaciones web que se comunican con esa base de datos. Si reemplaza el sistema de la base de datos del cliente con un sistema nuevo (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á que cambiar la capa de comunicación de la WebAPI .

Básicamente, la arquitectura de capas actualmente se considera tanto como: Patrón como Anti-Patrón. (Ver: Lasagna-Code ) Si solo tiene 1 sistema sin planes de expandirlo más en los próximos años, preferiría considerarlo como antipatrón. Pero este woudl será un juez taff irrealista ya que no sé las circunstancias / situación exactas :)

    
respondido por el Stefan Woe 10.10.2015 - 19:55

Lea otras preguntas en las etiquetas