Wymuszanie wspólnych bibliotek w mikroserwisach

Był monolit, są mikroserwisy. Architekci wymyślili sobie, by stworzyć wewnętrzny framework, który będzie zawierał libki konfigurujące wiele rzeczy jak connectory do kafki, klient http, dependencies, logowanie po to żeby była 1 wspólna konfiguracja dla wszystkich mikroserwisów. DRY.

Programiści nie chcą używać tego frameworka, bo jest napisany dziwnie np. klient http jest udekorowanym RestTemplate ,który zapodać możesz do klasy tylko przez beana, bo:

FrameworkClient implements HttpClient {

  @Autowired
  private RestTemplate restTemplate;

  FrameworkClient() {

  }

  // nawet brak setterów
}

Jednocześnie we frameworku jest zdefiniowany primary bean resttemplate:

@Bean
@Primary
RestTemplate restTemplate() {
...
}

inny z przykładów dziwności to konfiguracja kafki:

KafkaConsumerConfig extends KafkaProducerConfig {
...
}

1. Architekt: używajcie naszego frameworka do http
   Programista: ale używamy już FeignClienta
   Architekt: a uzgodnił ktoś z nami, że go używacie? Musicie go zastąpić

2. Programista: leci mi błąd jak próbuję użyć tego klienta client.call(...) jakiś NPE, potrzebuję coś dokonfigurować? wiesz o co chodzi?
   Architekt: nie, nikt nie zgłaszał. To zanurkuj tam i obczaj o co chodzi.

3. W międzyczasie programista2 z innego zespołu trafił na ten sam błąd i pewnie też stracił czas na rozkminiane tego. Ostatecznie nic nikomu nie powiedział, zamknął taska pisząc FRAMEWORK RZUCA NPE TO NIE BEDE GO UZYWAŁ

4. Programista przeanalizował NPE, znalazł linię kodu, gdzie leci ten NPE i wyczaił, że błąd pojawia się, gdy client.call(...) jest użyty poza contextem RestControllera (nie jest w następstwie odpowiedzi endpointa, nie wiem ja kto nazwać). Programista odnalazł zespół za to odpowiedzialny i zgłosił im ten błąd.
   Twórca: zobacz sobie jak to jest użyte w tym i tym microserwisie, u mnie działa
   Programista: tam nie ma tego przykładu, zobacz.
   Programista napisał nawet im propozycję poprawki.
   Programista: moja propozycja, teraz działa. Poprawcie to albo wywalajcie UnsupportedOperationException z informatywnym msg
   Twórca: zgłoś buga.

5. Po miesiącu.
   Twórca: a serio potrzebujesz wołać tego clienta poza contextem? To podaj przykład, gdzie tego potrzebujesz.
   Programista: tu i tu.
   Twórca: no to nie rób tak tylko użyj naszego frameworka i wtedy masz to w contextcie. Nie naprawiamy.

6. Manager nietechniczny podchwycił temat i zrobił gównoburze, że tamci nie chcą naprawić błędu i że w ogóle ich biblioteka to syf i wszyscy na to narzekają.

7. Twórca na to, że tu nie ma żadnego błędu tylko programista nie czai co do niego się mówi i że dostał info jak tego używać.

Co o tym sądzicie i co należałoby zrobić?

że czas odświeżyć CV

programista-z-cyrku napisał(a):

Był monolit, są mikroserwisy. (...)

Nie nazwałbym tego, co opisałeś, mikroserwisami. Bardziej "rozproszonym monolitem".

by stworzyć wewnętrzny framework, który będzie zawierał libki konfigurujące wiele rzeczy

W teorii brzmi dobrze, w praktyce u was jak sam piszesz się to nie sprawdza, skoro programiści zamiast niezależnie pracować nad swoją częścią, to muszą nurkować we framework:

1. Programista: leci mi błąd jak próbuję użyć tego klienta client.call(...) jakiś NPE, potrzebuję coś dokonfigurować? wiesz o co chodzi?
   Architekt: nie, nikt nie zgłaszał. To zanurkuj tam i obczaj o co chodzi.

