Porównanie/ranking nieservletowych frameworków http ?

0

Micronaut? Ratpack ? Quarcus? Te potrafię wymienić z głowy, pewnie inne.
Jeden czysty http, drugi ma elementy do (mikro)serwisów

  1. Jeszcze o jakimś innym powieniem poczytać?
  2. Są jakies artykuły, które je porównują? Zauważają wady?
  3. Waszym zdaniem, z którym są najlepsze perspektywy?
2

Ja mam kolejne bardziej pytania niż odpowiedzi:

  • Czy Dropwizard, Akka HTTP, Spark Java też się zaliczają do tej grupy?
  • Jaka jest zaleta nieservletowych nad servletowymi?
0

Micronaut, Ratpack i Quarkus to trochę różne bajki - framework, biblioteka web, i w zasadzie plaftorma (na quarkusie chyba bez problemu odpale np. ratpacka).
Weź cokolwiek i się pobaw - IMO z perspektywy zabawy tutoriale, filmiki itp. najklepiej wyglądają w Quarkusie.

0
Kamil Żabiński napisał(a):
  • Jaka jest zaleta nieservletowych nad servletowymi?

Performance, RAM, wątki?
Na obecnym etapie pytam z amatorskiej ciekawości.
Zestandaryzowany świat servletów ma wiele innych plusów

0

Jest jeszcze vert.x i... Spring WebFlux :) „Zaleta” nieservletowych frameworków jest odejście od modelu thread-per-request, co swoją drogą wprowadza dodatkowe utrudnienia. Jeśli miałbym coś wybrać to porównywałbym wielkość community, ekosystemu, łatwość developmentu i testowalność. Chyba, że jesteś Netfliksem to jeszcze performance.

2

Nieservletowe frameworki mogą być blokujące - SparkJava (chyba) jest taki. Czyli to ortogonalna sprawa.

Problem z servletami polega na tym, że są chore. Koncepcja, że jakiś kontener ładuje klasę przez refleksję, startuje obiekty domyśłnym konstruktorem itd. zabija normalne dependency injection i łatwe testowanie.
Aby jakoś temu zaradzić urodziły się tak chore pomysły jak kontener DI i Spring. Trzeba było jakoś połatać totalną nietestowalność (i toporność) oryginalnej platformy.

Dodatkowo technologie oparte o servlety i model request per thread umożliwiają korzystanie z potworów typu ThreadLocal (i wszelkie magiczne frameworki namietnie to wykorzystują). Przez to śledzenie przepływu w takich programach i refaktoring jest często wyzwaniem (ile to już razy wywaliłem "nieużywany" parametr :/ i zadziwiłem testerów (a testy na zielono oczywiście) ).

Model nieblokujący bardziej pasuje do programowania funkcyjnego więc dla maniaków fp takie rozwiązania są bardziej naturalne (i łatwe do ogarnięcia). Dodatkowo "cały świat" poza javą tak robi, więc pisanie w nodeks express, ratpacku, webflux (funkcujnym), akka http itd. wygląda dość podobnie.

2

https://github.com/rapidoid/rapidoid
http-server modul. Swego czasu uznawany za najszybszy server http (ogólnie, nie to że w java) - https://www.techempower.com/benchmarks/#section=data-r12&hw=peak&test=plaintext
Osobiście nigdy nie korzystałem, sam benchmark to stare dzieje więc wrzucam raczej jako ciekawostkę.

Jeśli nie servletowe (tj nie Spring) w pracy to Ratpack

Trzeba też wziąć pod uwagę, że pomimo tych wszystkich zalet rozwiązań nieblokujących, to nie ma nic za darmo. Kod nie blokujący o wiele trudniej się piszę, testuję i utrzymuję. Zablokowanie wątku na event-loop przez chwilę może się skończyć tragedią dla aplikacji. Server nieblokujący będzie wolniej odpowiadał ale w przeciwieństwie do tego blokującego - jednak nadal będzie odpowiadał przy dużej ilości połączeń - jednak nie należy sie spodziewać, że te rozwiązania zwiększą throughput (już gdzieś widziałem na tym forum jak ktoś był bardzo zdziwiony jak mu reaktywny sterownik o 20% wolniej odpowiadał niż zwykły do bazy danych).

- tutaj jest imho bardzo fajnie zobrazowane to o czym piszę. Jest gdzieś wersja polska na 100% ale nie mogłem znaleźć.

Można jeszcze rozważyc server http obsługiwany przez Kotlin Coroutines - chociaż to bym raczej odradzał na ten moment, od roku piszę w tym mniejsze lub większe aplikację i na ten moment moje odczucia są takie, że problem który miały rozwiązać coroutines, co prawda rozwiązały ale wprowadzając jeszcze większy chaos niż ten znany z reaktywnych monad. Nieład dotyczący scoep'ów, brak sensownej obslugi wyjątków (np musimy sami stworzyć coroutine, jak poleci wyjątek żeby zastąpić starą), podczas korzystania z channeli albo mamy callback'i (tylko, że w aktorach) albo zamieniamy Mono / Producer / Publisher na Deffered i czar "strcutured concurrency" prysł. Mimo to nadal podoba mi się, że to takie lightweight i nie trzeba tony konfiguracji jak np przy Akka żeby zrobić coś fajnie współbieżnie w nieblokujący sposó” bo tworzymy aktora one-linerem :P

1

Kiedyś promowałem Ratpacka, nadal ma u mnie dobre notowania, ze względu na stabilność (naprawdę cieżko go zDOSować - (sam engine - kod można napisać syfny i wtedy polegnie) ).
Ratpack niestety zatrzymał się w rozwoju (brak chyba nadal wsparcia dla http2 itp). No i ma już lekko archaiczne api śmierdzące groovm (throws Exception? - no prośba).

Używam częściej fukcyjnego Spring WebFluxa - bez kontekstu springowego i całej springowej otoczki (adnotacji, skanowania klas i tym podobnych badziewi). Jest ok. Jedyna wada, że blisko Springa, i jest ryzyko, że ktoś w zespole niechcący magii użyje.

Z tą szybkością nieblokujący ws blokujący - i tak większość zależy od kodu. Jakkolwiek - **wiadomo ** dlaczego serwery blokujące powinny efektywniej działać o ile cały nasz stack jest nieblokujący (czyli nie mamy np. jdbc...).

Z innej beczki, trochę też posiedziałem przy Kolinowych Współprogramach ( :-) Coroutine) i zgadzam się, że to mechanizm jednak zbyt niebezpieczny - za dużo w tym runtime. Fajne rzeczy można zrobić (KotlinTest, kotlin-ktor itd.) - ale jak ludzi zaczną tego na szerszą skalę używać to bedzie dramat na miarę Springa i Java EE.

1 użytkowników online, w tym zalogowanych: 0, gości: 1