Na bazie dyskusji z zespołami u mnie w projekcie doszło do dyskusji jak porozdzielać odpowiedzialności dla prostej strony, będącej częścią dużego serwisu. Strona (OPA) ma robić dwie, niezbyt skomplikowane rzeczy i pojawiło się w dyskusji trochę możliwości:
- Podejście podręcznikowe na pełnej mocy:
Stawiamy sobie za głównym API gatewayem następujące serwisy:
- fasadę (gateway) z zadaniem grupowania endpointów wykorzystywanych przez aplikację webową
- uS dla funkcjonalności A - prosta zmiana w bazie danych
- uS dla funkcjonalności B - przyjęcie tego pliku na klatę i orkiestracja działania innych serwisów (już istniejących)
- na istniejącym już serwerze www publikujemy endpoint (raczej nie ma sensu stawiać osobnych serwisów do serwowania statycznych plików)
- Podejście "konformistyczne":
- stawiamy serwis, który zawierać będzie w sobie całą logikę opisaną w podejściu wyżej
- Na istniejącym API gateway'u dodajemy trochę przekierowań
Argumenty padające za pierwszym rozwiązaniem, to wiadomo - jasny podział odpowiedzialności, jak wchodzimy w mikroserwisy, to na całość itp.
Argumenty za drugim podejściem, to "za dużo repozytoriów gubimy się", "więcej serwisów, to więcej zasobów (wszystko chodzi w k8s, więc trochę moim zdaniem na wyrost)
I pytanie - które z powyższych podejść jest lepsze w dużym projekcie, wszystko publikowane w chmurze, łącznie kilkadziesiąt osób zaangażowanych w zabawę (bezpośrednio w tę część 5 ludzi). Zależy mi na praktycznym podejściu, jak jest w książkach wiem.