oraz tracony jest czas na bikeshedding i komunikację z innym zespołem:

1. Programista przeanalizował NPE, znalazł linię kodu (...) odnalazł zespół za to odpowiedzialny i zgłosił im ten błąd.
   Twórca: zobacz sobie jak to jest użyte w tym i tym microserwisie, u mnie działa
   Programista: tam nie ma tego przykładu, zobacz.
   Programista napisał nawet im propozycję poprawki.
   Programista: moja propozycja, teraz działa. Poprawcie to albo wywalajcie UnsupportedOperationException z informatywnym msg
   Twórca: zgłoś buga.

Co o tym sądzicie i co należałoby zrobić?

Jeżeli chcesz zostać w tej firmie, to chyba dobrym posunięciem byłaby zmiana zespołu i dołączenie do "klasowych łobuzów", czyli do tych architektów, którzy robią sobie ten framework, którym mogą gnębić później innych i pokazywać dominację. if you can't beat them, join them.

Albo zmiana firmy.

programista-z-cyrku napisał(a):

inny z przykładów dziwności to konfiguracja kafki:

Kopiuj

KafkaConsumerConfig extends KafkaProducerConfig {
...
}

Problem jest taki, że to ma sens ;)
Kiedyś sam pisałem pewne API, które służyło do szybkiego tworzenia pewnego rodzaju kodu i zauważyłem, że konfiguracja kafkowego producenta duplikuje część pól z kafkowego konsumenta.
Co prawda ja koniec końców postawiłem (i tak te klasy były wewnętrzne) na stare Properties, ale pokusa by zrobić coś takiego była.

Wracając do tematu - tworzenie bibliotek to ciężka robota, błędy będą. Z tego co piszesz biblioteka perfekcyjna nie jest, no i brakuje w niej dokumentacji. Zdarza się dużo częściej niż powinno, czasem trzeba z tym żyć. Natomiast to, co mnie uderza to naprawdę tępy vendor-locking - wymuszenie korzystania ze Springa. Ba, wymuszanie korzystania z field injection - jeśli ktoś sobie to wyłączy żeby nikogo w zespole nie kusiło wstrzykiwać inaczej niż przez konstruktor to framework jest martwy.

Ja pewnie zacząłbym się kłócić z panami architektami o to bo klient http, którego nie da się stworzyć poza kontekstem springowym jest dla mnie nieporozumieniem. Ewentualnie zrobił to, co zrobił programista nr. 2.

wartek01 napisał(a):

Ja pewnie zacząłbym się kłócić z panami architektami o to bo klient http, którego nie da się stworzyć poza kontekstem springowym jest dla mnie nieporozumieniem.

+1
Patologia.
O ile kod aplikacyjny od kontekstu S zależy, nie ma rady, to libki tak robione to patologia.

(ale w patrzeniu przenikniętym rozproszonym monolitem nie w tym nic nagannego)

Klasyka. Architekci tworzą swojego liba, bo jest to fajne. Niestety tworzenie libów jest ciężkie. W takich sytuacjach bardzo przydaje się monorepo (bo każdy może zrobić zmianę na szybko, nie trzeba wersjonować) i ogarnięty team (który chce robić takie liby sam z siebie a nie, bo muszą).

Tak czy owak brzmi to jak patologia. Zewnętrzna biblioteka, która wymaga stanu globalnego (w typ przypadku Autowired) to zło i normalnie nikt takiego gówna by nie użył

Też potwierdzam, że klasyka.
Spring to patologia, ale firmowe frameworki oparte o springa, lub zauroczenie springiem (inner platform effect) to patologia do potęgi.
Pocieszające jest to, że zwykle da się to ignorować, po prostu nie pytasz tylko robisz swoje. A w międzyczasie warto powoli przygotować ewakuację.

