Czy ten Spring to na pewno jest taki bee?

Odpowiedz Nowy wątek
2019-03-12 09:25
eL
3

Cześć.
Od kilku lat pracuje jako java dev. Pamiętam jeszcze projekty w starszych wersjach Springa gdzie trzeba było konfigurować tone XMLi żeby wszystko chciało działać. Aktualnie Spring w mojej ocenie niesamowicie się zmienił i praca ze Spring Bootem + stackiem Springa jest bardziej przyjemna a community ogromne choć jak każda technologia ma ogrom zalet ale i też wad przez co nawet tutaj na forum często można spotkać opinie żeby szukać alternatyw. I super, bo to na pewno bardzo rozwojowe ale czy dobre w kontekście rozwijania projektów?

Jakiś czas temu chciałem napisać prototyp pewnej aplikacji i pomyślałem że bedzie to dobra okazja do nauki nowych technologi. Zamiast Springa postawiłem aplikację na alternatywnych technologiach, np.: Kotlin, Ktor (asynchroniczny serwer http), Kodein (IoC), JOOQ (dostęp do bazy danych).
Z jednej strony zauważyłem sporo zalet takiego podejścia. W przypadku JOOQ mam poczucie pełnej kontroli nad bazą danych (co w Spring Data czy w ogóle JPA nie zawsze było takie odczuwalne bo zawsze gdzieś ten element 'magi' w postaci wygenerowanych tabel czy zapytań pozostaje). Z drugiej jednak strony to co działało w Spring Data tutaj sprawia problemy, np część testów funkcyjnych uruchamiam na bazie H2 w pamięci. Problem w tym że w kodzie jak dodaje rekordy do bazy danych to potrzebuje je od razu zwrócić razem z id by dalej przetworzyć. Spring Data przy zapisie zawsze zwraca zapisaną encję a w jooq jest returning: https://www.jooq.org/doc/late[...]t-statement/insert-returning/
Niby spoko, też fajnie ale na H2 to nie działa, problem zauważony już od 2014 roku a nadal nie jest naprawiony: https://github.com/jOOQ/jOOQ/issues/3035
Efekt jest taki że testy padają i trzeba robić jakieś workaround'y.

Inna sprawa to pobieranie konfiguracji z plików yaml albo propierties. W Spring'u mamy @Value który wszystko robi za nas. Bez springa trzeba kombinować i ręcznie wszystko zaciągać - niby są biblioteki typu Snakeyaml i inne tego typu ale nie jest to już tak intuicyjne.

Generalnie przykładów mógłbym powielać więcej ale nie rozwodząc się już zbyt mocno przejdę do puenty.
Czy to nie jest trochę tak że Spring jak każdy inny framework ma swoje wady i zalety i pewne rzeczy może faktycznie robi dziwnie i z jednej strony możemy na niego narzekać ale prawda jest taka że nie ma aktualnie równie dobrej alternatywy?
Czy koszt wprowadzenia nowych technologii i zmaganie się z innymi problemami (które i tak przyjdą bo żadna technologia nie jest idealna) nie jest czasami większy?
Spring ma za sobą ogromne community, całkiem długą historię rozwoju, wypracowane dobre praktyki i mimo że też nie jest pozbawiony wad to na codzień produkcyjnie korzystamy właśnie z niego bo tak naprawdę porzucenie jego niewiele by zmieniło (zamienilibyśmy jedne problemy na inne)?

Gdzieś przeczytałem (nie potrafię teraz znaleźć) że "framework to zbiór kompromisów" - kelog 2019-03-13 21:26
@kelog: i to by się nawet zgadzało ;) - eL 2019-03-14 06:36

Pozostało 580 znaków

2019-03-12 10:07
3

