Symfony często opisuje się jako framework PHP, ale jego fundament stanowi około pięćdziesięciu niezależnych bibliotek. Każda rozwiązuje konkretny problem, a framework łączy je za pomocą wspólnej konfiguracji i konwencji.
Komponenty Symfony można instalować osobno przez Composer i wykorzystywać również poza aplikacjami zbudowanymi na pełnym frameworku. W tym przewodniku wyjaśniamy, za co odpowiadają najważniejsze z nich: od obsługi HTTP i architektury aplikacji po dane, asynchroniczność, bezpieczeństwo i narzędzia.
Każdy komponent Symfony jest osobną paczką, dlatego do projektu można dodać tylko te elementy, które są potrzebne. Nie trzeba korzystać z całego frameworka, żeby użyć konkretnego komponentu w aplikacji PHP.
Komponenty mają minimalne zależności. Większość z nich zależy przede wszystkim od PHP oraz odpowiednich paczek symfony/*-contracts. Contracts zawierają interfejsy bez ich implementacji, dzięki czemu kod może opierać się na abstrakcjach zamiast bezpośrednio na konkretnej implementacji Symfony.
FrameworkBundle działa natomiast jako warstwa łącząca komponenty w ramach frameworka. Dostarcza konfigurację i rejestruje usługi w kontenerze, podczas gdy same komponenty pozostają niezależnymi bibliotekami.
Komponenty Symfony można podzielić według problemów, które rozwiązują:
HTTP: HttpFoundation, HttpKernel, Routing, HttpClient;
architektura: DependencyInjection, EventDispatcher, Config, OptionsResolver, Runtime, Dotenv;
praca z danymi: Serializer, PropertyAccess, PropertyInfo, TypeInfo, Validator, Form, Yaml, JsonPath;
asynchroniczność: Messenger, Mailer, Mime, Notifier, Scheduler;
bezpieczeństwo: Security, RateLimiter, Lock, Semaphore, UID;
narzędzia: Console, Process, Filesystem, Finder, Cache, Translation, Workflow.
Komponenty HTTP w Symfony tworzą warstwę odpowiedzialną za komunikację aplikacji przez protokół HTTP. Symfony traktuje HTTP nie jako techniczny szczegół, ale jako model programowania, na którym opiera się działanie kolejnych elementów aplikacji.
HttpFoundation zamienia globalne tablice PHP związane z HTTP w obiekty reprezentujące żądanie i odpowiedź. Obsługuje również sesje, ciasteczka, negocjację formatu treści, SSE, przesyłane pliki oraz odpowiedzi strumieniowe.
Te ostatnie pozwalają pracować z dużą ilością danych, które mogą nie mieścić się w pamięci. Komponent obsługuje także odpowiedzi plikowe z możliwością wznawiania pobierania.
HttpKernel definiuje podstawową operację frameworka: przyjąć żądanie i zwrócić odpowiedź. To, co dzieje się pomiędzy tymi momentami, jest zorganizowane wokół zdefiniowanych zdarzeń, do których można podłączać się za pomocą EventDispatchera.
Routing odwzorowuje adresy URL na kod odpowiedzialny za ich obsługę, ale działa również w drugą stronę: generuje adres URL na podstawie nazwy trasy.
Dzięki temu zmiana adresu zdefiniowanego dla trasy może zostać uwzględniona w linkach generowanych przez aplikację bez ręcznej zmiany każdego z nich. Routing pozwala też konfigurować zależności związane między innymi z domeną czy językiem.
HttpClient odpowiada za wychodzące żądania HTTP. Symfony potrzebowało takiego klienta między innymi dla Mailera i Notifiera. Wprowadzenie Guzzle jako zależności frameworka oznaczałoby narzucenie konkretnej biblioteki i jej drzewa zależności, co nie odpowiadałoby modułowej architekturze Symfony.
HttpClient i Guzzle różnią się też podejściem do asynchroniczności. Guzzle wykorzystuje model oparty na promises, natomiast HttpClient strumieniuje odpowiedzi: żądanie rozpoczyna się od razu, a blokada następuje dopiero wtedy, gdy kod próbuje odczytać dane. Kod zależny od PSR-18 może działać zarówno z klientem Symfony, jak i Guzzle czy inną implementacją standardu.
Komponenty odpowiadające za architekturę aplikacji Symfony określają, jak jej poszczególne części są ze sobą połączone i jak współpracują. Obejmują tworzenie obiektów i dostarczanie zależności, komunikację przez zdarzenia, konfigurację oraz sposób uruchamiania aplikacji.
DependencyInjection dostarcza kontener usług odpowiedzialny za składanie aplikacji. Tworzy obiekty i przekazuje im potrzebne zależności, dzięki czemu nie trzeba ręcznie budować całego grafu obiektów.
Kontener wykrywa usługi na podstawie typów znajdujących się w konstruktorach i zajmuje się autokonfiguracją. Ręczna konfiguracja jest potrzebna głównie w specyficznych przypadkach. Mechanizm ułatwia również podmienianie implementacji.
EventDispatcher umożliwia komunikację pomiędzy elementami aplikacji za pomocą zdarzeń i jest implementacją wzorców obserwatora oraz mediatora.
Pozwala rozszerzać działanie aplikacji bez modyfikowania istniejącego kodu, ponieważ jej poszczególne części mogą reagować na zdarzenia bez bezpośredniego wiązania ich ze sobą. Na tym mechanizmie można budować rozszerzalne rozwiązania bez konieczności modyfikowania kodu źródłowego. W ten sposób wykorzystuje go między innymi Sylius.
Config i OptionsResolver dotyczą konfiguracji, ale działają na różnych poziomach.
Config wczytuje konfigurację, na przykład z YAML, XML lub PHP, waliduje ją względem zdefiniowanego schematu i scala wartości z wielu źródeł. Na tym mechanizmie Symfony buduje konfigurację swoich Bundle.
OptionsResolver porządkuje i waliduje tablice opcji przekazywane do kodu. Pozwala określić między innymi wymagane pola, wartości domyślne i typy, bez ręcznego sprawdzania każdego klucza.
Runtime oddziela kod aplikacji od sposobu jej uruchamiania. Ten sam kod może działać pod klasycznym PHP-FPM albo jako długo działający proces, na przykład we FrankenPHP. Runtime tłumaczy format wejściowy konkretnego środowiska na obiekty zrozumiałe dla Symfony.
Dotenv wczytuje zmienne środowiskowe z plików .env*, dzięki czemu konfiguracja może pozostawać poza kodem zgodnie z metodologią 12-Factor App. Wartości mogą zależeć od środowiska i być lokalnie nadpisywane, na przykład za pomocą .env.local.
Komponenty Symfony do pracy z danymi odpowiadają za informacje przepływające przez aplikację: dane pochodzące między innymi z formularzy i API, sprawdzanie ich poprawności oraz postać, w jakiej są zwracane na zewnątrz.
Serializer zmienia strukturę danych z jednego formatu na drugi. Udostępnia również mechanizm grup serializacji, dzięki któremu ten sam obiekt może mieć różne reprezentacje w zależności od odbiorcy.
Przykładowo zamówienie może udostępniać inny zestaw danych klientowi, administratorowi i systemowi księgowemu, bez konieczności każdorazowego tworzenia osobnego mapowania. W przypadku tego komponentu – jeden obrazek z oficjalnej dokumentacji Symfony jest wart więcej niż tysiąc słów.
To komponenty niskiego poziomu wykorzystywane przez inne części Symfony, między innymi formularze, Serializer i Validator.
PropertyAccess odczytuje i zapisuje właściwości obiektów oraz automatycznie wykrywa gettery, settery i metody takie jak addItem.
PropertyInfo pozyskuje informacje o typach między innymi z deklaracji PHP, adnotacji i mapowania Doctrine.
TypeInfo zapewnia nowszą, spójną reprezentację systemu typów PHP. Powstał w odpowiedzi na problemy i ograniczenia PropertyInfo i stopniowo zastępuje wcześniejsze rozwiązania.
Validator sprawdza, czy dane spełniają określone reguły. Obsługuje między innymi zagnieżdżone obiekty, grupy walidacyjne i reguły warunkowe.
Mechanizm opiera się na trzech elementach: Constraints reprezentujących reguły, Metadata określających ich przypisanie do pól oraz Validator Service, który wykonuje walidację i zwraca listę błędów. Validator współpracuje również z Serializerem.
Form odpowiada za cały cykl życia formularza: od jego zbudowania i renderowania, przez przyjęcie danych, po walidację i przepisanie wartości do obiektu. Jest jednym z najbardziej rozbudowanych komponentów Symfony i pozwala elastycznie dostosowywać formularze do potrzeb aplikacji.
Formularze definiuje się jako osobne klasy, dzięki czemu można wykorzystywać je w różnych miejscach aplikacji. Komponent obsługuje także ochronę przed CSRF oraz dodatkowe pola, których nie ma w definicji FormType. Korzysta przy tym między innymi z Validatora, OptionsResolvera, PropertyAccess i TypeInfo.
Yaml jest parserem i generatorem formatu YAML. Konwertuje YAML na tablice PHP i odwrotnie. Obsługuje również elementy specyficzne dla Symfony, takie jak %env(DATABASE_URL)% czy stałe PHP zapisane z użyciem !php/const.
JsonPath służy do pobierania konkretnych danych z głębokich struktur JSON lub YAML za pomocą zapytań tekstowych. Działa na podobnej zasadzie jak XPath w przypadku XML.
Asynchroniczne przetwarzanie w Symfony pozwala wykonywać część operacji poza podstawowym cyklem żądanie-odpowiedź. Obejmuje zadania działające w tle, kolejki, wysyłkę wiadomości i harmonogramy. Pozwala między innymi skrócić czas obsługi żądania, celowo opóźnić wykonanie operacji albo sprawić, że chwilowa niedostępność systemu po drugiej stronie spowoduje opóźnienie zamiast utraty danych.
Messenger służy do asynchronicznego przetwarzania zadań i obsługi wiadomości w architekturze kolejek. Pozwala przenieść cięższe lub czasochłonne operacje, takie jak np. generowanie PDF, poza obsługę żądania HTTP i wykonać je w tle.
Obsługuje różne systemy transportowe, między innymi RabbitMQ, Redis, Amazon SQS i tabelę w bazie danych, a także ponawianie nieudanych prób z rosnącym opóźnieniem oraz opóźnione dostarczanie wiadomości.
Mime tworzy obiekty wiadomości e-mail i odpowiada między innymi za nagłówki, kodowanie znaków oraz załączniki.
Mailer zajmuje się wysłaniem przygotowanej wiadomości przez SMTP lub API dostawców takich jak Mailgun, SendGrid czy Amazon SES. Integruje się również z Messengerem, dzięki czemu wysyłkę można przenieść do kolejki.
Notifier pozwala wysyłać powiadomienia przez różne kanały z poziomu jednego interfejsu. Zamiast tworzyć osobne mechanizmy dla e-maili, SMS-ów czy Slacka, aplikacja może korzystać z jednej usługi, a kanał dobierać zależnie od wagi zdarzenia i preferencji odbiorcy.
Scheduler służy do wykonywania cyklicznych zadań i pozwala definiować harmonogram w kodzie PHP zamiast przechowywać go w całości w systemowym Cronie.
Harmonogram może dzięki temu być wersjonowany, testowany i utrzymywany w spójny sposób w różnych środowiskach. W takim podejściu w systemie Linux wystarczy jedno główne zadanie Cron uruchamiające workery Messengera, a godziny i częstotliwość wykonywania poszczególnych zadań określa się w kodzie aplikacji.
Komponenty związane z bezpieczeństwem w Symfony rozdzielają kilka różnych odpowiedzialności: ustalenie, kim jest użytkownik, określenie, co może zrobić, kontrolowanie częstotliwości wykonywania operacji oraz ich równoczesnego wykonywania. Symfony udostępnia do tych zadań osobne komponenty.
Security odpowiada za uwierzytelnianie i autoryzację. Uwierzytelnianie określa, kim jest użytkownik, a autoryzacja, co może zrobić. Komponent dostarcza mechanizmy realizujące oba zadania, między innymi z wykorzystaniem formularzy, JWT czy OAuth.
RateLimiter ogranicza liczbę żądań, które użytkownik lub określony adres IP może wykonać w zadanym czasie. Mechanizm może służyć między innymi do ochrony przed botami i atakami brute-force.
Lock zapewnia, że określoną operację wykonuje tylko jeden proces w tym samym czasie, rozwiązując problem race conditions.
Semaphore pozwala określić większy limit procesów, które mogą wykonywać daną operację równocześnie. Może być używany między innymi podczas komunikacji z zewnętrznym API z limitem połączeń lub przetwarzania zadań w tle przez Messengera.
UID służy do generowania unikalnych identyfikatorów UUID i ULID. Identyfikator może powstać po stronie aplikacji jeszcze przed zapisaniem danych w bazie, a publiczne adresy nie muszą ujawniać liczby rekordów w systemie.
Oba formaty są sortowalne i zapobiegają fragmentacji indeksów B-Tree. Od Symfony 7.4 domyślną wersją podczas tworzenia UUID jest UUID v7.
Ta grupa komponentów Symfony obejmuje narzędzia potrzebne do wykonywania różnych zadań poza podstawową obsługą żądania. Pozwalają między innymi uruchamiać zadania z konsoli, pracować z plikami, uruchamiać zewnętrzne programy oraz zapamiętywać wyniki kosztownych operacji do ponownego wykorzystania.
Console pozwala tworzyć interfejsy wiersza poleceń w PHP. Za jego pomocą można budować własne komendy automatyzujące zadania, takie jak cykliczny import danych, generowanie raportów lub feedu czy anulowanie niezapłaconych zamówień.
Komponent obsługuje także paski postępu dla długich operacji oraz pytania kierowane do użytkownika podczas wykonywania skryptu.
Process pozwala uruchamiać i kontrolować zewnętrzne programy i komendy systemowe. Obsługuje limit czasu, bieżący odczyt danych wyjściowych oraz tryb asynchroniczny.
Dostarcza obiektowy interfejs zastępujący natywne funkcje PHP, takie jak exec(). Z kodu PHP można dzięki niemu uruchomić na przykład zewnętrzne narzędzie generujące PDF albo skrypt w Pythonie, zachowując kontrolę nad błędami.
Finder wyszukuje pliki i katalogi według określonych kryteriów. Filesystem wykonuje na systemie plików operacje, takie jak tworzenie katalogów, kopiowanie i usuwanie danych czy tworzenie linków symbolicznych.
Filesystem zapewnia takie samo działanie niezależnie od systemu operacyjnego, dzięki czemu ten sam kod może działać na serwerze Linux i lokalnym komputerze z Windows.
Cache może przechowywać wyniki kosztownych operacji, aby można było wykorzystać je ponownie. Mogą to być odpowiedzi z API, dane z bazy, kosztowne obliczenia procesorowe czy operacje na plikach.
Symfony Cache implementuje PSR-6 i udostępnia również własny interfejs oparty na podejściu „pobierz i oblicz”.
Translation służy do tworzenia aplikacji wielojęzycznych. Obsługuje między innymi liczbę mnogą zgodnie ze standardem ICU i może współpracować z zewnętrznymi systemami lokalizacyjnymi, takimi jak Lokalise.
Workflow zarządza cyklem życia obiektów poprzez modelowanie procesu biznesowego jako maszyny stanów. Logika jest definiowana za pomocą stanów (places) i przejść (transitions).
Komponent pilnuje, aby obiekt nie zmienił stanu w niedozwolony sposób, a podczas zmian może automatycznie wyzwalać zdarzenia. Pozwala również wizualizować proces w postaci schematu blokowego. W Syliusie jest intensywnie wykorzystywany między innymi przy cyklu życia zamówienia i zwrotach.
Komponenty Symfony to niezależne biblioteki PHP rozwiązujące konkretne problemy aplikacyjne. Można instalować je osobno przez Composer i wykorzystywać również poza aplikacjami zbudowanymi na pełnym frameworku Symfony.
Tak. Każdy komponent jest osobną paczką, dlatego można zainstalować tylko te elementy, których potrzebuje dany projekt. FrameworkBundle łączy komponenty w ramach frameworka, ale same komponenty pozostają niezależnymi bibliotekami.
Komponenty Symfony można podzielić na kilka obszarów: obsługę HTTP, architekturę aplikacji, pracę z danymi, asynchroniczność, bezpieczeństwo oraz narzędzia. Należą do nich między innymi HttpFoundation, HttpKernel, Routing, DependencyInjection, Serializer, Form, Messenger, Security i Console.
Za różne elementy komunikacji HTTP odpowiadają HttpFoundation, HttpKernel, Routing i HttpClient. HttpFoundation reprezentuje żądania i odpowiedzi jako obiekty, HttpKernel organizuje przebieg obsługi żądania, Routing łączy adresy URL z kodem aplikacji, a HttpClient służy do wykonywania wychodzących żądań HTTP.
Messenger służy do obsługi wiadomości i asynchronicznego przetwarzania zadań w architekturze kolejek. Obsługuje różne systemy transportowe, ponawianie nieudanych prób oraz opóźnione dostarczanie wiadomości.
Commerce Weavers bierze na siebie budowę modułu finansowego Open Mercato. Pierwsza iteracja obejmuje plan kont i księgę ...
Czytaj więcej →
Wybór frameworka może wyglądać jak decyzja czysto techniczna. W praktyce wpływa jednak na znacznie więcej niż sposób, w ...
Czytaj więcej →
AI w developmencie e-commerce coraz mocniej wchodzi do codziennej pracy zespołów developerskich. Pomaga generować kod, p...
Czytaj więcej →