Kiedyś moja firma dostała zlecenie, zrobienie jakiegoś tam serwisu w jednym banku i trafiłem tam, bo zespół (z mojej firmy) nie mógł sobie poradzić właśnie z takim frameworkiem. Wyszło, że po prostu nie może działać (powody classloaderowe - typowe dla patologicznych technologii - tu akurat JavaEE - czyli spring tylko jeszcze bardziej springowy - wszystko na adnotacjach ). Ale architekci z banku uparli się, że niemożliwe, że nie może, bo to ich standardowy framework - kazali nam sprawdzić jak to jest, że innym zespołom w banku działa. Więc dzwoniłem do tych zespołów - kilku, do których dostałem kontakt - wyszło, że wszystkie te bankowe zespoły totalnie olały standardowy bankowy framework :-)

@slsy

Niestety tworzenie libów jest ciężkie.

uh? no fakt, tworzenie libów może być cięższe, bo złamanie kompatybilności ssie, ale takie problemy raczej nie są aż tak bolesne gdy jest to wewnętrzna libka, a nie np. publiczna libka mająca 10 000 aktywnych userów.

a zatem czym się różni pisanie liba od pisania zwykłego kodu?

no w teorii nie powinno niczym - w obu przypadkach chcesz zaprojektować dobre API, sensownie rozwiązać dany problem, uczynić ten subsystem modularnym, dobrze zamodelować itd itd., ale to trzeba chcieć :)

więc skąd ta różnica?

Strasznie mnie bawi to jak powszechne jest zjawisko degradacji pomysłów w IT. Jak rozważam różne pomysły, metodologie, wzorce, etc. to praktycznie w każdym widzę podobny schemat, tzn:

• Pojawia się jakiś ogarniacz w danym temacie
• Ogarniacz wymyśla jakiś proces, metodologię, rozwiązanie, o nazwie X.
• Rozwiązanie jest bardzo dobre, i staje się popularne
• Coraz więcej osób słyszy o rozwiązaniu
• Dochodzi do momentu w którym spora cześć ludzi słyszała o rozwiązaniu, ale mało kto je rozumie
• Powstają karykatury rozwiązania, które noszą tą samą nazwę, ale nie mają nic wspólnego z orginalnym pomysłem.

Tak się stało z MVC, Agile, XP, TDD, Open/Close, OOP, MVVM. Dochodzi do momentu że są "programiści" którzy myślą że jak dodają kilka testów do projektu to to jest TDD. I tak również jest z mikroserwisami.

Nie wiem czy wiecie, ale pomysł z mikroserwisami jest stary jak najstarsza sekwoja; i w tym pomyśle chodziło o to, że cała aplikacja składała się z (naprawdę) mikro-serwisów. Nie chodzi tutaj o małe, malutkie serwiski, tylko na prawdę mikro serwisy, takie które można było wyrazić jednym lub kilkoma plikami. Po co one były, zapytacie, ano idea była taka, żeby nie modyfikować kodu mikroserwisów. Że jak zmienią się wymagania, to nie modyfikuje się kodu w ogóle, tylko najzwyczajniej się się usuwa cały mikroserwis do kosza i pisze się nowy. To była idea za mikroserwisami, że napisanie nowego serwisu jest prostsze, lepsze i mniej problematyczne niż babranie się z dopasowaniem go do zmian. I to miało dużo zalet w odpowiednim środowisku. Teraz popularne "mikroserwisy" nie mają z tym praktycznie nic wspólnego, oprócz przetwarzania rozproszonego, właściwie, i niezależne deploy'owania (czasami), bo często są wprowadzane breaking change'a, takie że i tak musisz zdeployować dwie na raz. Kolejną zaletą takich mikroserwisów było też właśnie niezależność od bibliotek, bo jak tylko się pojawiła jakaś zmiana, był potrzebny jakiś update, to się właśnie wyrzucało cały serwis do kosza, i pisało nowy z nową/inną biblioteką.

Teraz to szkoda gadać.

