Jako programiści lubimy dyskutować nad tym, czy nasz kod wygląda dobrze. Zastanawiamy się, czy da radę go re-używać oraz zrozumieć. Niestety, nie podejmujemy zbyt wiele dyskusji na temat tego, czy aplikacje, które tworzymy mają odpowiedni performance. Zatem dziś jak podejrzewacie, będzie właśnie o performance.
Symfony Messenger jest świetny. Zgodzicie się? Instalujecie jedną paczkę i możecie wysłać wiadomość na kolejkę… oh wait. No jednak nie. Chociaż nie jest to tak trywialne jak w Doctrine, to jest to dosyć proste, o czym będzie dzisiejszy post.
W poprzednim wpisie zajmowaliśmy się tematem przetwarzania asynchronicznego wiadomości za pomocą komponentu Symfony Messenger. Czy wiecie, że Messenger służy również do komunikacji dwóch mikroserwisów ze sobą? Nie? No to zaraz się dowiecie 😉
To, że Symfony Messenger jest niezastąpiony, wszyscy wiedzą. Za to, jak go skonfigurować – niekoniecznie. Z tego powodu właśnie powstał dzisiejszy post. Skonfigurujmy razem messengera, aby przeprocesował komendę asynchronicznie! 🙂
Wszyscy dookoła mówią, że encje powinny zawierać wyłącznie logikę biznesową, a nie settery. Niby wszyscy to wiedzą, ale każdy i tak robi te settery. Ja wiem, dlaczego tak się dzieje i z chęcią Wam o tym opowiem 🙂
Tworzenie aplikacji biznesowych z grubsza polega na definiowaniu procesów, które mają za zadanie w określony sposób przetwarzać zapisane w systemie dane. Część z tych danych posiada swój stan (jeden z wielu), który zmienia sposób interpretacji zawartych wewnątrz informacji. Tematem dzisiejszego wpisu jest więc Maszyna Stanów – wzorzec, który upraszcza dużo w poruszonej wyżej kwestii.
Niezależnie od tego, z którego frameworka korzystamy, zawsze powinniśmy promować własną refleksję ponad wszystko. Nawet pracując w Symfony, który uchodzi za najlepsze narzędzie w swojej kategorii, jesteśmy w stanie stworzyć niefajny kod. Dziś poruszymy temat reprezentatywnego przykładu, który potwierdza tą tezę.
Umiejętność praktycznego korzystania z wzorców projektowych jest czymś, co spłaca się bardzo szybko. Wzorce właśnie po to są – aby rozwiązywać problemy, z którymi się spotykamy na co dzień, bez odkrywania koła na nowo. Spójrzmy zatem na dwa świetnie pracujące ze sobą wzorce – fasady i strategii – w oparciu o dosyć standardowy scenariusz biznesowy.
W trakcie działania aplikacji biznesowych niejednokrotnie wiele się dzieje. Wielokrotnie zmieniamy stan systemu, o czym dobrze by było np. poinformować inne systemy bądź wysłać maila. Jednym, z bardzo dobrych do tego celu wzorców, jest architektura sterowana zdarzeniami, o której właśnie będzie ten wpis.
Tworząc skomplikowane systemy bardzo często sięgamy do architektury mikroserwisowej. Im więcej serwisów, tym większa również potrzeba komunikacyjna między nimi. Przyjrzyjmy się zatem jednej z form komunikacji systemów, jaką jest obsługa systemów kolejkowych za pomocą komponentu Symfony Messenger.