Micro frameworki: trzy stygmaty PHP

Trzy stygmaty PHP

Frameworki w PHP jest to temat powszechnie znany. Wszyscy korzystają i zapewne też zdają sobie sprawę z trzech zmian jakie w nich ostatnimi czasy zaszły. Na pierwszą z nich składają się architektura i dobre praktyki (wzorce). Łatwo jest odróżnić framework powstały X lat temu od tych, które powstały niedawno – architektury nie da się ot tak zmienić, bez przepisania całości kodu. Jeśli ktoś się zastanawia czy to ma sens („przecież działa”), to wystarczy spojrzeć na to kto zrobił całkowite rewrite: Laravel 3/4, Symfony 1/2, Yii 1/2, Fuel 1/2, Zend 1/2, Magento 1/2 itd. Trudno podejrzewać developerów o brak wiedzy czy odpowiedzialności za własny projekt. Skoro się na to zdecydowali, przy tak dużych i znanych projektach, developerzy o takiej reputacji jak np. Fabien – to nam, szaraczkom, pozostaje tylko uznać, że ma to sens i postarać się dowiedzieć kiedy i dlaczego warto to zrobić – pomimo, że „działa”.

Drugą zmianą w świecie PHP są komponenty. Kiedyś każdy framework był samoistną wyspą, z własną bazą kodu, niekompatybilną z innymi rozwiązaniami – czasami wyjątkiem były tu biblioteki do bazy danych. Wraz ze wzrostem popularności Symfony2 okazało się, że można inaczej (Zend jakoś nie osiągnął tak oszałamiającego sukcesu w tym temacie). I tu nie chodzi tylko o fakt „wezmę coś z Symfony (a, niech będzie Doctrine)”. Laravel pokazał, że można z gotowych komponentów i własnych pomysłów zrobić nowy, liczący się framework. Jesteśmy wtedy „do przodu” z aktualizacją 3/4 elementów, zostawiając dla siebie to co najlepsze, czyli nasz pomysł na framework, naszą architekturę, klasy spinające to wszystko w idealny mechanizm. Trudne do przecenienia. Trudno też oszacować ilość czasu jaką dzięki temu można zaoszczędzić. Wzrasta też jakość kodu, bo sprawdzone komponenty dają nam pewność, że są bezpieczne, stabilne, dobrze napisane i przetestowane tak jak tylko można. I oczywiście komponenty to nie tylko Symfony czy Aura. Github jest pełen gotowych rozwiązań i sprawdzonych bibliotek, często lepszej jakości niż byśmy sami napisali w rozsądnym czasie.

Trzecia zmiana to micro frameworki. Coś, czego w zasadzie nie było wcześniej. Nazwa jest nieco myląca i zapewne dlatego wielu developerów nie traktuje ich poważnie. „Micro? To do małych rzeczy, ja potrzebuję „normalnego” frameworka, a skoro taki mam, to po co mi kolejny, „micro”. Silex w testach AB działa wolniej niż moje CI, więc o co chodzi” itp.

Nowe micro vs stare macro

Micro frameworki powstały niedawno i to proste stwierdzenie zawiera w domyśle kilka informacji:

  • powstały w oparciu o nowe podejście do architektury aplikacji (wykorzystanie DI/IoC itd)
  • wspierają różne dobre praktyki i wnioski wyciągnięte z „dużych” frameworków (banał: standardowy routing REST zamiast „sieczki”)
  • powstały z wykorzystaniem komponentów

A to powoduje, że… micro frameworki są dużo nowocześniejsze niż nasze sprawdzone CI czy Kohana. Dzięki temu korzystając z nich uczymy się tych wszystkich dobrych praktyk, zamiast klepać kod tak samo jak 5 lat temu. Te czasy nie wrócą, im szybciej zrozumiemy jak teraz działają aplikacje, tym lepiej dla nas. Chyba nikt nie ma wątpliwości, że trzymanie się HTML/JS/WebDesign/RWD z 2008 roku to nie jest najlepsze rozwiązanie… Więc dlaczego trzymać się PHP z tamtych czasów? Wiele się zmieniło, nie ma lekko, uczyć się trzeba przez całe życie. Wystarczy popatrzeć na dyskusje w Slim Issues aby ocenić, czy aby na pewno jesteśmy na czasie.

Micro framework do makro zadań