Odpowiadając na pytanie OP: Uważam że wymuszanie tych samych bibliotek (albo na dobrą sprawę tych samych języków programowania) w różnych mikroserwisach to słaby pomysł.

@Riddle:

Odpowiadając na pytanie OP: Uważam że wymuszanie tych samych bibliotek (albo na dobrą sprawę tych samych języków programowania) w różnych mikroserwisach to słaby pomysł.

tak, nie, zależy.

to że MS umożliwiają ci klepanie w 5 językach, to wcale nie oznacza że jest to pożądane

to że są jakieś tam libki od czegoś i każdy MS ich używa, to też jeszcze samo w sobie nic złego nie mówi

tylko na prawdę mikro serwisy, takie które można było wyrazić jednym lub kilkoma plikami. Po co one były, zapytacie, ano idea była taka, żeby nie modyfikować kodu mikroserwisów. Że jak zmienią się wymagania, to nie modyfikuje się kodu w ogóle, tylko najzwyczajniej się się usuwa cały mikroserwis do kosza i pisze się nowy. To była idea za mikroserwisami, że napisanie nowego serwisu jest prostsze, lepsze i mniej problematyczne niż babranie się z dopasowaniem go do zmian. I

@Riddle: a to ciekawe, masz jakieś uzasadnienie tych swoich rewelacji czy to jakies kolejne tezy w które wierzysz tylko ty? (Podobnie jak to że obiekty w OOP powinny być niemutowalne itp)

A używanie wspólnych bibliotek może mieć sens (np. jakiś commons z typami typu Pesel + jakąs walidacją itp), ale takie coś jak u OP to na pewno nie ma sensu...

scibi_92 napisał(a):

A używanie wspólnych bibliotek może mieć sens (np. jakiś commons z typami typu Pesel + jakąs walidacją itp), ale takie coś to na pewno nie ma sensu...

Żaden commons biznesowy w microserwisach nie ma sensu, bo jakakolwiek wspólna dzielona odpowiedzialność, powinna być albo A. tylko w jednym z microserwisów, i nie powinna być współdzielona; albo B. jeśli musi być współdzielona to powinna być wydzielona do osobnego microserwisu z którego korzystają pozostałe.

Więc nie ma sensu współdzielić commonsów z biznesowymi odpowiedzialnościami jak Pesel, walidacja, etc.

@Riddle: rozumiem że Guavy albo Apache Commonsów tez byś nie wykorzystywał?

@Riddle

Załóżmy że masz 2 MS, gdzie jeden odpowiada za przyjmowanie danych, a z drugi za wyrzucanie. W obu jest trochę logiki biznesowej.

Dane przychodzą i wychodzą w formacie dupaJsonCSV i zazwyczaj jest ich tak po 10GB na wejściu i podobnie na wyjściu

I mamy do tego firmową, proprietary libke dupaJsonCSVCompanyLib

I czy dobrze rozumiem - stosując twoje podejście tworzymy trzeci MS który będzie miał jedynie zależność od dupaJsonCSVCompanyLib, a pozostałe dwa MS będą uderzać do niego aby przeparsować dane lub je serializować?

scibi_92 napisał(a):

@Riddle: rozumiem że Guavy albo Apache Commonsów tez byś nie wykorzystywał?

Ale rzeczy nie-biznesowe, jak Guavy i Commonsy, możesz dodawać oczywiście do microserwisów; tylko takich rzeczy również nie ma sensu współdzielić. Tzn możesz mieć commonsy w jednych, guave w drugich, jacksona w trzecich, gsona w czwartych etc.

Czyli:

• biznesowe commonsy - nie warto wymuszać "wspólnych", bo jakiekolwiek wspólne powinny być wydzielone do osobnych serwisów (myśląc racjonalnie - jaki sens jest mieć microserwisy jak i tak mają zależności na sobie w postaci tych wspólnych bibliotek. Cały sens microserwisów idzie do kosza)
• techniczne commonsy - nie warto wymuszać "wspólnych", bo różne mikroserwisy powinny móc same decydować o tym jak rozwiązują implementacyjne problemy, np jakiego StringUtils używają.

