LITMIR.BIZ

      ■ wizualna i interakcyjna spójność między różnymi komponentami wymaga nietrywialnego wysiłku w celu zbudowania i utrzymania poszczególnych komponentów i zasad projektowania;

      ■ rozmiar (a tym samym czas ładowania) może być trudny w zarządzaniu podczas ładowania kodu JavaScript z wielu źródeł;

      ■ przeładowania i odświeżenia interfejsu mogą zmniejszać ogólną wydajność.

      ■ udostępnianie fragmentów UI jako komponentów webowych z przejrzystym interfejsem opartym na zdarzeniach;

      ■ integrowanie fragmentów przez zawieranie ich po stronie klienta;

      ■ używanie elementów iframe do udostępniania mikroaplikacji w oddzielnych sekcjach ekranu;

      ■ integrowanie komponentów w warstwie pamięci podręcznej za pomocą Edge Side Includes (ESI).

      ■ Indywidualnie mikroserwisy są wewnętrznie podobne do aplikacji monolitycznych.

      ■ Aplikacja mikroserwisowa jest jak sąsiedztwo – jej ostateczny kształt nie jest opisany, ale zamiast tego jest oparty na pewnych zasadach i modelu koncepcyjnym wysokiego poziomu.

      ■ Zasady określające architekturę mikroserwisową odzwierciedlają cele organizacyjne i informują o praktykach zespołu.

      ■ Plan architektoniczny powinien zachęcać do rozwoju w dobrym kierunku, a nie narzucać podejścia do całej aplikacji.

      ■ Aplikacja mikroserwisowa składa się z czterech warstw: platformy, usługi, granicy i klienta.

      ■ Warstwa platformy zapewnia narzędzia, elementy i infrastrukturę, aby wspierać rozwój mikroserwisów zorientowanych na produkt.

      ■ Komunikacja synchroniczna jest często pierwszym wyborem w aplikacji mikroserwisowej i najlepiej nadaje się do interakcji opartej na poleceniach, ale ma też wady i może zwiększać powiązanie i słabość.

      ■ Komunikacja asynchroniczna jest bardziej elastyczna i ułatwia szybką ewolucję systemu kosztem dodatkowej złożoności.

      ■ Typowe asynchroniczne wzorce komunikacyjne obejmują kolejki oraz publish-subscribe.

      ■ Warstwa granicy stanowi fasadę dla aplikacji mikroserwisowej odpowiednią dla zewnętrznych użytkowników.

      ■ Typowe rodzaje granic obejmują bramy API i bramy consumer-driven, takie jak GraphQL.

      ■ Aplikacje klienckie, takie jak strony internetowe i aplikacje mobilne, wchodzą w interakcję z backendem za pośrednictwem warstwy granicznej.

      ■ Isnieje ryzyko, że klienci mogą stać się monolitami, natomiast zaczynają powstawać techniki stosowania zasad mikroserwisowych w aplikacjach frontendowych.

      ■ określania zakresu mikroserwisów w oparciu na zdolnościach biznesowych i przypadkach użycia;

      ■ przypadków, w których należy określać zakres mikroserwisów, aby reprezentowały zdolności techniczne;

      ■ dokonywania wyborów projektowych, gdy granice usług są niejasne;

      ■ skutecznego określania zakresu, gdy mikroserwisy są w posiadaniu wielu zespołów.