Monolith jest postrzegany jako klasyczna metoda developmentu. Sama idea oparcia architektury o jedną aplikację ma długą historię. Jest pozostałością czasów gdzie najczęściej jeden mocny komputer obsługiwał wielu klientów. Monolith możemy traktować jako rozwiązanie nierozproszone. Interfejs użytkownika, logika biznesowa, obsługa danych i aplikacje istnieją jako jedna całość. Monolith jest dużą, samodzielną strukturą, w której wszystko jest zbudowane liniowo. Daje to możliwość pełnej kontroli każdego aspektu i zadania jakie ma wykonać aplikacja.
Konsekwencją takiej budowy jest wzrost komplikacji systemu wraz ze wzrostem złożoności problemu oraz zwiększenie zapotrzebowania mocy obliczeniowych. W pewnym momencie system może stać się zbyt duży i nieporęczny.
Powstanie architektury Api-Client, zwanej również architekturą mikrousług lub mikroserwisów, było odpowiedzią na problemy architektury monolitycznej. Komunikacja API została stworzona w celu rozwiązania podstawowych problemów, głównie poprzez rozdzielenie zadań na pojedyncze mikrousługi. Mikrousługi lub mikroserwisy tworzone są jako osobny segment, jako część zbiorczej grupy usług. Mikrousługa może być samodzielna, ale zwykle działa jako jedna z wielu usług, które pozostają ze sobą w relacji i składają się na cały proces. Użytkownik, może korzystać z jednego interfejsu, tak jak w przypadku architektury monolitycznej, ale poszczególne wywołania będą kierowane do osobnych mikroserwisów, nie obciążając całej aplikacji. Dodatkową zaletą jest możliwość łatwej modyfikacji, dołączania, odłączania poszczególnych mikroserwisów bez ingerencji w całe środowisko aplikacji.
Interfejsy API są wykorzystywane do komunikacji, gdzie każda mikrousługa posiada swoją autonomię oraz reprezentuje zdefiniowany zakres z określoną funkcją.
kompleksowa kontrola nad każdym elementem aplikacji,
łatwe wdrożenie, pozwala na oszczędność czasu i kosztów,
łatwy rozwój (przy małych projektach),
dobrze sprawdza się w systemach o małym zakresie funkcjonalnym i prostym przepływie danych.
w przypadku dużych projektów, zarówno wdrażanie jak i rozwój znacznie się komplikują,
duże aplikacje potrzebują znacznie więcej zasobów i obciążają cały system,
jeden błąd może zaważyć na działaniu całego systemu lub większości jego funkcjonalności, a wykrycie go może być bardzo pracochłonne,
mała integrowalność z zewnętrznymi aplikacjami i systemami.
pozwala na izolowanie błędów, które w efekcie są łatwiejsze do wykrycia, a awaria nie wpływa na działanie całego systemu,
łatwość procesu kodowania każdej niezależnej usługi osobno,
elastyczność, którą osiąga dzięki możliwości swobodnego dodawania i modyfikowania kolejnych mikrousług,
dobrze sprawdza się w systemach nastawionych na dalszy rozwój
i częste zmiany,
swoboda wyboru technologii.
bardziej złożony system zależności między poszczególnymi usługami, który trzeba dobrze zrozumieć dla prawidłowego rozwoju aplikacji,
bardziej skomplikowany system aktualizacji całego systemu (np. wdrożenie nowej wersji języka programowania) ze względu na rozproszenie mikrousług.
Ciężko jednoznacznie stwierdzić czy architektura monolityczna jest lepsza od architektury Client-API. Każde z rozwiązań ma swoje zalety i jest zalecane przy określonych warunkach. Wybór zależy między innymi od celu, budżetu, czasu jaki mamy na tworzenie i wdrożenie systemu. Aplikacje monolityczne zdecydowanie lepiej sprawdzają się przy małych projektach o niewielkim budżecie. Architektura mikroserwisów natomiast przyniesie wiele korzyści przy rozbudowanych projektach o złożonej strukturze.