Wchodząc w świat Symfony niektóre rzeczy robimy z automatu, bo tak jest w dokumentacji. Nie zawsze zdajemy sobie sprawę z tego, o co tak na prawdę chodzi z pewnymi detalami. Jednym z takich detali jest token CSRF, który na pierwszy rzut oka wydaje się uciążliwy. Ale jest ważny, o czym będę pisał dzisiaj.
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! 🙂
Warstwa domeny w Domain Driven Design jest prawdziwą wisienką na torcie. Powinniśmy dbać o nią, aby zawsze była czysta. Dziś przedstawię Wam kilka heurystyk, których stosowanie spowoduje, że Wasza domena nabierze barw 🙂
Aby nasz kod mógł być czysty, twórcy frameworków muszą się nieraz porządnie nagimnastykować. Dobrym tego przykładem jest biblioteka Doctrine, która skrywa wiele bardzo ciekawych technik. Jedną z nich jest wykorzystywanie tzw. klas Proxy, którym poświęcam dzisiejszy wpis.
Encje są bardzo kontrowersyjnym tematem. Z jednej strony, są to klasy, które żyją niejako w odseparowaniu od Doctrine. Z drugiej strony, to Doctrine zarządza tym, kiedy, gdzie i jak encja powstaje. Dzieje się tam pod spodem trochę magii, którą, w dzisiejszym wpisie, postaram się nieco prześledzić.
System zdarzeń jest jednym z fajniejszych wzorców projektowych. Nie dość, że jest on zgodny z SOLID (bo rozszerzamy), to dodatkowo jest on łatwo testowalny. Niestety, czasami możemy przeszarżować, zwłaszcza, jeżeli chodzi o nasłuchiwanie zdarzeń, które oferuje nam Doctrine 2. Poznajcie kilka wskazówek, dzięki którym (mam nadzieję) pozbędziecie się potencjalnych problemów w przyszłości.
Podczas tworzenia aplikacji biznesowych, nie sposób nie poruszyć tematu aktualizacji bazy danych – elementu, z którym spotykamy się w codziennej pracy. Niezależnie od typu środowiska, zawsze trafimy na temat migracji bazy danych. Na szczęście Doctrine posiada specjalnie do tego wyspecjalizowany mechanizm, którego najważniejsze elementy poruszymy w tym wpisie.