[Ankieta] Dlaczego Quarkus, Dropwizard, Ktor, Micronaut a nie Spring?

cześć,
Nie da sie ukryć, że w większości około JVMowych projektów mamy Springa... Dużo integracji, duzo autokonfiguracji, ogromne community, łatwość użycia itd - dla właścicieli projektu to istotne cechy (np przy poszukiwaniu ludzi do zespołu, rotacji w zespole itp).

Mimo to niektóre zespoły wybierają inne biblioteki/frameworki - między innymi te z tytułu wątku - Micronaut, Ktor, Quarkus itd.

Pytanie jest proste: dlaczego one, a nie Spring? Jakie argumenty przemawiają

Disclaimer: Ja jestem świadomy jak działa Spring i wiem, że jest wiele osób które nie znosi tego frameworka. Pisanie w Springu często prowadzi do "moj projekt pisany jest w Springu" zamiast "moj projekt pisany jest w javie/kotlinie" :D. Natomiast to że ktoś nie lubi Springa nie ma większego znaczenia dla stakeholdera, dla którego użycie Springa najzwyczajnie przyspieszy development. Przynajmniej na początku.
Mówię to, bo ciekawi mnie ilu z was używa Springa a ilu poszło w coś innego (i dlaczego taka decyzja)?

Niektóre firmy (Revolut?) jawnie mówią, że na ich rekrutacji zadania nie można napisac z uzyciem Springa. (nie jestem na 100% pewny ale słyszałem o czymś takim)

Pisanie w Springu często prowadzi do "moj projekt pisany jest w Springu" zamiast "moj projekt pisany jest w javie/kotlinie" :D.

Dlaczego twój projekt jest napisany w javie/kotlinie?

Natomiast to że ktoś nie lubi Springa nie ma większego znaczenia dla stakeholdera, dla którego użycie Springa najzwyczajnie przyspieszy development.

Dlaczego przyspieszy?

@jarekr000000: ciesze sie że sie wypowiedziałeś :)

Dlaczego twój projekt jest napisany w javie?

nie do końca rozumiem, mozesz wyjasnic?

Dlaczego przyspieszy?

sam chyba wiesz jakie tu są argumenty... :) w springu wrzucasz dependency typu spring-kafka, ustawiasz pare propertiesów i automatycznie masz skonfigurowane polaczenie; tak samo z jakąś bazą danych; stawiam, że gdybyś chciał wystawic API po GraphQL to jest jakies spring-boot-graphql które wrzucasz i masz wszystko skonfigurowane out-of-the-box; actuator to kolejne - od pstrykniecia palcem daje ci metryki, wystawia endpointy; kolejne - Spring Security który daje ci możliwość szybkiego pokonfigurowania jakiegos RBAC w aplikacji; chcesz deployowac aplikacje na rozne srodowiska? w springu masz rożne application-profil.yaml które czyta się bardzo łatwo w kodzie; i tak dalej

nie chce tu mówić jaki to Spring nie jest zajebisty; wiem że ta "magia autokonfiguracyjna" może się odbić czkawką; tylko podaje przykłady gdzie Spring "przyspiesza development"

nie wszystkie libki takie coś mają; analogicznie w takim Ktor'rze trzebaby: połączenia do Kafki zrobić od podstaw przez jakiegos kafka-connectora dla jvm; GraphQL endpoint skonfigurowac od podstaw, RBAC tez zrobic od podstaw; czytanie propertiesów w kodzie nie w kazdej alternatywie jest tak.. przystępne jak w Springu; wystawienie metryk z aplikacji (analogicznie do actuatora) to w pełni customowa robota itp

Ogólnie czy byłbyś w stanie wyjaśnić dlaczego piszesz w javie/kotlinie - a nie np. w PHP?
Tam tez masz wszystko gotowe.
Weź laravel - masz wszystko gotowe.
Weź wordpressa i masz gotowe nawet więcej - jak będziesz chciał postawić CMS to żaden spring Ci nie podskoczy...

nie wierze, że nie wiesz o co mi chodzi @jarekr000000

nie chce tu mówić jaki to Spring nie jest zajebisty; wiem że ta "magia autokonfiguracyjna" może się odbić czkawką; tylko podaje przykłady gdzie Spring "przyspiesza development"