Skoro wiemy już jakie to micro frameworki są fajne, to pozostaje kwestia: „no dobra, ale podaj jakiś przykład”. Proszę: SymfonyLive Portland 2013, Dave Marshall i Igor Wiedler opowiadają o Silex: An implementation detail. Dzięki tej prezentacji łatwo zrozumieć jak potężnym narzędziem jest micro framework np. Silex. To nie tylko mały gracz do prostych spraw. To nie tylko fajny sposób na nieduże API. To przykład dobrych praktyk/architektury i tego jak (nieograniczone?) daje to możliwości. Domyślnie jest w nim niewiele, ale jeśli tylko chcemy, to można dodać kontrolery, modele i całą resztę rzeczy znaną z większych frameworków. Micro framework daje nam możliwość skorzystania z podstawowych komponentów i stworzenia własnej architektury aplikacji, ze wszystkimi tego konsekwencjami. Możemy znać CI, znać Kohanę, CakePHP czy inne „stare” frameworki, ale ta prezentacja zapewne wielu osobom uświadomi, jak bardzo programowanie w PHP się zmieniło przez ostatnie kilka lat. I pokaże, że micro frameworki to nie mali gracze, to wbrew nazwie mogą być fundamenty pod rozwiązania bardzo „macro”. A ilość wiedzy potrzebna aby je zrozumieć, opanować i w pełni wykorzystać zostawia daleko w tyle „starą gwardię” frameworków.

Krajobraz po bitwie

Architektura aplikacji pisanych w PHP bardzo mocno się zmieniła na przestrzeni kilku ostatnich lat i dla kogoś, kto siedzi w starym kodzie nie jest tak prosto nagle wskoczyć w temat Symfony2 z Doctrine. Czy w dyskusje typu Di/IoC/ServiceLocator, albo czy Laravel używa Facades czy Proxy. Tak, to są teoretycznie rozważania ale samo ich sedno to jak najbardziej realne tematy – za rok czy dwa, jak wszystkie liczące się FW zostaną przepisane, znajomość DI/IoC/ServiceLocator będzie tak oczywistym wymaganiem jak obecnie znajomość OOP. Bez tego nie ma szans na zrozumienie jak działa środowisko w którym tworzymy nasze aplikacje i jakie tak na prawdę możliwości nam oferuje. Micro frameworki są idealnym źródłem wiedzy, dzięki nim, krok po kroku, możemy sami pobawić się tymi wszystkimi tematami, bez zaciemniania w postaci zbędnych klas opakowujących wszystko w „duży” framework. Stworzyć sobie „piaskownicę” do zabawy z różnymi koncepcjami.

Warto wiedzieć, że ci „micro gracze” to nie są jakieś tam zabawki dla początkujących. Mają one na prawdę duże możliwości, jednak aby je wykorzystać w pełni wymagana jest spora wiedza na temat architektury aplikacji. Wtedy dopiero pokazują na co je stać.

Linkografia

Freelancer, programista php, wiecznie niezadowolony ze swojego kodu. Toleruje frontend, kocha backend, miłośnik integracji :)

  • thejw23

    Dla zainteresowanych, rodzimy micro framework – https://github.com/potfur/moss

  • Michal

    Przeczytalem… ale dalej nie wiem jaki framework warto używać i się uczyć…

    • m

      Silex

    • Jan

      Polecam Fat Free Framework lub Slim – są o wiele szybsze niż Silex korzystający z wolnych komponentów Symfony2.

  • Guest

    Warto też spróbować framework’a SMVC dla osób lubiących MVC, strona projektu na github: https://github.com/simple-mvc-framework/v2 i strona frameworka: http://smvcf.co.uk/

  • nicky

    hej,

    fajny artykul 🙂 Jezeli ktos lubi Slim-a to polecam framework zbudowany na jego bazie, ale dodajacy pare fajnych i potrzebnych rzeczy, ktorych w golym Slim-ie nie ma:

    http://momentphp.com

Send this to friend

webmastah.weekly
Cotygodniowa porcja linków ze świata WEBDEV BEZ spamu, TYLKO samo mięcho!
Zobacz poprzednie wydania. Dołącz do 2 tysięcy webdeveloperów!
HTML5, CSS3, JS (React, Angular, Ember, Vue), PHP, SQL
webmastah.weekly
Cotygodniowa porcja linków ze świata WEBDEV BEZ spamu, TYLKO samo mięcho!
Zobacz poprzednie wydania. Dołącz do 2 tysięcy webdeveloperów!
HTML5, CSS3, JS (React, Angular, Ember, Vue), PHP, SQL