Symfony czy Drupal: kiedy warto wybrać Symfony do projektu webowego

To pytanie pojawia się regularnie, szczególnie gdy firma planuje nowy projekt webowy i ktoś w zespole zna Drupala, a ktoś inny pracował z Symfony. Odpowiedź zależy od tego, co właściwie budujesz, i warto to rozróżnienie zrozumieć zanim zaczniemy rozmawiać o konkretnym frameworku lub CMS-ie.

Czym jest Symfony, a czym Drupal

Symfony to framework PHP. Daje narzędzia do budowania aplikacji webowych, ale nie narzuca żadnej struktury treści, żadnego panelu administracyjnego ani gotowego modelu danych. Zaczynasz praktycznie od zera i budujesz dokładnie to, czego potrzebuje projekt.

Drupal to system zarządzania treścią zbudowany na Symfony. Ma wbudowany model typów treści, zarządzanie użytkownikami, edytor stron, system modułów i wiele innych rzeczy gotowych od startu. To nie jest ten sam poziom abstrakcji: Drupal rozwiązuje problem “muszę zarządzać treścią na stronie”, Symfony rozwiązuje problem “muszę zbudować aplikację webową”.

Zadanie “symfony czy drupal” brzmi jak pytanie o wybór między dwoma konkurentami, ale w praktyce to pytanie o to, jakiego rodzaju system budujesz.

Kiedy Drupal ma sens

Drupal sprawdza się, gdy projekt jest w dużej mierze redakcyjny. Wiele typów stron, wiele redaktorów, złożone relacje między treściami, wielojęzyczność i potrzeba zarządzania tym przez osoby bez wiedzy technicznej. Organizacje mediowe, duże portale korporacyjne, systemy dokumentacji, serwisy rządowe, platformy wiedzy z dziesiątkami kategorii treści.

Gotowy ekosystem modułów Drupala skraca czas pierwszego wdrożenia w tych scenariuszach znacząco. Wielojęzyczność, zarządzanie wersjami treści, zaawansowane uprawnienia redakcyjne. To wszystko jest w Drupalu z pudełka.

Kiedy wybrać Symfony zamiast Drupala

Symfony wygrywa tam, gdzie logika biznesowa jest bardziej złożona niż zarządzanie treścią. Jeśli budujesz platformę sprzedażową B2B z własnym modelem zamówień, system integracji z ERP, API backend dla aplikacji mobilnej, kalkulator cen z niestandardowymi regułami albo sklep z zaawansowanym konfiguratorem produktów, to Symfony daje swobodę, której Drupal nie oferuje bez walki.

W Drupalu każde odejście od standardowego modelu treści wiąże się z obejściami i hackingiem modułów. Im bardziej projekt odbiega od “zarządzam treścią na stronie”, tym bardziej Drupal staje się przeszkodą zamiast pomocą.

Symfony pozwala zaprojektować model danych pod konkretny problem, zintegrować dowolne zewnętrzne systemy w naturalny sposób i utrzymywać projekt bez walki z narzuconą przez platformę strukturą.

Symfony w projektach B2B i e-commerce

W projektach e-commerce B2B Symfony pojawia się najczęściej jako backend platformy sprzedażowej lub warstwa API. Frameworki takie jak API Platform (zbudowane na Symfony) pozwalają szybko budować solidne API REST i GraphQL z walidacją, dokumentacją i obsługą uprawnień bez pisania wszystkiego od zera.

Wiele platform e-commerce, w tym Sylius z naszego portfolio, jest zbudowanych na Symfony. Możliwość bezpośredniego rozszerzania logiki na poziomie frameworka, a nie tylko przez wtyczki, to coś, czego nie da się przecenić przy złożonych wymaganiach B2B.

Pracujemy na Symfony przy budowie platform sprzedażowych B2B, dedykowanych aplikacjach i PWA oraz projektach wymagających głębokiej integracji z systemami zewnętrznymi. Szczegóły techniczne i projekty opisujemy na stronie technologii Symfony.

Co decyduje o wyborze w praktyce

Zanim padnie decyzja, zadajemy kilka pytań: czy treść jest rdzeniem projektu czy tylko jednym z jego elementów? Ilu redaktorów będzie pracować w systemie i jakiego interfejsu potrzebują? Czy logika biznesowa jest na tyle specyficzna, że gotowy CMS będzie ją ograniczać?

Jeśli odpowiedzi wskazują na CMS jako główną potrzebę, Drupal jest sensowną rozmową. Jeśli projekt to przede wszystkim aplikacja z własną logiką, katalogiem produktów, procesem zamówień lub integracjami z kilkoma systemami zewnętrznymi, wybór Symfony oszczędza wielu problemów w przyszłości.

W naszym doświadczeniu projekty, które zaczynają od Drupala “bo szybko na start”, często wracają z prośbą o migrację po roku lub dwóch, gdy wymagania urosły poza to, co CMS wygodnie obsługuje.