Ja np. nie mam zbyt dużego doświadczenia w Springu. Korzystając z niego zauważyłem, że najbardziej denerwuje mnie hibernate i JPA. Do prostych rzeczy super, cokolwiek więcej koszmar. W żadnym projekcie na prostych rzeczach się nie kończy. Dużo fajniej jest pobrać dane z bazy, załadować do POJO i na tym pisać sobie logikę wraz z unit testami. Spring Data z bazą noSql fajnie się to sprawdza. I mówię to jako wieloletni funboy Oracle, SQL i PL/SQL :)
Propertiesy w javie się łatwo ogarnia. Te w application.properties używam tylko dla właściwości frameworku.
Ja też robię sobie projekcik tak w ramach nauki, bazując na jednym ze swoich starych projektów. Tam gdzie logikę umieściłem w Javie to przenoszę sobie bardzo łatwo, kopiuj wklej, czasem poprawię trochę kod, dodam jakąś lambdę. Całą resztę muszę przepisywać. To zajmuje sporo czasu. Zrozumiałem, że logika nie powinna być zależna od technologii i frameworka.

Póki co uważam, że spring jest w miarę OK. Jednak tam gdzie mam kod zależny od niego (Security, WebClient, Thmyleaf do generowania maili) to mam go słabo przetestowanego, głównie przez to, że testy muszą czekać na wystartowanie contextu springa, a to kpina jest.

Akurat to nie wina Springa, że Hibernate i JPA są skopane tylko wina twórców Hibernate i implementatorów standardu JPA. Hibernate to zupełnie osobny element i można używać go bez Springa. Można też używać Springa bez Hibernate. - Kamil Żabiński 2019-03-12 11:57
Zgadzam się. Tylko po prostu ucząc się Springa + baza SQL wszystkie przykłady, które widziałem, bazowały na hibernate i JPA. - kkojot 2019-03-12 12:07
Nie lubię SQLi w stringach, ale pewnie wolałbym to od hibernata. W sumie gdybym miał teraz budować springową aplikację z bazą SQL to musiałbym się dobrze zastanowić co wybrać. Póki co próbuję webfluxa + nosql. - kkojot 2019-03-12 12:29

Pozostało 580 znaków

2019-03-12 15:57
6

Często jadę po Springu, ale i pracuje z nim i próbuję robić czasem Spring z ludzką twarzą.
Złe są Beany i katastrofalne są aspekty.
Dziś widziałem przypadek gdzie jakiś security check (chyba!!) nie działał. Podobno, dlatego że adnotacje były na implementacji, a nie na interfejsie ... grubo. Jeszcze ten przypadek sprawdzam, może to bzdura, ale samo to, że nie można być pewnym czy działa Ci security to trochę straszne...

Żaden sensowny biznes nie powinien opierać się na aspektach!

Praktyka pokazuje, że nawet w bardzo klasycznym springu można użycie beanów i aspektów ostro minimalizować (np. ograniczyć się tylko do adnotacji Rest) resztę robić bibliotekami i springowymi templatami.

Najbardziej mi przykro jest jak widzę SpringBatch - naprawdę potrzebny tool i ma wiele fajnych rzeczy zrobionych (DSL do definiowania batchy jest naprawdę ok).
W praktyce w Spring batchu praktycznie nie da się nic zrobić bez beanów i to w ich najgorszej wersji czyli JobScope, TaskScope. Zmienne globalne, (statyczne) to pikuś w porównaniu do raka jakiego powodują (w kodzie) Scoped beany oparte o threadlocal.

Widzę systematyczną poprawę - WebFlux, czysto funkcyjny DSL bez fasolek to był duży krok naprzód. Projekty takie jak SpringFu pokazują jak można robić to co w SpringBoot tylko lepiej. Tylko chłopaki ze springa będą musieli jednego dnia oficjalnie powiedzieć, że Beany to ścierwo... Na razie trochę to marketingowo nie pasuje, po tylu latach psucia kodu beanami. Ale jest nadzieja, dawniej Spring był oparty o XML i w każdej książce o Springu były całe rozdziały o zaletach pisania w XML ( :-) )... jakoś udało się to wypchnąć i zakopać.

Mam już małe czyste aplikacje w Springu oparte o WebFlux (bez żadnego smierdzącego beana!)
Wada jest taka, że czasem przy WebFLuxie muszę wynajdować koło na nowo, zwykle się okazuje, że gdzieś tam jest, ale ostro zakopane w kodzie i nie ma dokumentacji.

