 No to witam wszystkich. Najpierw sobie zrobię małą próbę czy to wszystko działa? O, działa. Super. Dobre. To porozmawiamy dziś troszeczkę o... A, czekajcie, że sobie licznik odpale, żebym tu się nie zdziwił, bo... bo mnie, wiecie, zaraz ściągną tutaj siłą. OK. My tutaj mamy własny licznik. Tak, ale wolę swój. Nasz działa lepiej. Dobrze. To porozmawiamy dzisiaj troszeczkę o headless, o architekturze i zastanowimy się, czy ona ma sens, nie ma sensu, a niektóre firmy promują ją jako coś, co rozwiąże w szerakie nasze problemy. Wiecie, znikną wojny, niebo będzie bardziej niebieskie, ptaki będą ładnie śpiewać. Tylko, no wiecie, jak jest. To nie jest wszystko tak oczywiste. I właśnie się zastanowimy, ile w tym wszystkim, ile jest korzyści z przejścia na architekturę headless w przypadku WordPressa, a ile jest tym po prostu takiego marketingu, który... No, czasami mówimy o po prostu w tym pojęciu overselling. No więc, mimo zaczniemy, musimy troszkę zacząć od podstaw, czyli czy w ogóle jest architektura headless? No, żeby zacząć mówić o headless, musimy zacząć od tego, czym jest monolit. WordPress domyślnie jest monolitem. Oznacza to, że mam tu jakiś laserek, nie wiem, nie będę ryzykował. Jest? Więc zarządzamy sobie treścią za pomocą naszego WPA-admina. Jak wiecie, dodawać, wpisydawać, strony, kategorię, co sobie tylko życzymy. A następnie, ten sam WordPress będzie też pomagał nam wyświetleniu tych danych na froncie. Od tego mamy nasze motywy. Więc tak działa monolit. Wszystko jest w jednym miejscu, bezpośrednio z bazy danych, ale ci jest super. A tak wygląda headless, czyli WordPress cały czas robi to, co robił. Czyli zarządzamy sobie w nim naszymi danem i cały czas dodajemy strony, tylko dane wyświetlane są nie bezpośrednio przez WordPressa, tylko przez jakąś niezależną aplikację, która sobie wisi gdzieś na zewnątrz. Może być ona napisana, w czym sobie życzymy. Może to być jakiś nowoczesny framework jazzowy, może to być jakaś aplikacja w Laravelu, a może ktoś chce coś bardziej specyficznego, jakiś go, rust, to już tutaj od was zależy. Ważne jest to, jak one się będą sam komunikować. Do tego jest potrzebne jakieś API. W przypadku WordPressa mamy albo domyślne rest API, albo możemy sobie zainstalować wtyczkę, no bo wiemy, że WordPress ma wtyczkę na wszystko i możemy mieć jeszcze dostęp do GraphQL. No i bardzo fajnie, mamy ładny przykład jak wygląda headless, to musicie przyznać. Wygląda to trochę jak monolith, tylko z takim dodatkowym krokiem, taki trochę przekomplikowany, bez jakiegoś większego sensu. Widzę, że niektórzy się uśmiechałem, lubią te szylka i mortiego, bardzo się cieszę. I jest to prawda. Uważam, że przykład, który jest używany do ilustrowania najczęściej jak wygląda architektura headless jest jednym z tych przykładów, który zupełnie nie pokazuje jego korzyści. Bo on zgadza się, on jest poprawdo, pokazuje co się dzieje, że odcinamy front od backendu no ale z tego tak naprawdę nic nie wynika. Poza jednym konkretnym przykładem, ale ogólnie nic tego nie wynika. Dlatego o wiele lepsze są troszkę inne przykłady, bardziej zaawansowane. Jeden jest taki, że nasz WordPress zaczyna robić z tak zwany single source of truth. Dla naszych wielu stron. Czyli wyobraźcie sobie, że macie sieć 60 landingów, trzech aplikacji i gdzieś tam pod spodem jest jeden WordPress, z którego te wszystkie strony pobierają dane. Czyli jak w jednym miejscu w tym WordPressie zmienimy, czym się zajmujemy, to te wszystkie nasze aplikacje i strony dostaną tą informację i zostaną przebudowane. To jest jeden wariant. Drugi wariant to jest ta odwrót. Czyli nasza strona jest swego rodzaju hub'em i ten hub będzie pobierał dane z wielu różnych źródeł. Czyli na przykład będziemy sobie ciągnęli z naszego WordPressa bloga. I tylko tym się będzie zajmował WordPress blogiem. Dodatkowo mamy e-commerce i tutaj będzie główną rolę pełniło Shopify. A jeszcze mamy gdzieś tam dziwną tabelę w notion, w którym coś sobie trzymamy i też sobie te dane zaciągamy. I w ten sposób mamy takie hub'a, który zaciąga z wielu źródeł dane. No i oczywiście możecie sobie też wyobrazić teraz próbujcie sobie zmiksować te dwa obrazki, kiedy tworzymy taką naprawdę ogromną pajęczynę połączeń. Kiedy mamy... No wtedy byłoby przestać być takim single source of truf, ale mamy taki CMS, który dostarcza dane do wielu stron, a a następnie deszcz te strony jeszcze sobie pobierałem dodatkowe dane jeszcze z kilku miejsc. I wtedy nam się tworzy taki bardziej oczywisty przykład, kiedy Headless tak naprawdę spełnia swoją rolę. No dobrze, tylko no to już mamy trochę teorii. No teraz porozmawiajmy, jak to jest, czy ten Headless są pewne takie amazing, bo naprawdę posłuchamy takie wersala czy netlify'a, to oni nam będą próbowali i powiedzieć, że przejdźmy na tą architekturę, będzie super w końcu, a nie ten stary WordPress na starem PHP. No wiecie, jak jest. No naprawdę oni troszeczkę przesadzają i właśnie teraz omówię kilka takich najpopularniejszych argumentów, które są używane, czemu korzystać z Headless, które nie są aż tak dobre, jak się im przyjrzymy. No jeden slajd. Dobrze. Pierwsza rzecz, ten najpopularniejszy argument wydajność, performance. Wiecie, bo jak wszyscy wiemy WordPress jest stary, wolny na PHP koszmar, prawda? I dzięki temu, że właśnie przejdziemy na architekturę Headless, nagle będzie będzie o mniej PHP na poziomie stu, a nawet stu jeden, no i w końcu będzie dobrze. Czy to jest prawda? Czasami tak, ale wynika to bardzo często nie tyle samej architektury Headless, co z faktu, że część na przykład frameworków będzie konwertowała naszą stronę dostatyczną i to się zgadza. Wtedy nasza strona będzie szybsza, no bo oczywiście, że statyczny HTML zawsze będzie szybszy od dynamicznego PHP, a no tego nie przeskoczymy. Tylko, żeby uzyskać z WordPressa statyczny HTML nie musimy zmieniać całej architektury. Wystarczy, że, wiecie WordPress, mamy do tego wtyczki, simply static, WP to static, albo nawet skorzystamy z bardziej agresywnego keszowania strony. I efekt będzie taki sam, zbliżony bez potrzeby posiadania niezależnego frontendu i zmiany architektury. Kolejna rzecz, o której słyszymy, że dzięki podejściu Headless, będziemy mi w końcu większą kontrolę nad tym, co wczytujemy jakie CSS, jakie JTS i troszkę jest w tym racji, ale też nie do końca, bo polega to po prostu na tym, że kiedy tworzymy niezależną aplikację zaułóżmy, że sobie w tym dzieje się czerwna rawelu i chcemy dodać jakiś CSS czy JTS, to to zabierz mi to trivialnie, to musimy go dodać po prostu ręcznie. W WordPressie bardzo często korzystamy z tych gotowych wtyczek, które troszkę decydują za nas, że wczyta autor zadecydował za nas, że wczyta JTSa czy CSSa. I wtedy nasza rola bardziej polega do tego, że jeżeli my chcemy, żeby to działał troszkę, inaczej musimy je usunąć. Ja uważam, że mamy dokładnie taką samą kontrolę, tylko mamy troszkę inne podejście. W przypadku WordPressa mówimy o swego rodzaju opt-out w przypadku Headless o opt-in. I tyle, ale kontrola jest bardzo zbliżona, więc mówię, kontrola jest według mnie naprawdę bardzo na tym samym poziomu. Musimy jeszcze pamiętać, że niektóre frameworky JSowe dadzą nam w prezencie dość spory narzut JSa. Tak trochę patrzę tutaj złośliwie szczególnie na Nexta, który nawet jeżeli nasza aplikacja nie ma żadnych dodatkowych JSów i tak nam podaruje dość dużo tego JTSa tak na start, żebyśmy mieli. Więc nasz page speed też troszeczkę będzie przez to gorszy. Kolejnym znanym argumentem czemu iść w stronę Headless jest bezpieczeństwo. No bo wiemy WordPress jest niebezpieczny, dziurawe wiecie jak jest każdego dnia ktoś tam próbuje to przypomnieć. I czy dzięki Headless będzie lepiej? Nie do końca. Bo o ile na przykład przekonwertujemy naszą stronę na statyczną zgadza się. Liczba potencjalnych wektorów ataku na naszą stronę spadnie no bo wiadomo, HTMLa się dość ciężko hakuje w przeciwieństwie do aplikacji z drugiej jednak strony skądś te dane musimy zaciągnąć, czyli ten WordPress ciągle gdzieś tam musi być, więc my ciągle od niego musimy dbać, ciągle go musimy aktualizować. Oczywiście bardzo często przy takim ustawieniu łatwiej jest tam tego WordPressa, nazwijmy to troszkę zabunkrować, żeby był trudniej dostępny, ale jednak musimy o niego ciągle dbać, więc aż tak łatwiej nie będzie. Z drugiej strony pamiętajcie te obrazki na początku. Bardzo łatwo jest doprowadzić do pięknej pajączyny i wtedy musimy pamiętać, że te połączenia API, żebyśmy je gdzieś nie dali za dużych uprawnień, nagle się pojawia wiele środowisk, więc z tym bezpieczeństwem jest tak, zagrożenia są tylko inne, więc WordPress nie rozwiąże nam w magiczny sposób naszych problemów z bezpieczeństwem. Koszty. Też argument, że w końcu WordPress będziesz miał prawie ze strony za darmo. I zgadza się, w pewnych sytuacjach tak, jeżeli na przykład pójdziemy tą metodą z tym single source of truth, wtedy nasz world i będziemy mieli te nasze landingi statyczne, to z jednej strony na hosting WordPressa oszczędzimy, bo może być stosunkowo słaby. Z drugiej strony porozrzucamy się po darmowych tirach, Wersela, Netlify, GitHub Pages. I naprawdę uda nam się w tej sytuacji zbić kosztę do naprawdę bardzo niskiego poziomu. Ale tylko wtedy. Moment, kiedy zaczniemy, kiedy chcemy, żeby te strony były dynamiczne, to już zaczynamy normalnie płacić za hosting. Nasz WordPress też musi być wtedy o wiele mocniejszy, bo musieli zdarzyć obsługiwać te wszystkie zapytań. Musimy też wziąć pod uwagę, że im bardziej skomplikowany układ, tym coraz bardziej skomplikowane CI CD nam się będzie potrzebne, cały tutaj flow się pojawi. I co jeszcze ważne, tak średnio ujmując, developerzy WordPressa są troszkę tansi na przykład JSa. Więc to, co oszczędziliśmy na naszej infrastrukturze nagle się okaże, że wydamy na programistów. Więc z tymi kosztami nie jest to takie oczywiste. Tak, czasem się da, ale nie zawsze na tym oszczędzić. Zapomniałem, zapomniałem kliknąć. Nie idziemy. Dobra. Też kolejny argument jest, że przechodząc na te nowoczesne technologie będzie nam prościej. I to znowu nie jest tak do końca. Tu trochę mamy problem z tym, że nie wiecie, jaką backup ma renomę. On umiera co roku, prawda? Tylko coś umrzeć nie może i ciągle jakąś nową wersję wypuszczają. No ja nie wiem, jak to się dzieje. Pierwszą rzecz, którą się bardzo często pojawia, kiedy przejdziemy w jakiś tryb headless, szczególnie jak pójdziemy za używanie tego argumentu ze statykami, pojawia się krok z budowaniem strony. Coś, czego normalnie w WordPressie nie ma. W sensie ok, niektóre pewnie firmy, które mają bardziej zaawansowane jakiś ten flow mają ten krok, budowania strony pełne CICD, ale i domyślnie WordPress tego nie ma. A w momencie, kiedy zaczniemy myśleć o headless, szansa, że ten krok budowania będzie jest coraz większe. To powoduje, że zmienia się i skomplikowanie, bo no troszeczkę rośnie. I bardzo często trochę user experience, bo nagle trzeba czekać, nim się pojawi nam treść na stronie. Ciężko mówić, że jest to prostsze niż było. Dodatkowo, często korzystamy z wtyczek. Bądźmy szczerze, że od tego mamy ten ekosystem, żeby z nich korzystać. Tylko się okaże, że część wtyczek nie ma integracji, akurat z API, z którego chcemy skorzystać. I wtedy w ramach prostotych możemy sobie dopisać naszą prostą, nową integrację, na przykład naszej ukochanej wtyczki z GraphQL. No, nie wiem, czy to jest wszystko takie proste, no, ale wszystko w imię pracy, na przykład w tym modern JS environment. No fajnie, fajnie. Przyczy. Tutaj sobie troszkę ponarzekałem, że te najpopularniejsze argumenty wcale nie są aż takie oczywiste, ale mamy kilka powodów, dla którego naprawdę warto jest o architekturze Headless pomyśleć, bo ona w pewnych przypadkach ma naprawdę ogromny sens. Pierwszy powód to według mnie jest wolność. Bo w przypadku monolitu stajemy się swego rodzaju niewolnikiem rozwiązania, które wybraliśmy. Wybraliśmy WordPressa, będziemy musieli korzystać z mapa, no teraz jeszcze przez Gutenberg z Reacta. Ale właśnie, z Reacta, nie z View. Z Reacta, bo WordPress tak robi. W przypadku Headless i faktu, że zaczniemy sobie rozdzielać te rzeczy, nagle się może okazać, że możemy zacząć dodać do naszego stacku kolejne języki. Nasz front może być napisany we View, albo się okaże, że na rynku pojawi się programiczni w innym języku. Spoko, może się okazać, że możemy ich zatrudnić i wszystko będzie ok. To jest ważna argument. Kolejna rzecz Headless jest bardzo związany z taką wymiennością części. Możemy go trochę porównać z krodzkami lego. Coś wydaje nam się, że chcemy zmienić. No wiecie, jak się w lego buduje. Rozkładamy zestaw, wymieniamy krodzki i składamy. Tyle. Jest to stosunkowo proste. Przykład tego na początku, co był ten diagram nie podoba nam się noszyn, przechodzimy na Google Spreadsheet. Spoko, wymieniamy tylko ten jeden mały element. Coś to jest z naszej perspektywy bardzo ważny developer experience. Bo wiecie, WordPress jest świetnie, jeżeli chodzi o user experience. Ludzie są do niego przyzwyczajeni. Potrafią z niego korzystać. Dla nas dla developerów WordPress często taki fajny nie jest. Wiemy, jak nowoczecnego PHPa mamy w korze. Wiemy, że mamy wiele naszych standardów. Korzystając z innych rozwiązań mamy też dostęp do całego zestawu toolingu, który jest tym związany. Więc możemy wykorzystać całe, wszystkie dobrodziejstwa, związane z Ravelem, związane z Nuxtem. Nam jako developera będzie wygodniej, a nasi użytkownicy wciąż będą mogli korzystać z ich ulubionego CMS. No więc, o czym pamiętać, jeżeli byśmy jednak postanowi to chcemy iść tego w ten headless, czy nie. Ja mówię, że pamiętacie, to jest tylko architektura. To nie jest coś, co magicznie rozwiąże nasze problemy. To nie jest jakiś kult. To jest po prostu architektura. Ona nie jest dobra albo zła. Ona będzie bardzo zależała od tego, co my potrzebujemy w firmie, od tego, jakich mamy pracowników. I wy, jako inżynierowie bardzo często będziecie musieli podjąć tą decyzję. Przemyśleć, czy w waszym przypadku ma to sens. Czasem będzie miało, czasami nie. No właśnie, nie rozwiąże wszystkich waszych problemów. Dla wyjaśnienia na boję z tyłu są dlatego, że w angielskiej wersji by było icnata silver bullet. No i właśnie to, o czym wspomniałem wcześniej, a czemu nie rozwiąże wszystkich waszych problemów, bo to jest tylko architektura. To jest bardzo ważne zapamiętań. To, co też jest ważne, im bardziej skomplikowany stak, o matko, im bardziej skomplikowany stak, tym najczęściej ale też nie zawsze. Nawet Emmaison, który tak kocha wszystkie bycie takim dekapl, microserwis i tak dalej, ostatnio w primie zaczął przechodzić na monolit w pewnych kwestiach, bo miało to sens. I właśnie na tym to polega, że zawsze trzeba podjąć tą decyzję. Aczkolwiek trzeba pamiętać, że w przypadku headless, im bardziej skomplikowany stak, najczęściej tym lepiej. Ale, jak powiedziałem, nie zawsze. I jeszcze coś. Jeżeli zdecydowaliście się na przejście z monolitycznego WordPressa na headless dlatego, że zapuściliście trochę waszą stronę i myślicie, że nagle będziecie mieli tą modern stronę, używających takich nowych, fajnych elementów to pamiętajcie, Javascript się zmienia w zastraszającym tempie. O wiele szybszym niż to, co się dzieje w WordPressie. Więc te wszystkie anegdotki odemrugniemy okiem i możliwe, że właśnie pojawił się nowy framework to jest trochę w tym prawdy. To się naprawdę wszystko tak szybko zmienia. Może się okazać, że jeżeli byliśmy w stanie zapuścić naszego WordPressa to naszą piękną, nowoczesną stronę bardzo szybko też zapuścimy w JS i nie powiedzieć, no i w sumie będziemy znowu w tej samej dupie. No to co, headless ma sens? Jak myślicie? Tak czy nie? O, o, o, o, o, bardzo ładnie, bardzo ładnie. Oczywiście to zależy. To zależy. Czasami ma sens, czasami nie ma. To co właśnie wspominałem, to będzie bardzo zależało od was, od tego, jak zobaczycie, czy firma wymaga tego czy nie. Może się okazać, że u was w danej, w waszej firmie monolith funkcjonuje doskonale. I super, zostancie przy nim. Nie róbcie tego na siłę. To, że ktoś na Twitterze napisał, że astro jest genialne. Nie znaczy, że musicie mnie słuchać, bo to, że mi się podoba, nie znaczy, że u was to zadziała. Tak samo to, że Google czy Facebook twierdzi, że tak, headless, decapl, microservices i tak dalej, fajnie, ale wy nie jesteście Facebookiem, Googlem i tak dalej, macie inne budżety, macie innych ludzi, macie inne wymagania, więc też ich tak do końca nie słuchać, sprawdzajcie, ale zawsze patrzcie, co się dzieje u was. Dobrze, zdążyłem, bo widzę, że nikt mnie nie ściąga siłą, a, a, a, a, a, już się szykował. To wielkie dzięki, że mnie wysłuchaliście, jeżeli chcielibyście jeszcze o tym troszkę pogadać, jestem na Twitterze, gdzie czasem właśnie piszę, że takie astro jest super, ale nie słuchajcie mnie też tak do końca, palmiak.fp, albo też mam newsletter, newsletter.maciek.parmowski.ed, gdzie czasem też piszę o headlesie, więc dzięki wielkie. Koniec, super, dziękuję. Koniec.