@Riddle: czy suma kontrolna (czy jak to się nazywa) Peselu ma jeden ustalony algorytm? Bo z tego co wiem to tak, więc czym może się różnić sprawdzenie czy suma kontrolna dla peselu jest poprawna między różnymi serwisami, oraz dlaczego żeby to zrobić nalezy wysłać request HTTP?

scibi_92 napisał(a):

@Riddle: czy suma kontrolna (czy jak to się nazywa) Peselu ma jeden ustalony algorytm? Bo z tego co wiem to tak, więc czym może się różnić sprawdzenie czy suma kontrolna dla peselu jest poprawna między różnymi serwisami, oraz dlaczego żeby to zrobić nalezy wysłać request HTTP?

Poruszasz dwie kwestie, więc odpowiem na nie osobno.

• czy suma kontrolna (czy jak to się nazywa) Peselu ma jeden ustalony algorytm? Bo z tego co wiem to tak, więc czym może się różnić sprawdzenie czy suma kontrolna dla peselu jest poprawna między różnymi serwisami Jeśli algorytm w istocie jest taki sam, to nie powinno mieć znaczenia jakiej biblioteki użyjesz do jej sprawdzenia, a powinieneś móc mieć możliwość żonglować sobie implementacjami jak chcesz, możesz nawet napisać takie coś samemu i nie powinno być z tym problemu. Więc odpowiadając na pytanie OP; nie ma potrzeby wymuszania czegokolwiek.
• oraz dlaczego żeby to zrobić nalezy wysłać request HTTP? jeśli zadajesz pytanie o zasadność żądań HTTP pomiędzy microserwisami, to tak na prawdę zadajesz pytanie o zasadność istnienia microserwisów. Pytanie w ogóle nie powinno brzmieć "czy to jest tak ważny element żeby zrobić request". Nie powinno brzmieć w ogóle "Jaka ilość skomplikowania logiki jest warta dodatkowego requestu". Pytanie powinno brzmieć tylko i wyłącznie: "Czy chce mieć różne elementy aplikacji oddzielone od siebie?" Jeśli tak, to dzielisz je na moduły albo microserwisy i każda konieczna komunikacja leci po HTTP; jeśli nie, to nie dzielisz ich na mikroserwisy i nie masz problemu z żadaniami.

Bo zobacz, niby dzielisz aplikacje na pod-aplikacje, żeby je odseparować od siebie. Ale potem dodajesz w inny sposób, zależności między nimi. Po co? Albo je rozdzielasz (i wtedy je rozdzielasz już całkiem), albo ich nie rozdzielasz i masz jedną aplikację. Co nie znaczy wcale że to musi być monolit, możesz mieć aplikacje jedną, ale rozsądnie podzieloną na moduły. Jeśli nie, to wtedy masz tylko sztukę, dla sztuki (tzn. "microserwis dla microserwisu"), dzielisz je, ale nie czerpiesz korzyści z rozdzielenia ich.

To jest swoją drogą kolejny przykład degradacji jakiegoś pomysłu. Teraz w "popkulturze" programistycznej się przyjęło, że każda, dowolna aplikacja która nie jest microserwisem, musi kategorycznie być monolitem.

Więc odpowiadając na pytanie OP; nie ma potrzeby wymuszania czegokolwiek.

Tylko ja nie pisałem nic o wymuszaniu korzystania z biblioteki, tylko o tym że te biblioteki mają sens.

