Jeśli miałbyś stworzyć sporą architektura mikroserwisową docelowo działająca na produkcji ale nie na spring błocie ani czymkolwiek opartym na adnotacyjnym robieniu magii to co by to było? Aplikacje nie muszą być reaktywne ale fajnie jakby były oparte na nettym (pytanie czy netty w aplikacjach blokujących nie ma gorszego perf od tomcata/jetty nawet jeśli damy mu tyle samo wątków) Póki co myślę że najlepszą, najlepiej dopracowana i sprawdzona produkcyjnie biblioteką do tego jest Vert.x, mimo że jest stworzone głównie do reaktywnego pisania aplikacji. A może jednak jest jakas lepsza alternatywa?
@Ewentualnie: camel używa między innymi netty, więc nie spodziewałem się, żeby było na odwrót ( ͡°͜ʖ͡°) Chodziło mi o zaznaczenie, że koncepcja jest cholernie stara.
@pwasowsk: jest camel dostępny na quarkusa. Tylko tego production ready bym nie nazwał (niczego na graalvm)
@pwasowsk: CV mam w dupie, ot lubię się pobawić czymś nowym. Z drugiej strony, kubernetes. To czasem jest taka alpha i rzeźba w gównie, że ręce opadają. Zarówno z poziomu developera, jaki administratora klastra. Produkcyjnie też można sobie elegancko strzelić w stopę. Konkurencji jednak nie ma i trzeba sobie radzić z tym co jest.
@globalbus: Nie znam kubernetes, ale jest fajna alternatywa w chmurze AWS - ECS. Na codzień developuję backend do aplikacji, używanej przez setki tysięcy userów i działa bez problemów. Mirki na springu.
@pwasowsk: vendor-lockin oznacza rozwiązania, z których nie korzystam. A z zastosowań pracowych, to wymogi formalno-prawne do wypychania czegoś w chmurę, w polskim sektorze finansowym są nieciekawe. Kubernetesa i oparte na nim twory stawiasz on-premise.
Póki co myślę że najlepszą, najlepiej dopracowana i sprawdzona produkcyjnie biblioteką do tego jest Vert.x, mimo że jest stworzone głównie do reaktywnego pisania aplikacji. A może jednak jest jakas lepsza alternatywa?
#java #programowanie #programista15k #spring #vertx
camel miał nonblocking zanim powstała koncepcja reactive streams.
https://camel.apache.org/manual/latest/asynchronous-routing-engine.html (to jest od 2010)
Chodziło mi o zaznaczenie, że koncepcja jest cholernie stara.
@pwasowsk: jest camel dostępny na quarkusa. Tylko tego production ready bym nie nazwał (niczego na graalvm)
Z drugiej strony, kubernetes. To czasem jest taka alpha i rzeźba w gównie, że ręce opadają. Zarówno z poziomu developera, jaki administratora klastra. Produkcyjnie też można sobie elegancko strzelić w stopę. Konkurencji jednak nie ma i trzeba sobie radzić z tym co jest.
A z zastosowań pracowych, to wymogi formalno-prawne do wypychania czegoś w chmurę, w polskim sektorze finansowym są nieciekawe. Kubernetesa i oparte na nim twory stawiasz on-premise.