Wiosenne porządki: Przegląd nowych narzędzi w ekosystemie Springa – JVM Weekly vol. 135

Spring Cloud AWS 3.0

Spring Cloud AWS to projekt w ramach większego ekosystemu Spring Cloud, który upraszcza integrację aplikacji Spring z usługami AWS (jakbyście się z nazwy nie domyślili). Projekt zapewnia dodatkową abstrakcje przy pracy usługami AWS. Zamiast ręcznie zarządzać połączeniami i credentialami, Spring Cloud AWS umożliwia używanie typowych dla Springa mechanizmów, jak AutoConfiguration i wstrzykiwania zależności. Dzięki temu nie musimy (tak dużo) myśleć o zarządzaniu zasobami. Dostajemy też wygodną implementacje standardowych mechanizmów frameworki w oparciu o usługi AWS, takich jak, przykładowo, integracje SQS poprzez udostępnienie SqsTemplate. W skrócie, całość sposób zapewnia ujednolicone, natywne-dla-springa API dla programistów, którzy nie chcą musieć bawić się z AWS SDK for Java (czy ostatnio też „for Kotlin”).

Nie oznacza to oczywiście, że jego twórcy piszą wszystko od zera. Spring Cloud AWS używa pod spodem narzędzi wspomnianego AWS SDK, a największa nowość przychodząca z wersja jest 3.0 to właśnie migracja na AWS SDK v2 for Java. Między wersją v1 i v2 Amazon zmienił bowiem swoje podejście do asynchroniczności. AWS SDK for Javy v2 wprowadziło obsługę nieblokujących I/O i oparł całość o Netty’ego. Dodatkowo, nowa wersja API zaczęła używać tak zwanych Fluent Interfaces, przez co obie edycje są w bardzo dużym stopniu wstecznie niekompatybilne. Ze strony twórców Spring Cloud AWS oznaczało to więc potrzebę całościowego refactoringu, którą wykorzystali jako możliwość poprawienia pewnych decyzji, z których nie byli zadowoleni. Ma to oczywiście swoje konsekwencje – całość jest kompatybilna tylko z Spring Boot 3.0+. Dla większego dobra.

Trochę, żeby uczcić (czy raczej może – wykorzystać) powyższą premierę, postanowiłem wziąć na tapet tematy, które zalegały mi od pewnego czasu i czekały na swój dzień – narzędzia, które wyrastają w ekosystemie. W świecie Springa pojawia się bowiem od czasu do czasu ciekawe projekty, które nie zawsze zbierają jakąś szeroką publikę. Dlatego dziś chciałem pokazać Wam dwa, które w ostatnich miesiącach wpadły mi w łapy.

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

Ostara

Dobra, to przyglądnijmy się pierwszemu z obiecanych narzędzi. Jak bardzo długo zalegało ono w moim backlogu, niech udowodni fakt, że kiedy ostatnio się nim interesowałem, miało jeszcze inną nazwę. Narzędzie, które w mojej głowie zapisało się jako boost aktualnie (niecały tydzień temu) zmieniła nazwę na ostara. Według dyskusji GitHubowej, motywowane było to chęcią uniknięcia konfliktów z popularną biblioteką boost ze świata C++. W związku z tym, że dla projektu może być to swoisty nowy początek, przyglądnijmy się jakie są stojące za nim założenia.

Ostara to narzędzie do zarządzania i monitoringu Sparingowych mikroserwisów, dostarcza w czasie rzeczywistym kluczowe metryki, takie jak użycie CPU i pamięci, wymagając jedynie działającej instancji mikroserwisu z aktywnym Actuatorem. W efekcie dostajemy adminkę, wyświetlającą wszystkie parametry wystawiane przez to API (a jak sobie sprawdzicie, jest tego całkiem sporo). Całość jest prosta w obsłudze, elastyczna i posiada całkiem przyjazną dokumentację.

