Symfony 4 – Jak przejść na nową wersję i grać w back-end orkiestrze

2 listopada 2018
Sebastian Łuczak

Wkrótce minie 12 miesięcy od wprowadzenia nowej wersji Symfony. Czwarta odsłona tego popularnego framework’a to z jednej strony spory krok naprzód, a z drugiej szereg ważnych zmian, z którymi jako programiści musimy się zmierzyć. Co zrobić, żeby bezboleśnie przesiąść się z poprzedniej wersji na aktualną i dalej grać razem z back-endową orkiestrą? Przyjrzyjmy się temu razem.

Bogata dokumentacja, świetne wsparcie rozbudowanej społeczności, dojrzała struktura, czy jeszcze lepsza integracja z innymi rozwiązaniami, takimi jak, chociażby silnik szablonów Twig. Jest wiele powodów, dla których uważamy, że warto pisać o Symfony. Jednak do najważniejszych z nich należy zastosowanie w budowie produktów online – stron internetowych, webowych aplikacji, czy systemów CMS.

I chociaż wyznawcy Pythona mogą się zżymać i wyzywać PHP od spaghetti code, to dla nas jest to świetne narzędzie, między innymi dla dostarczania MVP po zakończeniu warsztatów projektowania produktu. Jednak spokojnie – zacznijmy od początku.

Bez paniki

W tym artykule zabierzemy się za podsumowanie wszystkich ważnych zmian wprowadzonych w Symfony 4. Co, jeśli nie pracowałeś wcześniej na poprzedniczce – Symfony 3? Nic straconego! Pełna dokumentacja jest dostępna tutaj – znajdziesz w niej kompletny przewodnik prowadzący przez cały framework, nie zostawiający cię z żadnymi niewiadomymi.

Zdążyliśmy już wspomnieć o bogatej dokumentacji i nie było to dziełem przypadku. Dodatkowe materiały wraz z pełną referencją API możesz znaleźć tutaj, natomiast odpowiedzi na nurtujące cię pytania szukaj na StackOverflow.

Ułatwienie życia programisty

Czym zatem jest nowa wersja Symfony? Z jednej strony można powiedzieć, że Symfony 4.2 to Symfony 3.4 tylko, że z usuniętymi przestarzałymi zależnościami. Jednak w szerszej perspektywie, czwarta odsłona framework’a PHP to wielki krok naprzód.

Dlaczego? Ponieważ większość zmian – począwszy od procesu instalacji, poprzez użycie pakietów do struktury katalogów, aż po sam proces pisania kodu – została wprowadzona, żeby ułatwić życie programisty i zautomatyzować podstawowe prace.

Tak duży system, jakim jest Symfony może służyć do budowy aplikacji internetowych klasy Enterprise tak samo łatwo, jak do tworzenia małych wersji MVP i prostych aplikacji konsolowych. Jednak na pierwszy rzut oka ten ogromny potencjał może nie wydawać się oczywisty. Dzieje się tak dlatego, że nowa wersja Symfony w swoim głównym pakiecie udostępnia jedynie podstawowe moduły. Trochę sobie z nami pogrywa, ale wprawiony programista taki jak Ty, dostrzeże te pozornie ukryte możliwości. Cała reszta modułów, takich jak obsługa baz danych, logów aplikacji, czy trybu debug, trzeba zainstalować osobno, co różni nowy framework od tego, co widzieliśmy w Symfony 3.

Zanim się jednak rozkręcimy, pamiętaj, że Symfony 4 wymaga PHP 7.1.3 lub nowszego, więc upewnij się, że Twoje środowisko jest aktualne!

Instalacja – nie taki diabeł straszny
Pierwsze zmiany, z którymi trzeba się zmierzyć, przesiadając się na nową wersję Symfony, dotyczą instalacji. Jeśli się jednak przyjrzymy, to raczej możemy mówić tu o ewolucji niż o rewolucji.

1) Standardowa edycja

W przypadku Symfony 2 to była krótka piłka – musieliśmy tylko pobrać plik zip. Potem zrobiło się trudniej. Pojawił się composer – narzędzie do zarządzania zależnościami. Wraz z nim, polecenie rozpoczęcia projektu zmieniło się na takie:

composer create-project symfony/symfony-standard-edition PROJECT_NAME.

Przez co od razu wygenerowało to sporo problemów:

  • pakiet standardowej edycji był ogromny i kompozytorowi zajęło trochę czasu, żeby rozwiązać wszystkie zależności
  • nowi programiści nie byli świadomi czym jest edycja standardowa Symfony i jak się do tego zabrać
  • standardowa edycja ma wbudowaną prostą aplikację demo, co oznacza, że przed rozpoczęciem nowego projektu, musisz usunąć kilkanaście przykładowych plików. Byłoby to do przyjęcia, jednak nigdy nie zostało to wprost powiedziane w dokumentacji.

2) Skeleton

Jest też druga możliwość instalacji. Oprócz pakietu standard, twórcy Symfony 4 przewidzieli sposób z pakietem Symfony / Skeleton. Wygląda on tak:

composer create-project symfony/skeleton PROJECT_NAME

Czym ten sposób różni się od standardowego? Przede wszystkim plikiem composer.json , który zawiera w sobie pięć zależności:
„Symfony / console”: „⁴.1”,
„symfony / flex”: „¹.0”,
„symfony / framework-bundle”: „⁴.1”,
„symfony / lts”: „⁴ @ dev”,
„Symfony / yaml”: „⁴.1”

Instalacja gotowa – co dalej?

Symfony Standard i Symfony Skeleton to pakiety, dzięki którym będziesz mógł tylko uruchomić framework. To oznacza, że na samym starcie, zaraz po instalacji zastaniesz:

  • Brak domyślnej ORM (Doctrine)
  • Brak domyślnego mechanizmu szablonów (Twig)
  • Żadnych innych komponentów niekoniecznie potrzebnych do każdego projektu, takich jak: Forms, Security etc.

Wygląda jak skaza czy niedoskonałość tego rozwiązania? Tylko pozornie. To, że nowa wersja Symfony nie jest z definicji obciążona setkami zależności i danych, sprawia, że skalowanie produktu online staje się z nią zdecydowanie łatwiejsze. Zwinna budowa MVP, stworzenie prostego API niewymagającego szablonów widoków, czy też nawet lekkiego landing page’a bez konieczności ładowania weń kosmicznych baz danych. Jeśli biznesowe potrzeby klienta poszybują w górę, to zawsze można rozpocząć akcję skalowania produktu. Nasza aplikacja może się swobodnie rozrosnąć po zwodowaniu na rynek. W praktyce oznacza to, że nie masz żadnych problemów z dołączeniem dodatkowych komponentów do aplikacji. Korzysta na tym klient, ponieważ zmiany w jego produkcie są szybsze i łatwiejsze, oraz ty jako deweloper, ponieważ nie tylko sam framework nie spowalnia, ale też pisanie kodu i jego uporządkowanie jest zdecydowanie łatwiejsze. Brak niepotrzebnych zależności ułatwia nawigację po kodzie źródłowym i jego pełniejsze zrozumienie.

Fajnie, ale ja potrzebuję silnika szablonów!

OK, mimo wszystko tęsknisz za silnikiem szablonów, w porządku. Dobra wiadomość jest taka, że instalacja systemu Twig jest banalnie prosta i wygląda tak samo, jak w przypadku Symfony 3:

$ composer require twig

Co więcej, odpada konieczność konfiguracji. Nie musisz martwić się o takie historie, jak chociażby deklarowanie ścieżek. Wszystko to odbywa się automatycznie za pomocą Symfony Flex  - wtyczki composer do zarządzania aplikacjami Symfony.

Symfony Flex – koniec z szukaniem i czytaniem długich plików

Pozytywnych zmian ciąg dalszy. Starsze wersje Symfony potrafiły stwarzać problemy, jeśli chodzi o instalację rozszerzeń. Żeby wzbogacić framework o nowe możliwości, musiałeś mierzyć się z – często długimi – plikami readme.md, o ile już udało się je znaleźć na GitHub, co wcale nie było takie oczywiste.