Tak czy siak Spring jako zestaw bibliotek, tooli jest całkiem ok. Mogę tworzyć kod który na testach zachowuje się tak samo jak na produkcji i nie potrzebuje specjalnych testów integracyjnych, żeby sprawdzić czy aplikacja w ogóle wstanie. Czas frameworków już minął.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 4x, ostatnio: jarekr000000, 2019-03-12 19:11
Odwrotnie raczej. Adnotacje na interfejsie nie są nijak "dziedziczone" na implementacje ;) Więc jak ktoś sobie da @Transactional na swoje GenericDaoInterface to się potem moze zdziwić. - Shalom 2019-03-12 16:55
Czytając Twoje poprzednie posty aż dwa razy musiałem przeczytać ten żeby się upewnić, że nie jest hejtem na springa :D - OtoKamil 2019-03-12 18:52
Pracowałem trochę z WebFluxem i mam dość mierne wspomnienia. Masz może jakiś projekt dostępny publicznie (albo znasz) na który mógłbym rzucić okiem? Możliwe, że to ja coś źle projektowałem i przez to było sporo problemów. (stacktrace praktycznie nie istnieje, debugowanie jest koszmarne, wszędzie pełno magii z migracją Mono na inne typy itd.) - Lukasz_ 2019-03-18 11:28

Pozostało 580 znaków

2019-03-12 16:28
0

@jarekr000000: otóż nie sądze żeby beany miały zniknąc i nie sa one niczym złym jesli są stosowane zgodnie z rozsądkiem. Programowanie reaktywne nie jest odpowiedzią na wszystko. Co więcej, jest ich nawet więcej. Tylko trzeba wiedzieć kiedy z AOPa sie powinno korzystac a kiedy nie, akurat AOP sie przydaje do korzystania ułatiwien jakie dają frameworki np. zarządzanie transakcjami. I tu zadnej magii nie ma tylko trzeba wiedziec co sie robi.


Nie pomagam przez PM. Pytania zadaje się na forum.
Jak sobie spojrzysz w historię tego forum to chyba mam czuja do Springa i kierunków. W wersji 5 core springa juz jest wyczyszczony z beanów i faktycznie można je wywalić. I oczywiście reaktywne programowanie to jest tylko odpowiedź na programowanie reaktywne, ale zaprawdę jest wiele lepszych rzeczy lepsze niż Stringly typed. - jarekr000000 2019-03-12 17:58

Pozostało 580 znaków

2019-03-12 16:39
eL
0

Nie ukrywam @jarekr000000 że liczyłem na Twoją wypowiedź także dzięki za zaangażowanie ;)
Wracając jednak do Twojej wypowiedzi to właśnie dokładnie to samo obserwuje. Z jednej strony dostrzegamy te wszystkie wady i problemy które Spring ze sobą niesie ale z drugiej tak naprawdę nadal z niego korzystamy. Może nie w pełni ale nikt rewolucji w nowych projektach nie robi. We frontendach jak komuś nie pasuje Angular to bierze Reacta czy tam teraz Vue czy jakoś to mixuje a u nas jest trochę na zasadzie że plujemy na coś ale lepszej alternatywy i tak nie mamy więc musimy do tego pokornie wracać ;)

Pozostało 580 znaków

2019-03-12 18:04
1

@eL tu może wazna uwaga co do korzystamy ze Springa. Ja korzystam przewaznie na zasadzie zgniłego kompromisu. Tam gdzie już ten Spring jest, albo tam gdzie zawczasu dostaję info, że ma być robione pod javowców / springowców. Spring WebFlux to dla mnie piękny trolling na architektów, którzy przypadkiem zatwierdzili Springa i już przeszli na make jar. Jest szansa sie prześlizgnąć (Ale mój kolega niedawno został przyłapany... :-) ).
W projektach gdzie mam troszkę bardziej rozwinięty team, mniejsze ograniczenia od klienta, albo programuje sam (tzw. małe szybkie strzały) nie ma w zasadzie miejsca dla Springa, ani nawet dla Javy, ani nawet dla Kotlina.
Wychodzi, że mam takie na mniej więcej 2 miesiące w roku. Do tego dochodzą jeszcze projekty hobbystyczne po godzinach / konferencyjne , ale tu faktycznie czasem używam Springa w ramach eksperymentów na wrogu :-)


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 1x, ostatnio: jarekr000000, 2019-03-12 18:04
z ciekawości: w czym piszesz takie szybkie strzały, scali? - mad_penguin 2019-03-12 18:26
tak, dość klasycznie - Scala, często z Akka-HTTP (mało już modna). Często ScalaJS do frontu. - jarekr000000 2019-03-12 18:29