Nie chcę krytykować decyzji kolegów nie znając powodów dla jakich podjęli takie, a nie inne decyzje. Jeżeli jednak nie wiesz dlaczego masz tak robić, to ktoś gdzieś dał ciała, bo skoro był powód, to powinien być znany każdemu programiście, który tego dotyka. Ogólnie rzecz biorąc, o ile rozumiem np. chęć jako-takiego ujednolicenia tech-stacku, bo to, że każdy uS może być napisany w innym języku, korzystać z innej bazy danych, kontenera z innym systemem itd. nie znaczy jeszcze, że warto. Natomiast wszystkie pomysły "zróbmy sobie framework" z jakimi się spotkałem były kompletnie z czapy. Zwykle kończyło się to tym, że takie framework faktycznie był wszędzie, w każdym miejscu w innej wersji, na szybko przerobionej pod konkretny serwis/aplikację.
Ogólnie uważam, że architekt powinien trzymać pewien dystans od tego poziomu decyzji. Jak jest jakiś zespół, który zna się na tym co robi, to dlaczego mam się z nimi kłócić o to jak zrobią to za co odpowiadają? Nie znaczy to, że nie uczestniczę w takich dyskusjach, staram się służyć swoją wiedzą i doświadczeniem, ale przecież jak komuś narzucę, że ma coś zrobić używając czegoś tam, to z łatwością i dziką satysfakcją "udowodni" mi, że jednak się nie da.

Mogę za to powiedzieć z pewną satysfakcją, że w pewnej firmie miałem możliwość takiego frameworka ubić.

Riddle napisał(a):

Strasznie mnie bawi to jak powszechne jest zjawisko degradacji pomysłów w IT. Jak rozważam różne pomysły, metodologie, wzorce, etc. to praktycznie w każdym widzę podobny schemat, tzn:
[ciach]

Tak, dokładnie.

Pamiętam pierwszy świstek z "wolnego świata", piąte ksero z trzeciego kwero z "Byte", że xxxx (życie pokazuje, po 30 latach nadal wystarczy tu wstawić dowolną technologię programistyczną, np microserwisy) jest jak seks nastolatków
wszyscy o tym ciągle mówią, ale niewielu robi
każdy myśli, że inni to robią (lepiej od niego)
ci nieliczni, którzy robią, nie robią tego dobrze ani bezpiecznie
... było tego wiecej

Czy ten dowcip kiedyś odejdzie w niebyt historii? Bo na razie sie nie zanosi.

@Riddle: "Strasznie mnie bawi to jak powszechne jest zjawisko degradacji pomysłów w IT"
Ale zdajesz sobie sprawę, że świat i terminy w IT po prostu ewoluują? Skoro każdy w tym Google itd. używa danego terminu w "nowym znaczeniu" to oznacza, że to właśnie to nowe znaczenie ma znaczenie

Problem nie leży w tym, że pomysły ewoluują, tylko na stosowaniu ich bez zrozumienia po co są, a często nawet na czym polegają. Opisywany przez OP'a przykład może podpadać pod taki schemat. Jest DRY, które miał swój powód - mniej kodu do czytania, łatwiejsza zmiana, wymuszenie sensownego podziału na jednostki. A skończyło się w tym (i wielu innych przypadkach), na utworzeniu jakiegoś "wspólnego frameworku", który powoduje, że wejście w projekt jest trudniejsze, zmiany są bardziej skomplikowane, a w każdym serwisie ładowany jest ten sam zestaw dodatków, czy ma to sens, czy nie. W dodatku każdy błąd we "frameworku" spowoduje najprawdopodobniej konieczność przebudowy i zmiany wszystkich serwisów, które z niego korzystają. Jeżeli całość jest napisana na poziomie "technical excellency" jak przykład z wstrzykiwaniem beana na polu jakiejś owijki - to prawdopodobnie biedacy, którzy muszą tego używać większość czasu poświęcają na dostosowanie się do dupnych wymagań i użycie g... kodu "bo muszą" zamiast na sprawieniu, że to co piszą robi, to co ma robić.

