W pracy mamy dużą aplikację wewnętrzną, która jest rozwijana od prawie 2 lat; Niedawno dołączyłem do projektu i trochę architektury mnie nieco zakłopotało, więc mam nadzieję, że ktoś tu udzieli porady, zanim pójdę zadać architektom te same pytania (dzięki czemu mogę z nimi przeprowadzić świadomą dyskusję) ).
Przepraszam, jeśli poniżej jest trochę za długo, po prostu chcę namalować dobry obraz tego, czym jest system, zanim zadam moje pytanie :)
System jest skonfigurowany w taki sposób, że mamy jedną główną aplikację internetową (asp.net, AngularJS), która głównie gromadzi dane z różnych innych usług. Zasadniczo jest to host aplikacji AngularJS; istnieje dosłownie jeden kontroler MVC, który ładuje się po stronie klienta, a następnie każdy inny kontroler jest kontrolerem WebAPI.
Połączenia ze strony klienta są obsługiwane przez te kontrolery, które są zawsze wdrażane w skrzynkach, które nie wykonują nic poza hostowaniem aplikacji sieci Web. Obecnie mamy 4 takie skrzynki.
Jednak połączenia są następnie przekierowywane do jeszcze jednego zestawu aplikacji WebAPI (zazwyczaj są to obszary biznesowe, takie jak bezpieczeństwo, dane klientów, dane produktów itp.). Wszystkie te WebAPI są również wdrażane razem w dedykowanych urządzeniach; mamy również 4 z tych pól.
Z jednym wyjątkiem te interfejsy WebAPI nie są używane przez żadne inne części naszej organizacji.
Wreszcie te WebAPI wykonują kolejny zestaw wywołań do usług „zaplecza”, które są zwykle starszymi usługami asmx lub wcf umieszczanymi na różnych systemach ERP i magazynach danych (nad którymi nie mamy kontroli).
Większość logiki biznesowej naszej aplikacji znajduje się w tych WebApis, takich jak przekształcanie starszych danych, agregowanie ich, wykonywanie reguł biznesowych, zwykły rodzaj rzeczy.
To, co mnie pomyliło, to jaka jest potencjalna korzyść z takiego oddzielenia aplikacji sieci Web od obsługujących ją interfejsów WebAPI. Ponieważ nikt inny ich nie używa, nie widzę żadnej korzyści ze skalowalności (tj. Nie ma sensu umieszczać kolejnych 4 skrzynek API do obsługi zwiększonego obciążenia, ponieważ zwiększone obciążenie serwerów API musi oznaczać zwiększone obciążenie serwerów WWW - dlatego musi istnieć stosunek 1: 1 serwera WWW do serwera Api)
Nie widzę też żadnej korzyści z konieczności wykonywania dodatkowego połączenia HTTP. Przeglądarka => HTTP => WebApp => HTTP => WebAPI => HTTP => Usługi zaplecza. (moim problemem jest połączenie HTTP między WebApp a WebAPI)
Tak więc obecnie staram się przenieść obecne interfejsy WebAPI z oddzielnych rozwiązań, do oddzielnych projektów w ramach rozwiązania WebApplication, z prostymi odniesieniami do projektów pomiędzy nimi i jednym modelem wdrażania. Więc ostatecznie staną się bibliotekami klas.
Jeśli chodzi o wdrażanie, oznacza to, że mielibyśmy 8 „pełnych stosów” skrzynek internetowych, w przeciwieństwie do 4 + 4.
Korzyści, jakie widzę z nowego podejścia, to
- Wzrost wydajności, ponieważ istnieje jeden mniejszy cykl serializacji / deserializacji między aplikacją sieci Web a serwerami WebAPI
- Mnóstwo kodu, który można usunąć (tj. Nie trzeba utrzymywać / testować) pod względem DTO i maperów na wychodzących i przychodzących granicach odpowiednio aplikacji sieci Web i serwerów WebApi.
- Lepsza zdolność do tworzenia znaczących automatycznych testów integracji, ponieważ mogę po prostu kpić z usług zaplecza i unikać bałaganu wokół skoków HTTP w środkowej warstwie.
Pytanie brzmi: czy się mylę? Czy przegapiłem podstawową „magię” oddzielenia skrzynek WebApplication i WebAPI?
Przeszukałem niektóre materiały architektury N-Tier, ale nie mogę znaleźć w nich niczego, co mogłoby dać konkretną korzyść dla naszej sytuacji (ponieważ skalowalność nie jest problemem, o ile wiem, a jest to aplikacja wewnętrzna, więc bezpieczeństwo w zakresie aplikacji WebAPI nie stanowi problemu).
A także, co straciłbym pod względem korzyści, gdybym przeorganizował system do proponowanej konfiguracji?