Pozostało 580 znaków

2019-03-13 11:23
eL
0
jarekr000000 napisał(a):

Ja korzystam przewaznie na zasadzie zgniłego kompromisu.

Jasne, rozumiem ale jaki by ten kompromis nie był to prawie zawsze on jest. Nie ma czegoś takiego jak na froncie że skoro nie lubie i nie chcę Angulara to wezmę sobie np Vue i będze ok. Jak chcesz w Javie zrobić jakąś webówkę to praktycznie zawsze w mniejszym lub większym stopniu sprowadza się to do wykorzystania Springa (mimo narzekania).
Pytanie więc czy to wynika że nie ma lepszej alternatywy czy mimo tych wszystkich wad Spring jest dobrym wyborem?

Ps. Czemu akurat Scala? Też o niej kiedyś myślałem dość mocno (nawet założyłem fajnie rozwijający się temat ze Scalą który niestety ucichł https://4programmers.net/Forum/Off-Topic/260048-co_z_ta_scala ) ale mam wrażenie (biorąc pod uwagę liczbę ogłoszeń o pracę) że język mimo iż się rozwija to nie ma zbyt dużego zainteresowania. Wszyscy i tak klepią Java & Sprigng a Scalę traktują jako ciekawostkę (przynajmniej na polskim rynku to obserwuje).

EDIT
Sprawdziłem teraz ogłoszenia o pracę w różnych źródłach nie tylko w pl (m.in stackoverflow jobs) i w sumie jestem pod wrażeniem bo ogłoszeń jeśli o Scalę jest 2x więcej niż dla Kotlina (spodziewałem się że będzie podobna liczba). Co prawda Scala jest językiem starszym ale mimo wszystko jestem pod wrażeniem ;)

edytowany 2x, ostatnio: eL, 2019-03-13 11:32

Pozostało 580 znaków

2019-03-13 14:00
3
eL napisał(a):

Ps. Czemu akurat Scala? Też o niej kiedyś myślałem dość mocno (nawet założyłem fajnie rozwijający się temat ze Scalą który niestety ucichł https://4programmers.net/Forum/Off-Topic/260048-co_z_ta_scala ) ale mam wrażenie (biorąc pod uwagę liczbę ogłoszeń o pracę) że język mimo iż się rozwija to nie ma zbyt dużego zainteresowania. Wszyscy i tak klepią Java & Sprigng a Scalę traktują jako ciekawostkę (przynajmniej na polskim rynku to obserwuje).

Scala, bo można praktycznie pisać czysto. I oszczędza mi dużo problemów przy utrzymaniu refaktoringu - po prostu jak się skompiluje to już nawet nie muszę testować :-). Zresztą miałem takie kawałaki kodu w projektach, gdzie nawet szefa javowca do Scali przekonałem.

A to, że wszyscy piszą w Java & Spring to mi zwisa. Wszyscy to piszą w PHP, ale nadal nie jest to dla mnie argument. Poznałem każdy z tych języków . frameworków na tyle, żeby raczej starać się unikać.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 1x, ostatnio: jarekr000000, 2019-03-13 14:26
Dobra to jak lekko odbiegliśmy od tematu to powiedz mi jak masz jakiś hobbystyczny projekt, w Scali zrobisz backend to w czym klepiesz fronty? Po latach wiemy już że GWT, Vaadin (choć był całkiem spoko do momentu klepania dziwnych customowych kontrolek) nie wyszło i się nie przyjęło. Velocity, Freemarker czy Thymeleaf też jest raczej passe chociaż osobiście uwazam że praca z Thymeleaf + Spring Mvc była całkiem spoko i nawet nowe frameworki i tak jeszcze to wykorzystują (np. Ktor). Czy dla aplikacji prywatnych jest sens stawiać drugi serwis z frontem + react/vue/angular? - eL 2019-03-13 14:15
Frontend robię Scali. ScalaJS + React jest fajna. W firmie częściej Typescript+Angular. Na development mam drugi server (node) i proxy do backendu (klasyka). Produkcyjnie pakuje front (statyczne pliki zbudowane) przeważnie pod jeden serwer, razem z RESTem (bo mam deployment wtedy jako jeden jar). - jarekr000000 2019-03-13 14:25

