Porównanie/ranking nieservletowych frameworków http ?

Odpowiedz Nowy wątek
2020-03-22 21:13

Rejestracja: 1 rok temu

Ostatnio: 2 minuty temu

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?

Pozostało 580 znaków

2020-03-23 07:07

Rejestracja: 1 rok temu

Ostatnio: 25 sekund temu

Lokalizacja: Silesia

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?

Podpinam się pod pytanie. - donPietro 2020-03-23 10:50

Pozostało 580 znaków

2020-03-23 12:04

Rejestracja: 3 lata temu

Ostatnio: 1 minuta temu

Lokalizacja: U krasnoludów - pod górą

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.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 1x, ostatnio: jarekr000000, 2020-03-23 12:05

Pozostało 580 znaków

2020-03-23 16:37

Rejestracja: 1 rok temu

Ostatnio: 2 minuty temu

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

edytowany 1x, ostatnio: AnyKtokolwiek, 2020-03-23 16:37

Pozostało 580 znaków

2020-03-23 17:05

Rejestracja: 12 lat temu

Ostatnio: 41 minut temu

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.


Ivory Tower Architect
edytowany 3x, ostatnio: Charles_Ray, 2020-03-23 17:07

Pozostało 580 znaków

2020-03-23 18:18

Rejestracja: 3 lata temu

Ostatnio: 1 minuta temu

Lokalizacja: U krasnoludów - pod górą

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.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 3x, ostatnio: jarekr000000, 2020-03-23 18:28

Pozostało 580 znaków

2020-03-26 00:56

Rejestracja: 6 lat temu

Ostatnio: 3 dni temu

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/b[...]mp;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

edytowany 1x, ostatnio: pedegie, 2020-03-26 01:28

Pozostało 580 znaków

2020-03-26 06:55

Rejestracja: 3 lata temu

Ostatnio: 1 minuta temu

Lokalizacja: U krasnoludów - pod górą

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.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 5x, ostatnio: jarekr000000, 2020-03-26 08:11
Pierwszy raz o Ratpacku usłyszałem na Twojej prezentacji jakieś 2-3 lata temu. Wtedy udało mi się go przemycić na proda (i to w publicu!) i tak do tej pory sobie stoi i z tego co wiem dobrze się sprawuję :) - pedegie 2020-03-26 13:05
Moje Ratapacki też działają, ale nowych projektów już nie robie na Ratpacku. Może gdybym miał pod bardzo duży,publiczny load coś robić ...sprawdziłbym jeszcze raz , ciągle nie ufam do końca wielu alternatywom, a ratpacka nieźle udało mi się natestować. - jarekr000000 2020-03-26 13:07
@donPietro: netty jest dość niskopoziomowe, i niespecjalnie wygodnie pisze się w nim typowe serwery http (https://github.com/daschl/net[...]ki/1.-Simple-HTTP-Hello-World) Ratpack i inne serwery (SpringWebflux) korzystają z netty jako "fundamentu". - jarekr000000 2020-03-30 14:03

Pozostało 580 znaków

Odpowiedz

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