nie wszystkie libki takie coś mają; analogicznie w takim Ktor'rze trzebaby: połączenia do Kafki zrobić od podstaw przez jakiegos kafka-connectora dla jvm; GraphQL endpoint skonfigurowac od podstaw, RBAC tez zrobic od podstaw; czytanie propertiesów w kodzie nie w kazdej alternatywie jest tak.. przystępne jak w Springu; wystawienie metryk z aplikacji (analogicznie do actuatora) to w pełni customowa robota itp

No właśnie piszesz o rzeczach do których większość alternatyw ma sensowne wsparcie. Czasem zamiast frawmeworka bierzemy bibliotekę.
Co więcej, nawet jak nie jest tak dobrze opisane to to są rzeczy, które się konfiguruje przez pierwsze godziny, może dni w projekcie. A projekt trwa zwykle dużo dłużej....

Bywa, że na etapie konfiguracji projektu mam jakąś przycinkę - niedawno miałem... i wtedy nawet stwierdzam, że Spring ma to out of the box.
Ale potem widzę jak moi koledzy w sąsiedni, projekcie przez 3 dni nie są w stanie stwierdzić czy Spring działa czy nie (drobna literówka gdzieś w url)... i nawet nie wiedzą gdzie szukać problemu, bo magia nie działa, debuga nie ma gdzie postawić...

Jeśli pytanie brzmiało by dlaczego Micronaut to dlatego że najlepiej współpracuje z GraalVM ze wszystkich innych frameworków.

Dużo integracji

Nie rozumiem. Biblioteki w Javie integrują się dobrze też bez springa

duzo autokonfiguracji

