Życie po Springu?

3
Korges napisał(a):

Z tego co pamiętam, generalnie sami możemy przypadkowo wymusić na boocie pobranie dependencji która nas kompletnie nie interesuje. Poza tym zawsze można sterować, albo ręcznie dołączając paczki albo jakieś exclusions. Lub nawet kompletnie zrezygnować z boota i sterować wszystkim samodzielnie.
Ale generalnie masz rację, Spring zaciąga sporą ilość zależności.

Z drugiej strony to chyba nie na tym miało polegać, że Spring / Spring Boot niby ułatwia życie dając paczki do wszystkiego, a jak przyjdzie co do czego to trzeba się użerać żeby zależności nie wywaliło w kosmos.

Druga sprawa, to podbijanie wersji w Springu - mam teoretycznie wszystko skonfigurowane (mniej lub bardziej zgodnie ze sztuką - nie mnie oceniać co jest zgodne ze sztuką), aplikacja działa, wstaje, testy zielone, wszystko cacy.

A potem zmieniam wersję dowolnej Springowej dependencji z dajmy na to 2.1.x na 2.4.y (numery zmyślone). I bęc, wszystko leci w kosmos

  • W dependencjach plątaniec, bo którejś paczce zmieniły się zależności
  • Jak już plątaniec wydaje się być rozplątany to kontekst nie wstaje, bo okazuje się że masz teraz dwa KasztanBeany i Spring nie się co robić - a Ty nie wiesz skąd ten drugi bean
  • Jak już ustalisz skąd to zamieszanie i wydaje się, że problem jest rozwiązany to okazuje się, że teraz masz 0 KasztanBeanów i kontekst znów nie wstaje
  • Jak już rozwiążesz problem z KasztanBeanem odkrywasz, że przestały działać np. konfiguracje sekórity i można mieć wjazd na admina bez admina
  • Wymyśl sobie jeszcze 0..* takich problemów

Nie mówiąc o tym, że prawie pusty serwis ze śladową ilością (jawnych) dependencji potrafi sobie wstawać np 20s albo 30s :]

0

@superdurszlak: to może masz HDD i3 i 1GB bo u mnie wstaje kilkanaście sekund apka z kilkoma tabelami i z jakimś grafem obiektów, do tego flyway na start :D

2

@superdurszlak: w ogóle propo tego problemu z zależnościami, to miałam jeden projekt, który używał bazela zamiast mavena czy gradle'a. Oczywiście psioczyłam na teog bazela niemozliwie :D Aczkolwiek w bazelu nie jest tak, że dodajesz spring-boot i działa (szok!), ten system budowania nie zaciąga pośrednich zależności. Na początku to było mega irytujące, trzeba było definiować wszystkie zalezności ale potem wspominając inne projekty pomyślałam, że to fajne. Wtedy wiadomo, że w całymprojekcie masz wersję x danego modułu springa czy biblioteki nie musisz excludować itp. Masz kontrolę bardziej oczywistą. Ideą springa jest żeby dodać tego startera i wzystko śmigało, ale to drugie podejscie jest fajne, w kontekście wielu różnych zależności.

3

Wtedy wiadomo, że w całymprojekcie masz wersję x danego modułu springa

maven i dependencyManagement też to załatwia ;)

superdurszlak

Jedyny problem z migracją jaką widziałem to kiedy Spring Boot zmienił format jara, nigdy wcześniej ani później. Podbijam wersje i działa od ręki ;)

1
Shalom napisał(a):

Jedyny problem z migracją jaką widziałem to kiedy Spring Boot zmienił format jara, nigdy wcześniej ani później. Podbijam wersje i działa od ręki ;)

A podbijałeś kiedyś wersję Spring Boota z 1.5 do 2.2 w projekcie z OAuth2? xd Nie polecam.

1
AnyKtokolwiek napisał(a):

Co by taki produkt miał zawierać, jak by musiał być, aby zastąpić Springa?

Spring będzie zastąpiony w przeciągu paru lat, jeżeli nic nie zrobią ze wstrzykiwaniem zależności na etapie kompilacji oraz kompilowania kodu aplikacji do kodu natywnego systemu operacyjnego. Spring był pisany kiedyś jak jeszcze nieznane były mikroserwisy i ciągnie za sobą dług w tej postaci. Nie będę tutaj się rozwodzić. Są frameworki, które są już pisane w tzw. cloud-native np. Quarkus pod flagą RedHata, stąd noo... Jeżeli wciąż chmura będzie tak forsowana jak teraz i tzw. serverless to nie widzę Springa w przyszłych 10 latach jako wiodącego frameworka. Jedynym plusem jaki jest teraz, jest to, że masa ekosystemów jest postawiona na Springu i będzie podobnie jak z Javą EE, że nie będzie sensu tego przepisywać. Choć mogę się mylić.

1

Byl moment ze wszyscy dużo osób mysleli ze groovy on grails go zastapi, no ale jednak nie wyszło

0

oraz kompilowania kodu aplikacji do kodu natywnego systemu operacyjnego

Że co? Jak ma się to do Springs I czemu miałaby to być zaletą?

0
scibi92 napisał(a):

oraz kompilowania kodu aplikacji do kodu natywnego systemu operacyjnego

Że co? Jak ma się to do Springs I czemu miałaby to być zaletą?

Przede wszystkim jest to wstrzykiwanie zależności na etapie kompilacji, co znacząco skraca czas uruchamiania aplikacji. Drugą ważną zaletą jest możliwość skompilowania kodu aplikacji napisanej przy pomocy Micronauta i Quarkusa to kodu natywnego systemu operacyjnego, co znacząco podnosi wydajność takiej aplikacji i zmniejsza jej zapotrzebowanie na pamięć.

Tutaj o tym kiedyś czytałem, daję cytat.
https://bulldogjob.pl/news/901-spring-micronaut-czy-quarkus

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