Droga, którą musiałeś pokonać, żeby zainstalować pakiet, wyglądała najczęściej w ten sposób:

  • najpierw rejestrowałeś pakiet w AppKernel,
  • następnie dodawałeś konfigurację do config.yml,
  • a na końcu musiałeś wprowadzić kilka poleceń konsoli

Teraz, Symfony Flex robi to wszystko za ciebie! Jak? Otóż każda instalacja pakiety odbywa się zgodnie z przepisami określonymi w repozytoriach na Github:

https://github.com/symfony/recipes
https://github.com/symfony/recipes-contrib

Weźmy na warsztat przepis na popularny EasyAdminBundle:

{

„bundles”: {

„EasyCorp\\Bundle\\EasyAdminBundle\\EasyAdminBundle”: [„all”]

},

„copy-from-recipe”: {

„config/”: „%CONFIG_DIR%/”

}

}

Co robi ten przepis? Wydaje Flexowi takie polecenia:

  • zarejestruj pakiet dla wszystkich środowisk („prod”, „dev”, „test”) (dyrektywa ‘all’)
  • skopiuj pliki z przepisu do katalogu config (wówczas każdy pakiet otrzyma swój plik konfiguracyjny Yaml)
    Wszystkie recepty – zarówno te oficjalne, jak i dostarczone przez PHP-owe społeczności) czekają na ciebie na oficjalnej stronie: https://symfony.sh/.

Gdzie się podziały tamte pakiety?

To jeszcze nie koniec zmian. Komponenty Symfony, które dawniej były częścią integralną częścią frameworka, teraz muszą być instalowane osobno. Tutaj znajdziesz je wszystkie.

A co powiesz na listę najbardziej przydatnych pakietów?

  • debug które instalują DebugBundle
  • profiler dla Web Profiler Toolbar
  • log dla MonologBundle
  • orm jeśli potrzebujesz Doctrine ORM (obsługa baz danych)
  • twig dla silnika szablonów
  • mailer dla SwiftMailer

A co ze strukturą projektu?

Tutaj też czekają na ciebie zmiany, ale przyświeca temu szczytna idea, żeby wszystko stało się prostsze. To, co najbardziej powinno się dla ciebie liczyć:

  • nie ma już katalogu app/
  • config/jest teraz katalogiem najwyższego poziomu (wraz z config/packages – plikami ustawień specyficznych dla pakietu),
  • AppKernel.php jest przeniesiony do src/Kernel.php
  • Pakiety nie są już zdefiniowane bezpośrednio w pliku Kernela, ale w osobnym pliku: config/bundles.php
  • web/ zmienił nazwę na public/
  • zniknęły klasyczne pliki - app.php i app_dev.php. Jest to teraz jeden standardowy index.php, a środowisko jest ustawione na zmienną środowiskową APP_ENV
  • Szablony widoków nie są trzymane w app/Resources/views, ale w templates/

Najważniejszą zmianą jest fakt, że Symfony 4 nie ma już żadnych pakietów w src/.

Wszystkie pliki znajdują się teraz tylko w src/ (i mają App/ jako domyślną przestrzeń nazw). Ma to wpływ na dwie rzeczy:

To jak? Działamy?

Jak widzisz, Symfony 4 to zdecydowanie krok naprzód w stosunku do Symfony 3. To niesamowity framework, który można skalować, co jest prawdziwą siłą w kontekście naszych projektów, nad którymi pracujemy. Korzystamy na tym my, jako deweloperzy, ale przede wszystkim nasi klienci, a w szczególności start-up, które dzięki łatwej i szybkiej rozbudowie aplikacji, zyskują na czasie, a co za tym idzie – na pieniądzach.

Sam framework to obecnie już ponad 170 oficjalnych pakietów i „Bundles”, a codziennie przybywa nowych. Przybywa też fanów tej struktury, a dzieje się tak dzięki temu, że jest ona lekka, szybka, łatwa do nauki, i na sam koniec – wsparta potężną bazą dokumentacji.

cta.intresting
btn.yes
btn.no