Najlepsza biblioteka do konfiguracji jaką widziałem to typesafe-config wszystko inne jest gorsze :(

łatwość użycia

Może jak stawia się hello world na konferencji. Ja widzę bardziej niekończące się piekło adnotacji, co kto lubi. Ja wolę programować

Natomiast to że ktoś nie lubi Springa nie ma większego znaczenia dla stakeholdera, dla którego użycie Springa najzwyczajnie przyspieszy development.

Nie rozumiem tego narzecza, ale skąd ta pewność? Zmierzyłeś? Dasz sobie za to rękę uciąć?

dokładnie o tego typu argumenty chodziło mi od początku @jarekr000000

[..] Co więcej, nawet jak nie jest tak dobrze opisane to to są rzeczy, które się konfiguruje przez pierwsze godziny, może dni w projekcie. A projekt trwa zwykle dużo dłużej....

Zgadzam się. Wyobrażam sobie natomiast, że używam np. Micronauta i chce użyć technologie X - Micronaut nie ma integracji z nią więc robie konfiguracje od podstaw; no i teraz mam 10 mikroserwisów i każdy z nich używa X - tu pojawia sie kolejny dylemat: zrobić swojego in-house .jara gdzie wrzuce te konfiguracje zeby tego nie powtarzac we wszystkich serwisach, czy możę zrobie copy-paste? oba brzmią nie za fajnie
Alternatywe w springu masz taka: dependency spring-boot-X z dobra dokumentacja, duzym community no i na pewno będzie solidniejsza niż coś wyskrobanego in-house.

Nie mówie że zawsze tak jest; chce po prostu podkreślić ten punkt widzenia który ma większość pro-Springowców

KamilAdam napisał(a):

Najlepsza biblioteka do konfiguracji jaką widziałem to typesafe-config wszystko inne jest gorsze :(

Tropię takie smaczki, ale to nie typesafe, tylko stringowe rozwiazanie. czegoś nie zauważyłem?

Odpalasz projekt w tej technologii, w której masz doświadczenie, jest produkcyjnie sprawdzona i da się zatrudnić klepaczy za normalne pieniądze. Ewentualnie musisz iść w Kafkę, bo nikt nie przyjdzie pracować z JMS. To ma koniec końców zarabiać pieniądze i być łatwo utrzymywalne. Spring spełnia te kryteria, dzięki adnotacjom i autokonfiguracjom wszystko magicznie działa - nie potrzebujesz tabunu seniorów, żeby to ogarnąć. Sad but true.

(*) - z tego co wiem u nas są testy Micronauta, czasem fajnie zaszaleć :)

Tak już na serio - Spring jest łatwy w developmencie bo w 75% przypadków i znany. To bardzo duża zaleta. Wadą jest pozostałe 25% oraz to, że jest ciężki. Dla małych i średnich CRUDów to jest dobry framework (i wtedy bym go używał). Przy czym największym problemem Springa jest jego leciwość - tj. z powodów legacy istnieje wiele rozwiązań, które po prostu na siebie nachodzą i nie są w żaden sposób logicznie połączone - ot np. błędy RESTowe można ogarniać na co najmniej trzy sposoby (zwracać ResponseEntity, przez ExceptionHandler i ResponseStatusException). I teraz kombinuj skąd leci błąd bo mogło się okazać, że ktoś dodał klasę z @ControllerAdvice classpath i nagle wszystko się wysypuje.

Co do zależności springowych to jestem na 100% przekonany, że jeśli ktoś nie potrafi sensownie ogarnąć Kafki bez kafka-spring to tak naprawdę nie powinien się tego dotykać. Ba, czasem rozwiązania springowe raczej życie komplikują niż ułatwiają.

Załóżmy że masz średniej wielkości projekt. Znasz dobre praktyki, wiesz jak pisać kod z wykorzystaniem IoC. Słowem rzec, w każdym z frameworków napisałbyś kod w ten sam sposób.
Dlaczego użyć springa? Wszyscy go znają... + prawdopodobnie ktoś już miał ten sam problem co ty...
Dlaczego nie użyć springa?

Jeśli masz problem z pamięcią na serwerze, to statystycznie rzecz ujmując... zmiana frameworka może pomóc. Szybkość wstawania apki/testów? Who cares. Dopierd**** nowy procesor.
źródło: https://micronaut.io/blog/2020-04-07-micronaut-vs-quarkus-vs-spring-boot-performance-jdk-14.html

Ja mam Dropwizarda z jakimś starym Springiem (4 lub 3), nie wiem co zaznaczyć.
Nie pytajcie mnie do czego ten dropwizard bo dopiero ogarniam projekt.

Moje ulubione pytanie na rozmowach rekrutacyjnych to czy dany @Transactional zadziała. A Spring ma normalne narzędzie do transakcji, nazywa sie TransactionTemplate i działa nawet w metodach prywatnych, nie wiem tylko czemu niektórzy uważają że napisanie tej adnotacji @Transactional zamiast napisania 3 linijek z użyciem TransactionTemplate to taka oszczędność kodu.
Generalnie Spring jest jeszcze ok jak ktoś go w sensowny sposób używa, największym rakiem enterprajsów jest jednak JPA. Totalnie przeciekająca abstrakcja, wystarczy że nie przeczytasz jakieś bibli mającej tysiąc stron to nawalasz n+1 jak p...ny ewentualnie robisz Fetch.EAGER i masz ram zarąbany encjami albo StackOverflowException xD. Inna rzecz to lazy loading kolekcji której właściciela usunałem, ale jeszcze transakcja nie została poszła xD
A są takie fajne alternatywy :)

private fun updateInvalidPasswordCounter(username: String) {
        dslContext.update(USR)
                .set(USR.INVALID_PASSWORD_COUNT, USR.INVALID_PASSWORD_COUNT.plus(1))
                .where(USR.USER_NAME.eq(username))
                .execute()
    }

fun findUsernameByNotExpiredToken(hash: String, time: Instant): Option<String> {
        return dslContext.select(USR.USER_NAME)
                .from(USR)
                .join(RESET_PASSWORD_TOKEN).on(RESET_PASSWORD_TOKEN.USER_ID.eq(USR.USER_ID))
                .where(RESET_PASSWORD_TOKEN.TOKEN_HASH.eq(hash))
                .and(RESET_PASSWORD_TOKEN.EXPIRATION_TIME.ge(time))
                .fetchOptional()
                .toOption()
                .map { it.component1() }
    }

Uważam że trzeba wybierać odpowiednie narzędzia do tego co się robi i to że się da się coś zrobić adnotacjami albo jakimiś propertiesami to nie zawsze znaczy że tak się powinno robić.

Tylko Spring

dzięki wszystkim za wypowiedzi; chetnie "usłysze" jeszcze kogos :P

ankieta fajnie potwierdza moje przypuszczenia i udowadnia community Springowe