Pozostało 580 znaków

2019-03-14 17:18
2

Spring jest frameworkiem. Trzymaj swoją logikę biznesową z dala od frameworków. ( Na odległość jednego poziomu abstrakcji :) )

edytowany 1x, ostatnio: Michał Kuliński, 2019-03-14 17:20
To ja zapytam, dlaczego? - OtoKamil 2019-03-14 18:48

Pozostało 580 znaków

2019-03-14 19:39
6

To ja zapytam, dlaczego? - OtoKamil 43 minuty temu

Dobre pytanie i jest na nie prosta odpowiedź:

Testy

Testowanie z frameworkiem zwykle jest wolne i upierdliwe.
W przypadku springa można też odpalać testy olewając kontekst springowy. Wtedy testy są szybkie i niewiele warte, bo krytyczne aspekty kodu nie są włączone.

Dla niedowiarków, którzy sądzą, że aspekty nie są istotną częścią logiki biznesowej mam konktrprzykład w postaci prawie każdego biznesu z jakim pracowałem, gdzie wymagania odnośnie security/ról były zawsze bardzo jasno i dokładnie określone w zadaniach. I weryfikowane.

Co więcej nawet takie tranzakcje bazodanowe okazują się w pewnych sytuacjach częścią logiki biznesowej. (np. jeśli mamy smutną historię z wymianą danych z innymi systemami przez db, albo jasno okreslone reguły na rollback/timeouty, powtórzenia operacji itp.).

Mniej ważne:
Są też inne, sytuacje, gdzie wychodzi że mieszanie logiki z frameworkiem to nie jest fajna sprawa: gruby refaktoring, ( np. rodzielanie na mikroserwisy), albo wymiana frameworka na nowszy model.
Nagle się okazuje, że po refaktoringu pewne kluczowe funkcje dają inne wartości, ale testy są nadal ok :-)


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 6x, ostatnio: jarekr000000, 2019-03-14 19:55
Dzięki wielkie za odpowiedź :) My w aktualnym projekcie staramy się pisać testowalny kod bez stawiania springa, niestety sprawdzanie właśnie w/w uprawnień, odpowiedzi z kontrolerów wymusza na nas stawianie kontekstu + testujemy też GISowe zapytania (gdzie randomowo w testach pada rollback i musimy go tworzyć na nowo (randomowy błąd którego nie byliśmy w stanie zreprodukować), więc testy potrafią lecieć dłuuugo). Pojawia się za to dużo mockowania, choć sam do niego nic nie mam, to Jose Valim kiedyś fajnie opisywał testowanie bez mocków które chciałbym sprawdzić w Javie :) - OtoKamil 2019-03-15 11:29
@OtoKamil: Mógłbyś podzielić się linkiem do "testowania bez mocków"? Szukałem (nadal szukam) informacji na ten temat ostatnio, dzięki! - lubie_programowac 2019-03-15 14:24
https://elixirforum.com/t/why-avoid-mocks/1396 Kiedyś czytnąłem na szybko, więc mam nadzieję że nie opisałem tego źle. W każdym razie masz wątek w którym wypowiadał się autor + link do posta na blogu bloga w drugim poście - OtoKamil 2019-03-15 14:28

Pozostało 580 znaków

2019-03-14 22:23
2

Ja też pomyślałem sobie o możliwości wymiany. Sposoby i zasady w jakie firmy prowadzą swoje biznesy zmieniają się rzadziej niż wersje frameworka i same frameworki. Jeżeli nie postawisz sobie warstwy abstrakcji możesz zbyt mocno uwiązać się z nimi samymi i zmiennymi kaprysami ich twórców. Dalsze czytanie: https://michalkulinski.blogsp[...]zwiazani-z-frameworkiem2.html

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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