Bevezetés

A JPA, új nevén Jakarta Persistence egy szabvány, mely relációs adatbázisok elérését teszi lehetővő, object-relational mapping (ORM) használatával. Ennek különböző implementációi vannak, talán a legelterjedtebb a Hibernate. A Jakarta Persistence-re épül a Spring Data JPA, ami a repository mintát valósítja meg, valamint újabb lehetőségeket is az a JPA-hoz.

A JPA azonban nem fejlődik olyan dinamikusan, valamint több megszorítás, illetve kényelmetlenség is van benne.

Kényelmetlen a Criteria API használata, valamint korlátozott a DTO-k kezelése. Valamint nem támogat olyan hatékony SQL megoldásokat, mint a Window Functions vagy a Common Table Expression (CTE).

Ezeken egyrészt próbál segíteni a konkrét implementáció, mint pl. a Hibernate. (Ekkor persze elszakadunk a szabványtól.) Valamint a Spring Data JPA-val is több problémát próbál orvosolni. Vagy választhatjuk a mindkét előbbi technológiához jól illeszkedő Blaze-Persistence-t is kiegészítésül, mely további lehetőségeket rejt.

A példa alkalmazás forráskódja megtalálható a GitHubon.

Következő videóm témája, hogy egy modularizált alkalmazás felépítésekor az eseménykezelés segít nekünk abban, hogy a modulok lazán kapcsolódjanak egymáshoz. A Spring Modulith ezt kiegészíti, biztosabbá teszi a hiba- és tranzakciókezelést, valamint képes ezeket az eseményeket más service-ek felé is elküldeni valamilyen message brokeren keresztül.

Lesz szó modularizált alkalmazásról, eseménykezelésről, Spring Modulithról, tranzakciókezelésről, Testcontainersről, Kafkáról.

A példa alkalmazás forráskódja megtalálható a GitHubon.

A Spring Modulit modulkezeléséről írtam korábban egy posztot Modularizált alkalmazás fejlesztése a Spring Modulith-tal címmel.

A poszt végén a videóhoz képest extra tartalom is van.

Megjelent az első videóm, melynek témája, hogy hogyan lehet használni a Testcontainers-t Spring Boot alkalmazásban.

A videóhoz a forráskód is elérhető a GitHubon.

Ha valaki mégis a szöveges tartalomhoz ragaszkodik, olvasson tovább.

A Spring Boot 3.3 verzióban tovább egyszerűsítették az OAuth 2.0 integrációt. Az előző verziók esetén, amennyiben a JWT tokenben a felhasználónév nem a sub claim alatt szerepelt, saját magunk kellett ezt kiolvasni, pl. egy saját JwtDecoder bean megadásával. Amennyiben a JWT token tartalmazta a szerepköröket is, saját JwtAuthenticationConverter beant kellett felvennünk, mely képes volt a szerepkörök kiolvasására.

Erre a Spring Boot 3.3 verziótól kezdve nincs szükség, hiszen beállíthatjuk ezt az application.properties állományban, és a Spring Boot automatikusan konfigurál egy JwtAuthenticationConverter (vagy reaktív esetben egy ReactiveJwtAuthenticationConverter beant).

Ezt is említettem a XV. Pécs IT Meetupon. A meghívást ezennel is köszönöm a Kovács Bálintnak, a meetup egyik szervezőjének, aki többedmagával a Webstar céget is képviselte.

Napjainkban a telemetria egy nagyon fejlődő terület, napról napra jelennek meg új eszközök és szabványok, melyeket igen nehéz nyomonkövetni. Ez a poszt ebben szeretne egy kis rendet tenni, hiszen úgy lehet valamit a legjobban megismerni, hogyha másoknak elmagyarázod.

A telemetria (telemetry) klasszikusan egy rendszer különböző elemein mérési adatok előállítása és továbbítása egy központi helyre. Ennek célja, hogy a múltbéli és jelenlegi adatok elemzésével meg lehessen bizonyosodni a rendszer helyes működéséről, észlelni, esetleg előre jelezni lehessen annak hibáit. Erre különböző eszközöket és folyamatokat használunk, melyek biztosítják a rendszer folyamatos megfigyelhetőségét (observability).

Szoftverrendszer esetén is pontosan erről van szó, különböző mérési adatokat állítunk elő különböző szinteken, pl. operációs rendszer szinten mérjük a CPU, memória és lemezhasználatot, de alkalmazás/szolgáltatás szinten mérhető a bejelentkezett felhasználók, beérkező kérések, tranzakciók száma, válaszidők. Ezen adatokból kinyert információkból következtethetünk a szoftver állapotára, hibára. A túl magas válaszidő biztos valami problémára utal, de az rossz jel lehet, ha hirtelen lecsökken a tranzakciószám.