Z moich własnych zawodowych traum, przypominam sobie akcję "mikroserwisy rozwiążą nasze problemy, wszystkie, co do jednego". Większość tych serwisów na koniec była postawiona na osobnych VM'kach, komunikowała się synchronicznie, nikt nawet nie pomyślał o skalowaniu horyzontalnym, deployment był ręczny. Jak uciekałem z tego projektu, to zwyczajnie całość nie działała i nie miała moim zdaniem szansy zadziałać w przyszłości. Wszystko dlatego, że był tam architekt, który kazał robić mikroserwisy, bo jemu inny architekt kazał robić mikroserwisy, a zrozumienie ich idei było śladowe.

@piotrpo: Czyli zgaszasz się z Riddle, że mikroserwisy powinny być bardzo malutkie i nie powinny być zmieniane tylko wywalane do kosza jeśli biznes zmieni jakiekolwiek wymagania?

@anonimowy: Częściowo. Uważam, że powinny być małe, ale z zupełnie innych powodów niż "wywalić i napisać od zera".

• ograniczenie odpowiedzialności
• "fizyczne" ograniczenie zakresu zmian
• skalowalność

Z małego rozmiaru oczywiście wynika możliwość wywalenia i napisania od początku jeżeli komuś się tak spodoba, ale nie patrzę na tę cechę jak na cel sam w sobie.

anonimowy napisał(a):

@piotrpo: Czyli zgaszasz się z Riddle, że mikroserwisy powinny być bardzo malutkie i nie powinny być zmieniane tylko wywalane do kosza jeśli biznes zmieni jakiekolwiek wymagania?

Ja nie mówiłem, że takie powinny być, tylko że taka była początkowa ich idea.

W moim poprzednim poście napisałem, że powinno dać się móc je wywalić i napisać od nowa. Jako kryterium, czy masz dobrze napisany mikroserwis czy nie. Jeśli z jakiegoś powodu nie mógłbyś go wywalić i napisać nowa, to znaczy że masz ukryte powiązania, i cały microserwis trochę nie ma sensu i bardzo prawdopodobne że przynosi więcej szkody niż pożytku. Albo też może oznaczać że jest za duży.

Wyraźnie zaznaczyłeś, że powinny być mikro i nie powinny być edytowalne.
" ano idea była taka, żeby nie modyfikować kodu mikroserwisów"

Nie spotkałem się nigdzie z takim podejściem więc jest ono błędne bo nikt z niego nie korzysta. Jeśli taka była idea to znaczy, że jest przestarzała a nie źle zaadoptowana

anonimowy napisał(a):

Nie spotkałem się nigdzie z takim podejściem więc jest ono błędne bo nikt z niego nie korzysta. Jeśli taka była idea to znaczy, że jest przestarzała a nie źle zaadoptowana

No okej, masz prawo do swojego zdania.

Ale obawiam się, że to znaczy że jesteś osobą o której pisałem tutaj: Wymuszanie wspólnych bibliotek w mikroserwisach. Że jeśli jakiś słaby pomysł stanie się dostatecznie popularny, to przestaje być słaby.

piotrpo napisał(a):

Z małego rozmiaru oczywiście wynika możliwość wywalenia i napisania od początku jeżeli komuś się tak spodoba, ale nie patrzę na tę cechę jak na cel sam w sobie.

jak zwykle w inżynierii: tak małą, jak to potrzebne ALE NIE mniejsze
Kazda zbyt atomowa granujacja to rosnace koszty developmentu, złożoność, komunikacji, infrastrukturalne itd...
(javascriptowa libka do dodawania liczb)

Najsmutniejsze w tym wszystkim jest to, że taki sam 'wzorzec' przyjmuje Spring.

Dodajesz jakaś zależność i nagle masz nowe beany 'za darmo' + aplikacja się wywala, mimo że jest tylko jedna klasa z main.

Nigdy nie zrozumiem, jak to się dostało do mainstreamu.

programista-z-cyrku napisał(a):

Co o tym sądzicie i co należałoby zrobić?

Architekci powinni zatrudnić Dev Rel'a, żeby chodził i reklamował ich biblioteki. A Ty powinienes - jak już ktoś mądrze wspomniał - odświeżyć CV ;)