Klient potrzebował niewielkiej aplikacji wewnętrznej do rejestrowania operacji i wyliczania sald. Bez publicznej strony, artykułów, katalogu czy pracy redakcyjnej. Cały produkt miał być panelem dostępnym po zalogowaniu.
WordPress był realną opcją. Dałby gotowe logowanie, użytkowników, role i panel administracyjny. W firmie, która zna ten system, można więc szybko dojść do wniosku: zróbmy własną wtyczkę i wykorzystajmy to, co już działa.
Wybrałem Laravel. Nie dlatego, że framework jest z definicji lepszy od CMS-a. Zdecydował sposób działania aplikacji: dane miały tworzyć spójny rejestr, historia zmian musiała pozostać wiarygodna, a zadania w tle nie mogły zależeć od ruchu na stronie.
Saldo miało wynikać z operacji, a nie z edycji pola
Najważniejsza reguła biznesowa była prosta: użytkownik nie wpisuje aktualnego salda. System wylicza je na podstawie zapisanych operacji. Jeżeli trzeba wprowadzić korektę, powstaje kolejna operacja. Poprzednie dane nie znikają.
To naturalnie prowadzi do relacyjnego modelu danych z osobnymi tabelami, kluczami obcymi i ograniczeniami pilnującymi spójności. Baza danych nie jest tu tylko miejscem przechowywania wartości z formularza. Współtworzy reguły systemu.
W WordPressie również można zbudować taki model. Nie trzeba nawet opierać go na wp_posts i wp_postmeta - wtyczka może utworzyć własne tabele. Wtedy jednak coraz mniej korzystam z WordPressa jako CMS-a, a coraz więcej buduję obok niego własną aplikację: własny model danych, warstwę dostępu, walidację, procesy i ekrany panelu.
Laravel zaczyna się dokładnie w tym miejscu. Migracje, modele, transakcje bazodanowe i logika domenowa są standardowymi elementami projektu, a nie odstępstwem od podstawowego sposobu działania platformy.
Historia zmian musiała być wiarygodna
W tej aplikacji audyt nie oznaczał dodatkowej zakładki z listą edycji. Chodziło o gwarancję, że operacji wpływającej na saldo nie da się po cichu nadpisać lub usunąć.
Taką zasadę trzeba egzekwować na kilku poziomach. Interfejs nie powinien udostępniać destrukcyjnej akcji, serwer musi ją odrzucić niezależnie od interfejsu, a model danych powinien ograniczać możliwość powstania niespójnego stanu. Sama informacja „użytkownik X edytował rekord” nie wystarczy, jeżeli nie wiadomo, co wcześniej zawierał rekord i jaki wpływ miała zmiana.
Laravel pozwala umieścić te reguły bezpośrednio w kodzie aplikacji i objąć je testami. WordPress także może to zrobić, ale wymaga zbudowania podobnej warstwy wewnątrz wtyczki. Gotowa historia wersji wpisów nie rozwiązuje problemu rejestru finansowego czy operacyjnego.
Uprawnienia miały chronić operacje, nie tylko elementy menu
Ukrycie przycisku przed użytkownikiem nie jest zabezpieczeniem. Jeżeli dana rola nie może zatwierdzić korekty, serwer musi odrzucić takie żądanie również wtedy, gdy ktoś wyśle je ręcznie.
W Laravelu polityki autoryzacji i middleware pozwalają zapisać te zasady blisko chronionych operacji. Można osobno kontrolować odczyt rekordu, jego utworzenie, zatwierdzenie korekty czy wykonanie działania administracyjnego.
WordPress ma dojrzały system ról i capabilities, więc różnica nie polega na braku możliwości. Problemem jest punkt wyjścia. Panel WordPressa zakłada wspólne środowisko administracyjne, które następnie ogranicza się dla poszczególnych ról. Tutaj panel był całym produktem, dlatego prościej było od początku udostępnić każdej roli tylko te operacje, które należą do jej procesu.
Zadania w tle nie mogły zależeć od wizyt użytkowników
System wykonywał cykliczne kontrole, wysyłał powiadomienia i obsługiwał odroczone działania. Takie zadania muszą mieć określony status, możliwość ponowienia po błędzie i przewidywalny harmonogram.
WordPress udostępnia WP-Cron, ale jego domyślne uruchamianie zależy od żądań HTTP. Można podpiąć go pod systemowy cron serwera albo użyć kolejki opartej na dodatkowym rozwiązaniu. Jest to poprawna architektura, lecz wymaga świadomego dołożenia warstwy, której CMS sam nie zapewnia w oczekiwanym modelu.
Laravel ma harmonogram zadań i kolejki jako standardowe elementy aplikacji. Nadal potrzebuje crona oraz procesu obsługującego kolejkę, ale kod zadania, ponowienia, błędy i monitoring pozostają częścią jednego modelu aplikacyjnego. Dla systemu operacyjnego było to prostsze do wdrożenia i utrzymania.
Gotowy panel WordPressa nie dawał tu dużej przewagi
Najmocniejszym argumentem za WordPressem był szybki start. Logowanie, użytkownicy, resetowanie haseł i panel są dostępne od razu. Ta przewaga maleje jednak, gdy większość ekranów trzeba napisać samodzielnie.
W tym projekcie nie zarządzaliśmy wpisami, mediami ani taksonomiami. Potrzebne były dedykowane listy operacji, formularze, filtry, podsumowania i akcje wynikające z ról użytkowników. Niezależnie od wybranej platformy był to własny interfejs nad własnym modelem danych.
WordPress sprawdza się wtedy, gdy treść i proces publikacji rzeczywiście są częścią produktu. Opisałem ten przypadek szerzej w analizie kiedy WordPress nadal ma przewagę nad statycznym stosem. W aplikacji transakcyjnej funkcje redakcyjne nie dawały wartości, za to zwiększały zakres systemu wymagający aktualizacji i zabezpieczenia.
Kiedy wybrałbym WordPress
WordPress byłby uzasadnionym wyborem, gdyby aplikacja:
- stanowiła niewielki moduł istniejącego serwisu,
- korzystała głównie z użytkowników, treści i procesów już obecnych w CMS-ie,
- miała prosty model danych bez rygorystycznych zasad integralności,
- była utrzymywana przez zespół, który ma gotową infrastrukturę i procedury wyłącznie dla WordPressa,
- miała wkrótce otrzymać publiczną część treściową zarządzaną z tego samego panelu.
W takich warunkach własna wtyczka może być tańsza w budowie i utrzymaniu niż osobna aplikacja. Konsolidacja platformy ma wartość, szczególnie gdy niewielki zespół odpowiada za hosting, aktualizacje i kopie zapasowe.
W opisywanym projekcie żaden z tych argumentów nie przeważał. Aplikacja nie rozszerzała istniejącego serwisu, nie publikowała treści i od początku potrzebowała własnego modelu danych oraz procesów w tle.
Decyzję podjął koszt obchodzenia ograniczeń platformy
Laravel nie wygrał liczbą funkcji. WordPress na starcie oferował ich nawet więcej. Wygrał tym, że potrzebne elementy - transakcje bazodanowe, autoryzacja operacji, kolejki i harmonogram - należą do typowego sposobu budowania aplikacji w tym frameworku.
W WordPressie osiągnąłbym ten sam rezultat, ale musiałbym stworzyć znaczną część własnej warstwy aplikacyjnej wewnątrz CMS-a. Gotowy panel skróciłby początek prac, natomiast kolejne wymagania stopniowo zmniejszałyby tę przewagę.
To jest praktyczne kryterium wyboru technologii: nie pytam, czy na danej platformie da się coś zbudować. Zwykle się da. Pytam, ile jej domyślnych mechanizmów wykorzystam, a ile będę musiał zastąpić albo ominąć. W tym przypadku odpowiedź prowadziła do Laravela.
Narzędzia AI nie zmieniają tego wniosku. Mogą przyspieszyć przygotowanie migracji, modeli czy panelu, ale nie zdecydują, które dane powinny być niezmienne, gdzie przebiega granica autoryzacji ani jak system ma zachować się po nieudanym zadaniu. Im łatwiej wygenerować kod, tym większe znaczenie ma poprawny wybór modelu i platformy przed rozpoczęciem implementacji.