Doctrine, jako bardzo zaawansowane narzędzie, posiada bardzo dużo mechanizmów, które należałoby poznać zarówno od strony teoretycznej jak i w boju. Okazuje się, że niektóre z tych funkcjonalności – pomimo, że służą do podobnych celów – mogą się wzajemnie wykluczać. Niestety, niezbyt wiele osób wie, że właśnie tak jest z funkcjami Doctrine Schema oraz Migration. Dlatego właśnie powstał ten wpis.
We wpisie o Lazy Loadingu wspomniałem, aby pobierać wszystko, czego potrzebujemy, na raz. Słowem-kluczem tutaj są słowa „czego potrzebujemy”. Z perspektywy działania aplikacji wydaje nam się, że do konkretnych operacji potrzebujemy pełnego zestawu danych. O tym, że czasami można taniej – jest dzisiejszy wpis.
Najsłabszym ogniwem większości aplikacji jest baza danych. Praca na domyślnej konfiguracji Doctrine tylko pogłębia ten problem. Znajomość podstawowych procesów optymalizacji oraz zasady ich działania powinny być wiedzą ogólnodostępną. Dlatego dziś poruszymy klasyka, jakim jest Doctrine Eager fetch mode, czy jak kto woli – Doctrine Eager loading.
Większość świeżych programistów, którzy pytają tych starszych o porady, słyszą: „Ucz się Symfony, Doctrine i pisz testy”. A młodzi przyjmują to za świętość i uczą się. Znają podstawowe pojęcia, po czym wchodzą na projekt, napiszą endpoint dla dużego zestawu danych i… całość wykonuje się w 13 sekund. Ta historia, choć nieco przeze mnie ufarbowana, wydarzyła się całkiem niedawno. I z chęcią podzielę się z Wami kilkoma szczegółami oraz wnioskami z tej sprawy 🙂
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ę.
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.