Ostara to nie pierwsze stworzone przez społeczność narzędzie, będące swoistym Admin Panelem dla Spring Boota. Od kilku lat tryumfy święci bowiem Spring Boot Admin, który przez lata stał się de facto standardem. Po co w takim razie tworzyć nowy projekt? Twórcy Ostara motywują swoją decyzję tym, że Spring Boot Admin wymaga ingerencji w kod aplikacji poprzez dodanie spring-boot-admin-starter-client. Ostara została zaprojektowana tak, żeby w zupełności opierać się na Spring Actuator API, dlatego działa w sposób zupełnie niezależny do monitorowanych przez nią aplikacji.

just

To jak porozmawialiśmy sobie czym jest Ostara, po drodze zahaczając o Spring Boot Admin, czas przyglądnąć się również just, który prezentuje się nawet ciekawiej

Tydzień temu opisywałem, jak bardzo cenie sobie w Quarkusie ichniejszy nacisk na Developer Experience i Dev Mode, którym mocno wyróżniają się pod kątem konkurencji. just to próba stworzenia Springowego odpowiednika Quarkusowego Dev Servera. Projekt zapewnia takie funkcjonalności jak Live Reload, formatter kodu, czy też tworzenie wynikowych binarek projektów w różnych formatach jak obraz Docker czy GraalVM. Całość ma stać się swoistym szwajcarskim scyzorykiem, rozwiązującym codzienne problemy programistów.

just to stosunkowo młody projekt, który stworzony został przez Macieja Walkowiaka, który zresztą jest jednym z głównych kontrybutorów Spring Cloud AWS. Projekty łączy zresztą nie tylko osoba twórcy, ale też pewna stojąca za nimi koncepcja. Tak jak Spring Cloud AWS jest nakładką nad AWS SDK for Java, tak just zbudowany jest na podwalinach spring-boot-devtools. Każdy z projektów dokłada jednak od siebie na tyle dużo, żeby posiadać zupełnie własną tożsamość.

Ważną rzeczą z perspektywy użytkowników jest to, że just nie jest projektem Open-Source. Na tym etapie jego twórca postanowił pozostawić sobie elastyczność i nie udostępnił kodu źródłowego. Kiedy rozwiązanie, pozostający obecnie w alpha, stanie się w pełni produkcyjne, wtedy podjęta zostanie decyzja o modelu licencyjnym lub stworzeniu płatnej wersji.

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

Spring Modulith 0.6

To na sam koniec, aby domknąć całość pewną klamrą, chciałem zwrócić uwagę na fakt, że pojawiła się nowa wersja Spring Modulith. Wersja 0.6 nie przynosi olbrzymich usprawnień (aczkolwiek wprowadza min. Wsparcie dla konceptu jmolecules), ale sam projekt jest na tyle interesujący, że warto o nim moim zdaniem przypominać.

Celem Modulitha jest bowiem wprowadzić Springa w erę majestatycznego monolitu, przyjmując do tego dość niecodzienną strategie. Zamiast mocno ingerować on w proces budowania, wykorzystuje do weryfikacji założeń architektonicznych testy integracyjne. Te odpalają ArchUnit – bibliotekę, której celem jest właśnie weryfikacja zależności między poszczególnymi modułami. Magia Modulitha polega jednak na tym, że dzięki znanemu środowisku uruchomieniowemu (aplikacje Spring Boot 3.0) jest w stanie prekonfigurować ArchUnita za użytkownika. Dzięki temu w łatwy sposób jesteśmy w stanie przetestować, czy jakieś architektoniczne spaghetti nie przemknęło przez Code Review.

To tyle na dzisiaj, ale do tematu najpopularniejszego javowego frameworku pewnie już niedługo będziemy wracać – w końcu już za tydzień wypada Spring I/O, na którym z pewnością nie zabraknie ciekawych zapowiedzi. Ktoś się wybiera może do Barcelony?

PS: Dzisiaj trochę krócej, bo zaczął się sezon konferencyjny i zamiast śledzić Javę to obserwuje, co ciekawego się dzieje na Google I/O – a jest tam tak naprawdę sporo interesującego materiału.