Dzięki za komentarz! Racja! Można było odmienić po polsku, żeby jeszcze lepiej przedstawić ideę. 😊 Może jeszcze jakiś filmik się pojawi z tą architekturą, to wtedy na pewno to zrobię! :D
Kurczak, ciężko mi coś konkretnego polecić, ja akurat mam okazję tworzyć projekt z wykorzystaniem tej architektury, więc na co dzień zdobywam doświadczenie z nią związane bardziej na placu boju, analizując napotkane wyzwania. Mam na swojej liście do przeczytania książkę "Building Multi-Tenant SaaS Architectures", jednak jeszcze nie przeczytałem, więc nie wiem, czy jest godna polecenia, ale w tym roku chcę po nią sięgnąć :D Wiem, że za dużo nie pomogłem, ale jeśli sobie coś przypomnę, to dam znać!
Jak można rozwiązać problem podziału mikroserwisu na read write w Javie a potem kwestie datasource sourtingu? Baza danych jest postgres oparta o master slave
Dzięki za komentarz! Ciężko będzie mi tu jakoś ładnie odpisać, ale może coś się przyda :D . W skrócie, Spring udostępnia nam klaske AbstractRoutingDataSource (możemy po niej dziedziczyć), umożliwia ona konfigurację jednego dynamicznego dataSource dla zarówno master, jak i slave. Czyli rejestrujemy dwa datasource master i slave i tworzymy z nich jeden dynamiczny datasource. Wtedy będziemy mieli jakiś routingKey, aby dynamicznie wybierać, czy operacje mają trafić do master czy slave. Aby umożliwić Springowi decydowanie, do którego detasource ma trafić dane zapytanie, możemy stworzyć własną adnotację i oznaczać ją nad metodami i użyć AOP do przechwycenia wywołań metod, decydując wtedy, który dataSource powinien być użyty dla danego wywołania (jeśli jej nie będzie to znaczy że ma lecieć do mastera). Nie znam twojego przypadku, ale warto też rozważyć zastosowanie CQRS do replikacji danych. Pozwala to na dostosowanie modelu odczytu do potrzeb związanych z odczytem, niezależnie od modelu zapisu ( np inne struktury danych, inaczej ułożone dane, inne indeksy itp). Model odczytu może być nawet zasilany z kilku różnych źródeł danych. Oczywiście, możliwe że CQRS nie jest dla twojego case, ale zawsze warto wziąć pod uwagę :D
Kolejny filmik już jest nagrany - będzie o błędach w projektowaniu REST API (ale takich bardziej zaawansowanych). Nie będzie tam zbyt dużo kodu, bo to bardziej "projektanckie" tematy, ale mam nadzieję, że też się przydadzą, bo to rzeczy, które mogą ułatwić żyćko. 😊 Potem jednak chcę wrócić do serii związanej z taktycznym DDD, bo zostało tam jeszcze trochę do omówienia, więc znów będzie kodowanie! 🚀
Super filmik! Po urlopie rozsyłam mojej ekipie :) Czy tutaj nadal adekwatne jest stwierdzenie "najlepszą dokumentacją jest kod"? Czy spotkałeś się z jakąś dobrą praktyką opisywania takiej architektury np. dlaczego została wybrana taka i taka oraz w formie dokumentacji żeby szybciej wprowadzać osoby nowe do niej?
Dzięki wielkie za komentarz i chęć rozesłania - to zawsze zachęca do tworzenia nowych treści! Osobiście jestem zwolennikiem dokumentacji możliwie najbliżej kodu, najlepiej, gdy jest generowana automatycznie z kodu lub gdy kod generuje się na podstawie dokumentacji, bo wtedy zawsze jest aktualna. Ale jeśli chodzi o decyzje architektoniczne, czyli co było rozważane przy podejmowaniu decyzji i dlaczego akurat zostało wybrane to rozwiązanie, np. jedna baza, ale osobny schemat per tenant, to polecam Architecture Decision Record (ADR). Można je również trzymać na repozytorium z kodem i pisać w formacie .md. Dzięki temu później wiadomo, jaki był stan wiedzy i możliwości. To w sumie fajny temat na odcinek, więc może uda mi się to jakoś przedstawić, dzięki za zalążek pomysłu!.
Dzięki wielkie za komentarz! Będzie sporo tematów bardziej ogólnych, np. następny odcinek będzie o tipach przy projektowaniu REST API, więc też ogólne :D Oczywiście tematy strikte Javowe też będą się pojawiać, bo nazwa kanału zobowiązuje, ale myślę, że każdy znajdzie coś dla siebie :D
Coraz lepsze materiały robisz - Gratulacje i powodzenia w kolejnych materiałach!
Dzięki wielkie!
Łapa w górę i oglądamy!
Dzięki! I do usłyszenia!
Mega, jak zawsze 🎉❤
Dzięki wielkie!
Kolejny świetny materiał, dzięki za to co robisz!
Dzięki za miłe słowo!
Super film :) W porównaniu do bloku dodałbym zdanko, że w sumie tenant to po polsku właśnie 'najemca', więc jak najbardziej na miejscu.
Dzięki za komentarz! Racja! Można było odmienić po polsku, żeby jeszcze lepiej przedstawić ideę. 😊 Może jeszcze jakiś filmik się pojawi z tą architekturą, to wtedy na pewno to zrobię! :D
Dobrze wyjaśnione i świetny materiał! :D
Dzięki wielkie!
Dzięki za wartościowy materiał, czy mógłbyś polecić jakieś materiały rozwijające ten i pokrewne tematy?
Kurczak, ciężko mi coś konkretnego polecić, ja akurat mam okazję tworzyć projekt z wykorzystaniem tej architektury, więc na co dzień zdobywam doświadczenie z nią związane bardziej na placu boju, analizując napotkane wyzwania. Mam na swojej liście do przeczytania książkę "Building Multi-Tenant SaaS Architectures", jednak jeszcze nie przeczytałem, więc nie wiem, czy jest godna polecenia, ale w tym roku chcę po nią sięgnąć :D Wiem, że za dużo nie pomogłem, ale jeśli sobie coś przypomnę, to dam znać!
Jak można rozwiązać problem podziału mikroserwisu na read write w Javie a potem kwestie datasource sourtingu? Baza danych jest postgres oparta o master slave
Dzięki za komentarz! Ciężko będzie mi tu jakoś ładnie odpisać, ale może coś się przyda :D .
W skrócie, Spring udostępnia nam klaske AbstractRoutingDataSource (możemy po niej dziedziczyć), umożliwia ona konfigurację jednego dynamicznego dataSource dla zarówno master, jak i slave.
Czyli rejestrujemy dwa datasource master i slave i tworzymy z nich jeden dynamiczny datasource. Wtedy będziemy mieli jakiś routingKey, aby dynamicznie wybierać, czy operacje mają trafić do master czy slave.
Aby umożliwić Springowi decydowanie, do którego detasource ma trafić dane zapytanie, możemy stworzyć własną adnotację i oznaczać ją nad metodami i użyć AOP do przechwycenia wywołań metod, decydując wtedy, który dataSource powinien być użyty dla danego wywołania (jeśli jej nie będzie to znaczy że ma lecieć do mastera).
Nie znam twojego przypadku, ale warto też rozważyć zastosowanie CQRS do replikacji danych. Pozwala to na dostosowanie modelu odczytu do potrzeb związanych z odczytem, niezależnie od modelu zapisu ( np inne struktury danych, inaczej ułożone dane, inne indeksy itp). Model odczytu może być nawet zasilany z kilku różnych źródeł danych. Oczywiście, możliwe że CQRS nie jest dla twojego case, ale zawsze warto wziąć pod uwagę :D
Kiedy kolejne filmy? Prośba o więcej filmów z pisania kodu
Kolejny filmik już jest nagrany - będzie o błędach w projektowaniu REST API (ale takich bardziej zaawansowanych). Nie będzie tam zbyt dużo kodu, bo to bardziej "projektanckie" tematy, ale mam nadzieję, że też się przydadzą, bo to rzeczy, które mogą ułatwić żyćko. 😊 Potem jednak chcę wrócić do serii związanej z taktycznym DDD, bo zostało tam jeszcze trochę do omówienia, więc znów będzie kodowanie! 🚀
Super filmik! Po urlopie rozsyłam mojej ekipie :)
Czy tutaj nadal adekwatne jest stwierdzenie "najlepszą dokumentacją jest kod"? Czy spotkałeś się z jakąś dobrą praktyką opisywania takiej architektury np. dlaczego została wybrana taka i taka oraz w formie dokumentacji żeby szybciej wprowadzać osoby nowe do niej?
Dzięki wielkie za komentarz i chęć rozesłania - to zawsze zachęca do tworzenia nowych treści!
Osobiście jestem zwolennikiem dokumentacji możliwie najbliżej kodu, najlepiej, gdy jest generowana automatycznie z kodu lub gdy kod generuje się na podstawie dokumentacji, bo wtedy zawsze jest aktualna.
Ale jeśli chodzi o decyzje architektoniczne, czyli co było rozważane przy podejmowaniu decyzji i dlaczego akurat zostało wybrane to rozwiązanie, np. jedna baza, ale osobny schemat per tenant, to polecam Architecture Decision Record (ADR). Można je również trzymać na repozytorium z kodem i pisać w formacie .md. Dzięki temu później wiadomo, jaki był stan wiedzy i możliwości. To w sumie fajny temat na odcinek, więc może uda mi się to jakoś przedstawić, dzięki za zalążek pomysłu!.
Nazwa kanału trochę odstrasza nie-javowców, ale content fajny :P
Dzięki wielkie za komentarz!
Będzie sporo tematów bardziej ogólnych, np. następny odcinek będzie o tipach przy projektowaniu REST API, więc też ogólne :D
Oczywiście tematy strikte Javowe też będą się pojawiać, bo nazwa kanału zobowiązuje, ale myślę, że każdy znajdzie coś dla siebie :D
jak zwykle pelna klasunia, pozdrawiam serdecznie. :D
Dzięki wielkie! Do usłyszonka!
Łapa w górę i oglądamy!
Dzięki!