Pracując z Spring Bootem, napotkałem wiele mitów dotyczących tej technologii. Przyjrzyjmy się najbardziej powszechnym z nich:
Lombok oszczędza czas
Może nie tak bardzo, jak myślisz….
Lombok to narzędzie, które zyskało popularność dzięki zdolności skracania boilerplate’owego kodu w Javie. Pomimo jego zdolności do szybkiego tworzenia getterów, setterów i innych przydatnych narzędzi przy użyciu adnotacji, to odnotowałem kilka rzeczy, które nieraz spędzały mi sen z powiek:
- Ingerencja w bajtkod:
Lombok działa na poziomie bajtkodu, co oznacza, że wprowadza zmiany bezpośrednio do skompilowanego kodu. To może prowadzić do nieprzewidzianych problemów w momencie działania aplikacji, zwłaszcza gdy są używane inne narzędzia bazujące na bajtkodzie. - Utrudnione debugowanie:
Kiedy coś pójdzie nie tak, analiza problemu może stać się trudniejsza. Działanie Lomboka „za kulisami” może maskować źródło problemów, zwłaszcza gdy stosuje się mnóstwo jego adnotacji. - Nadużycie adnotacji:
Chociaż adnotacje Lomboka są przydatne, ich nadużycie może prowadzić do sytuacji, gdzie kod staje się trudny do zrozumienia i czytania. Zamiast skupiać się na logice biznesowej, programista musi przebić się przez las adnotacji. - Sztuczne zawyżanie wskaźnika pokrycia kodu:
Lombok może prowadzić do sytuacji, gdzie testy jednostkowe nie obejmują faktycznej logiki, ale wskaźnik pokrycia jest wysoki. To może być mylące, zwłaszcza dla zespołów polegających na metrykach jakości kodu. - Zależności i konflikty:
Wprowadzenie Lomboka jako zależności w projekcie może prowadzić do konfliktów z innymi bibliotekami, zwłaszcza w dużych, złożonych systemach. - Problem z narzędziami:
Nie wszystkie narzędzia, zwłaszcza analityczne są w pełni kompatybilne z Lombokiem. Może to powodować problemy z indeksacją kodu, analizą statyczną czy refaktoryzacją.
I to jest jedynie wierzchołek góry lodowej! Natomiast moją motywacją do poruszenie tej kwestii była ilość komentarzy od nowych osób przychodzących do mnie na LiveStreamy programistyczne, pytając dlaczego nie używam Lomboka? Oczywiście wielu programistom może się to wydawać bardzo wygodnym narzędziem. Jednak w moim doświadczeniu zbyt wiele razy napotkałem trudności utrzymując projekty z wykorzystaniem Lomboka i w dłuższej perspektywie przysporzył mi on więcej problemów niż korzyści dostarczał.
Servlety to technologia przeszłości
Często słyszałem to nie tylko od początkujących, ale również od osób zajmujących się nauczaniem. Jednak Spring Boot ma na ten temat inne zdanie… 😄
Przypuszczam, że ten błąd wynika z kojarzenia JSP z Servletami, prawdopodobnie dlatego, że te technologie często były używane w wielu książkach i artykułach nierozłącznie.
Servlet to specyfikacja do mapowania żądań, które wykorzystuje Spring Boot, jednocześnie oferując programistom intuicyjne interfejsy by mogli wkomponować w nie swoją logikę. Servlety to fundament aplikacji webowych w Javie. Pracując w Spring Boot bazujesz na Servletach, a popularne kontenery jak Tomcat czy Jetty to ich gospodarze.
Thymeleafa już się nie używa. Jeśli chcesz to robić dobrze, użyj Angulara albo Reacta.
Thymeleaf, jako silnik szablonów do aplikacji webowych w Javie, często jest uznawany za „starą technologię”. W rzeczywistości jednak, w odpowiednich rękach, może stać się nieocenionym narzędziem, dostarczającym szybkich i efektywnych rozwiązań dla wielu projektów.
Wielkie firmy, takie jak GE Aviation, New York Times czy Siemens nadal korzystają z Thymeleaf w swoich projektach. Natomiast sam jego projekt na GitHubie jest regularnie releasowany.
Wielu początkujących dokonuje wyboru narzędzi bazując na modnych hasłach lub wskaźniku popularności nie biorąc pod uwagę innych aspektów związanych z np. kosztami i zasobami.
Dla zobrazowania – backendowy programista może w ciągu 2 godzin stworzyć prosty interfejs użytkownika dla operacji CRUD w Thymeleaf. Podczas gdy w stosie technologicznym bazującym na Angularze czy React, te same godziny zostałyby poświęcone jedynie na instalacje, konfigurację środowiska i uporanie się z NPM.
W tym przypadku chce rzucić światło na fakt, że włączenie kolejnej technologii do stacku technologiczne wiąże się z koniecznością:
- Integracji z ekosystemem Springa,
- Tworzenia oddzielnych testów,
- Opracowywania scenariuszy budowania,
- Definiowania procedur CI/CD,
- Planowania osobnych wdrożeń,
- Zwiększonych kosztów związanych z utrzymaniem w chmurze/na serwerze,
- Posiadania różnych kompetencji w zespole.
Prawdopodobnie potrzebne będą również osobne zasady dotyczące stylu kodowania, środowisk, używanych narzędzi, potencjalnych migracji, aktualizacji i wersjonowania. Lista długa…
Korzystanie z Thymeleaf może obniżyć koszty projektu poprzez eliminację lub uproszczenie wielu kroków. Chociaż współczesne projekty często łatwiej utrzymywać w frameworkach opartych na JavaScript, to nie należy ślepo stosować najbardziej popularnych rozwiązań wszędzie. Najlepiej to zrozumie developer, który w swojej karierze był już odpowiedzialny za utrzymanie projektu.
Podsumowując, nie ma „złych” narzędzi w inżynierii oprogramowania – są tylko narzędzia źle dobrane do konkretnego projektu. A dla wzmocnienia przekazu zafunduje #bykucoelho
Nie używaj RestTemplate, bo teraz jest już WebClient.
Wraz z pojawieniem się Spring 5 i Spring Boot 2.x zadebiutował WebClient, zaprojektowany do obsługi zarówno tradycyjnej komunikacji blokującej, jak i „nowszej” reaktywnej. Aby w pełni wykorzystać potencjał WebClienta i jego reaktywne możliwości, konieczne jest dodanie specjalnych zależności i zmiana stosu technologicznego w projekcie, co w przypadku standardowej komunikacji może być nieuzasadnione.
Mimo popularności WebClienta, nie jest on bezpośrednim następcą RestTemplate. Prawdziwym nowoczesnym odpowiednikiem RestTemplate jest RestClient, wprowadzony dopiero w Spring Boot 3.2, oferujący usprawnienia, zwłaszcza w zakresie programowania funkcyjnego:
RestClient restClient = RestClient.create();
ResponseEntity<String> response = restClient.get()
.url("https://bykowski.pl/api")
.fetch()
.asEntity(String.class);
System.out.println("Status odpowiedzi: " + response.getStatus());
System.out.println("Nagłówki odpowiedzi: " + response.getHeaderInfo());
System.out.println("Treść odpowiedzi: " + response.getContent());
Zabezpieczenia w Spring Boot – Sam sobie to napiszę!
Podczas projektowania aplikacji kluczowym elementem jest bezpieczeństwo. Choć niektórzy początkujący developerzy decydują się na samodzielne tworzenie zabezpieczeń, często nadużywając Authoryzation Basic, jest to podejście co najmniej ryzykowne.
Gotowe rozwiązania, takie jak Keycloak czy Okta, oferują wiele zaawansowanych mechanizmów bezpieczeństwa „out-of-the-box”. Te narzędzia są sprawdzone, regularnie aktualizowane i uwzględniają zabezpieczenia, które łatwo pominąć podczas ręcznej implementacji.
Wiele osób mylnie uważa, że korzystanie z tych narzędzi jest nadmiarowe i wierzy, że sama poradzi sobie z implementacją. W rzeczywistości narzędzia te dostarczają skomplikowane zabezpieczenia w przystępny sposób.
W świecie IT, gdzie bezpieczeństwo danych jest priorytetem, korzystanie ze sprawdzonych narzędzi nie tylko gwarantuje lepszą ochronę, ale także pozwala zaoszczędzić cenny czas.
Chcesz rozwiązać wszystkie swoje problemy – użyj TDD
Test Driven Development (TDD) jest podeściem, w którym testy jednostkowe są pisane przed samym kodem, bazując na cyklu „czerwono-zielono-refaktoryzacja”. Osobiście widzę w TDD ogromny potencjał. Pomaga ono w tworzeniu kodu o wysokiej jakości, zwiększa jego odporność na błędy i gwarantuje, że tworzone rozwiązania są zgodne z oczekiwaniami.
Jednak TDD zakłada, że pracujemy z dobrze zdefiniowanym biznesem i jasno sformułowanymi wymaganiami. W praktyce developerzy nierzadko stają przed wyzwaniami, takimi jak prototypowanie, nurkowanie w „legacy code” (gdzie rezultat może być nieprzewidywalny), prace z nie do końca (lub błędnie) określonymi lub zmieniającymi się zadaniami.
Wprowadzenie TDD powinno być świadomą decyzją, przy uwzględnieniu specyfiki projektu i oczekiwań biznesowych. Więc za jego wdrożenie nie powinien być odpowiedzialny tylko dział IT. Nie on też panaceum na wszystkie problemy.
Chociaż o TDD nie mówi się już tak głośno jak kilka lat temu w kontekście poszukiwania idealnych rozwiązań, to obecnie za takie rozwiązanie wszystkich problemów uchodzi EventStorming. Ciekawe, co będzie następnym „złotym rozwiązaniem”. Jak myślisz? 😄
