Jak Smashing Magazine zarządza treściami: migracja z WordPressa do JAMstack

Ten artykuł został uprzejmie poparty przez naszych drogich przyjaciół z Netlify, kompleksowej platformy do automatyzacji nowoczesnych projektów internetowych. Dziękuję Ci!

Za każdym razem, gdy programiści mówią o WordPressie, zmienia się ich procentowy udział w rynku. „ 20% wszystkich witryn jest opartych na WordPressie! ” “ 40% wszystkich witryn jest opartych na WordPressie! ” Niezależnie od tego, jaki jest procent, przesłanie jest takie samo: pod względem przyjęcia WordPress jest MASYWNY.

Dlaczego więc, przy takim przyjęciu, witryna korzystająca z WordPressa rozważałaby przejście na JAMstack? W tej dwuczęściowej serii artykułów omówimy, jak wygląda rzeczywista migracja do WordPressa, wykorzystując studium przypadku witryny, z której właśnie czytasz.

Porozmawiamy o zyskach i stratach, o rzeczach, które chcielibyśmy wiedzieć wcześniej i czym byliśmy zaskoczeni. Następnie przedstawimy techniczną demonstrację jednej możliwej ścieżki migracji — nie całkowicie z WordPressa — ale jak możesz obsługiwać WordPressa oddzielonego, aby mieć to, co najlepsze z obu światów: implementację JAMstack WordPressa, która daje Ci wszystko moc ich deski rozdzielczej i funkcjonalności, z lepszą wydajnością i bezpieczeństwem.

Zagłębmy się!

Czemu?

W 2015 roku współzałożyciel Netlify Mathias Biilmann i założyciel Smashing Vitaly Friedman rozmawiali o sklepie. Gdy architektura JAMstack zaczęła robić rundy, Smashing bardziej zainteresował się ideą stosu. Witalij i Markus (były dyrektor zarządzający w Smashing) zapytali Matta, co by się stało, gdyby Smashing przeniósł się z tradycyjnej witryny WordPress/LAMPstack na architekturę JAMstack.

W ramach eksperymentu Matt zeskrobał cały kod HTML ze Smashing i udostępnił go na Netlify, dostarczając zawartość statycznie z CDN. Wyniki były przekonujące — wersja statyczna jest średnio ponad sześć razy szybsza!

Ten rodzaj architektury działa tak dobrze po części dlatego, że strony nie są kompilowane na żądanie podczas ich odwiedzania. Ponieważ udostępniasz gotowe treści bezpośrednio z sieci dostarczania treści , witryna jest już „tam” i gotowa dla użytkownika.

Ponieważ obsługujesz za pośrednictwem CDN, możesz również rozpowszechniać treści na całym świecie — bliżej potencjalnych odwiedzających. Nie ma centralnego punktu wyjścia, co jest niezbędne w przypadku każdej publikacji internetowej, która chce być szybka dla wszystkich swoich czytelników.

Więc scena została ustawiona. Smashing Magazine przeniósł się do JAMstack — w szczególności do Netlify jako platformy. W ciągu 10 lat swojej działalności Smashing przekształcił się z małej publikacji online w ogromny blog WordPress, sprzedający książki, bilety na konferencje i warsztaty.

Było kilka kawałków tej strony:

• Blog WordPress
• Tablica pracy Rails
• Sklep Shopify
• Kolejny CMS dla strony konferencji

Kiedy Netlify po raz pierwszy rozpoczęło migrację, strona miała problemy z wydajnością, obciążone 20 000 komentarzy i tysiącami artykułów. Smashing był również zainteresowany uwierzytelnianiem w ramach nowego planu subskrypcji, a także przeprojektowaniem w celu uzyskania bardziej nowoczesnego wyglądu.

Niezawodność

Smashing regularnie osiąga to, o czym marzą inne platformy: artykuły szeroko udostępniane przez ogromną społeczność. Jednak gdy osiągnięto punkt krytyczny ruchu dla posta, Smashing regularnie miał problemy z przestojami. Aby to złagodzić, do ich stosu wprowadzono intensywne korzystanie z wtyczek WordPress, ale nadal mieli problemy z utrzymaniem dobrych wskaźników czasu pracy.

Przejście na Netlify pozwoliło zespołowi Smashing uniknąć błędów połączenia z bazą danych i nie martwić się o przestoje , nawet gdy artykuł zobaczył ogromny ruch. Czemu? Ponieważ podczas udostępniania bez serwera, wstępnie zbudowana zawartość nie musi być generowana i serwowana — już istnieje, gotowa do przeglądania. Nic nie jest wymagane na miejscu, z wyjątkiem całej, statycznej strony.

Udostępnianie przez CDN pozwoliło również Smashingowi trochę łatwiej spać pod względem bezpieczeństwa. wp-login.php od dawna jest źródłem luk w zabezpieczeniach i wektorów ataków. Nie można uzyskać dostępu do gotowych treści w ten sam sposób, a luki w zabezpieczeniach nie są tak wszechobecne.

Unieważnienie pamięci podręcznej

Smashing przechodził cyklicznie przez każdą wtyczkę buforującą WordPress, z różnymi wynikami i wieloma problemami. Witalij Friedman ze Smashing wspomina:

„Główne problemy, które napotkaliśmy, były związane z „Błądem nawiązywania połączenia z bazą danych”, który mieliśmy co drugi tydzień i dosłownie wypróbowaliśmy każdą wtyczkę buforującą WordPress. Wydajność była całkiem OK (ogółem), ale chcieliśmy ją jeszcze poprawić. Ponadto chcieliśmy uruchomić członkostwo i połączyć wszystkie różne oferty — konferencje, ogłoszenia o pracę, artykuły, książki, e-booki — za pomocą jednej platformy, co było niezwykle trudne do osiągnięcia z WordPress w grze”.

Przejście na Netlify pozwoliło zespołowi Smashing zobaczyć natychmiastowe unieważnienie pamięci podręcznej, jednocześnie obsługując buforowaną i wydajną zawartość, bez dodatkowych kosztów.

Kiedy wdrażasz witrynę, pliki HTML są hostowane w sieci CDN Netlify. Jest zoptymalizowany pod kątem wysokiego współczynnika trafień w pamięć podręczną i szybkiego czasu do pierwszego bajtu, a jednocześnie jest w stanie natychmiast unieważnić wszystkie zmienione pliki HTML . Netlify pobiera również odciski palców do wszystkich linków do zasobów, takich jak pliki CSS, obrazy, czcionki lub pliki JS, i obsługuje Smashing z nagłówkami pamięci podręcznej, które buforują je na zawsze. Odciski palców gwarantują, że są unikalne, a jeśli zaktualizujesz nową wersję, zamiast tego zostanie wyświetlona nowsza wersja.

Przepływ pracy

Patrząc na istniejącą konfigurację, jednym z głównych powodów migracji było po prostu ujednolicenie istniejących właściwości. Konieczność zmiany kontekstu między wszystkimi tymi różnymi stosami technologicznymi i konfiguracjami stała się trudnym problemem konserwacyjnym, który stanowił zadanie dla inżynierów.

Kiedy wcześniej ich infrastruktura była podzielona między tak wiele różnych systemów, ten proces migracji również ujednolicił wszystko , utrzymując główną witrynę, witrynę konferencji, subskrypcje i sekcję e-commerce, które działają razem, zamiast oddzielnie utrzymywanych z różnymi stosami. Pomogło to w utrzymaniu niskich kosztów rozwoju i spójnego doświadczenia deweloperów w pracy nad wszystkimi nieruchomościami.

Największym i najbardziej delikatnym okazał się fragment dotyczący migracji do WordPressa. Netlify próbował wyeksportować dane z eksportera WP, tylko po to, by stwierdzić, że zawartość zawierała elementy, które trzeba było zachować, lub czasami zostały zmienione przez wtyczki. Aby zachować zgodność z tym, co było na stronie, napisano serię skrobaków, podzielonych na artykuły, zasoby, komentarze i stronę główną.

Po napisaniu i przekształceniu został załadowany do nowego repozytorium w GitHub, a zamiast tego został użyty Netlify CMS. To, co sprawia, że ​​Netlify CMS jest wyjątkowy, to to, że jest lekki i integruje edytory treści z przepływem pracy Git — co oznacza, że ​​dosłownie pobierze i wyświetli pliki przecen z repozytorium git zamiast bazy danych. Ponadto Netlify CMS jest niezależny od platformy i współpracuje z (prawie) wszystkimi generatorami witryn statycznych i witrynami przechowywanymi w serwisie GitHub.

W tym czasie Sara Soueidan pracowała dla Smashing jako niezależny programista front-end nad ich przeprojektowaniem. Stworzyła bibliotekę komponentów do zbudowania architektury front-endowej i zauważyła, o ile prostsza jest praca, ponieważ pracowała bezpośrednio w git, nawet podczas pracy z CMS.

„Wszystko, co wrzuciłem do repozytorium, jest bezpośrednio stosowane w bibliotece wzorców, co oznacza, że ​​nie musisz utrzymywać dwóch różnych zestawów komponentów… ten rodzaj ciągłości był świetny! Wszystko, co muszę zrobić, to napisać HTML, CSS i JavaScript i wypchnąć do repozytorium, a wszystko działa jak magia. Przepływ pracy był fantastyczny”.

Wszystko to powiedziawszy, Netlify CMS może czasami być zbyt lekki dla tak dużego ruchu i przypadku użycia na dużą skalę. Smashing regularnie ma gościnnie autorów i pełną redakcję. Niektóre z bogatych funkcji oferowanych przez WordPress są naprawdę pomocne w tego rodzaju środowiskach wymagających współpracy.

Dlatego w poniższym samouczku przeprowadzimy Cię przez model bezgłowy , w którym nadal możesz czerpać korzyści z pulpitu WordPress dla twórców treści, ale korzystaj z WordPressa za pośrednictwem interfejsu API, a programowanie opiera się na przepływie pracy skoncentrowanym na git, który jest łatwy dla programistów do utrzymania. Bądźcie czujni!

Wybory ramowe

W początkowym prototypie, który stworzył Matt Biilmann, napisał wszystko w minimalnym Preact, w połączeniu z Hugo, ponieważ był bardzo skoncentrowany na wydajności. Po prostu używał rekwizytów i utrzymywał wszystko bardzo lekkie. Kiedy przekazał projekt, który ma być utrzymywany przez dewelopera Smashing, Ilyę Pukhalski, odkrył, że Preact brakowało niektórych funkcji, których brakowało, aby wykorzystać ekosystem Reacta. Ostatecznie korzyści z Redux i innych bibliotek przewyższyły koszty.

Zastanawiając się teraz, Matt mówi, że użyłby Vue, który w tamtym czasie nie miał wystarczającego udziału w rynku (przysięgam, że nie skłoniłem go do powiedzenia tego). Zadałem oczywiste pytanie: dlaczego nie Svelte? Ponieważ ludzie nastawieni na wydajność mają tendencję do sięgania po tę bibliotekę. Wspomniał, że Svelte nie ma jeszcze ekosystemu Vue.

Kiedy Matt zastanawia się, czy nadal używałby Hugo, mówi, że kocha Hugo, ale w tym projekcie trudno mu było szczególnie o to, że nie miał dość systemu wtyczek — tworzenia banerów reklamowych i innych rzeczy że natura nie była wystarczająco programowalna z Hugo i musiał wstrzyknąć skrypty, aby to osiągnąć. Skrypty te spowalniały proces kompilacji. To powiedziawszy, nadal używamy Hugo do naszej własnej witryny na netlify.com i uwielbiamy ją — to zastrzeżenie jest szczególnie szczególne dla potrzeb witryny Smashing.

Gdyby mógł to zrobić jeszcze raz, mógłby wybrać albo Eleveny, które ma bogate możliwości w zakresie tworzenia wtyczek i innych rozszerzalnych skryptów. Lub, gdyby używał Vue, Nuxt zaoferowałby mu kilka fajnych możliwości wtyczek, jednocześnie będąc dobrym wyborem dla tego frameworka, oferując renderowanie po stronie serwera, routing i generowanie statyczne.

Budowanie dużych witryn

Był jeden problem, który pojawił się podczas pracy z witryną tak dużą jak Smashing i być może już wiesz, co to jest, po prostu go dotknęliśmy. Prawdą jest, że w przypadku każdej dużej witryny gotowych stron obsługiwanych w sieci CDN wydajność jest nadal świetna, ponieważ nie tworzymy niczego na bieżąco dla użytkowników.

Ale ta korzyść może nastąpić tylko wtedy, gdy witryna jest wstępnie zbudowana, a proces ten może być czasochłonny. Podczas gdy bardziej tradycyjne witryny będą tworzyć strony, gdy o nie poprosisz, dosłownie tworzymy każdą stronę z wyprzedzeniem na wypadek, gdyby użytkownik mógł tego potrzebować. To sprawia, że ​​wydajność jest superszybka! Ale ten czas jest teraz odłożony na czas opracowywania i publikowania — tworzenie każdej strony może zająć trochę czasu.

Nie jest to problem z mniejszymi witrynami, ale w skali Smashing Magazine musimy trochę bardziej pomyśleć o tym czasie, zwłaszcza po to, aby ludzie mogli utrzymać wysoką produktywność, aktywnie codziennie tworząc treści.

To, co zrobił Netlify, to utworzenie dużego folderu /production-articles , który zawierał większość z wielu tysięcy artykułów, które już hostowali. Następnie utworzył osobny katalog roboczy o nazwie content/articles , w którym można umieścić artykuły, które były aktywnie tworzone i edytowane.

Ten proces kompilacji oznaczał, że wszyscy, którzy pracowali na stronie, pracowali z mniejszą partią artykułów do lokalnego rozwoju, bez przeszkód czekaniem na całą kompilację. Proces ten był zarządzany przez zadanie przygotowania artykułów do produkcji i uwolnił Hugo tylko od zajmowania się tym, nad czym aktywnie pracowano.

Jedną z wad tego podejścia jest to, że nadal wymaga uruchomienia całej kompilacji, co spowalnia proces. W przypadku mniejszej publikacji miałoby to prawdopodobnie mniejsze znaczenie, ale na skalę Smashing spowalnia proces publikacji.

Interfejsy API typu open source

Na początku wspomnieliśmy, że firma Smashing była między innymi zainteresowana migracją istniejącego rozwiązania e-commerce, obsługą komentarzy poza WordPressem i dodaniem funkcji uwierzytelniania. Wszystkie te elementy funkcjonalności zostały zbudowane przy użyciu rozwiązań open-source, które obsługuje Netlify, dzieląc je na bezstanowe interfejsy API:

• GoTell
  Narzędzie API i narzędzie do budowania do obsługi dużej ilości komentarzy.
• GoCommerce
  Niewielki interfejs API oparty na Go dla witryn e-commerce obsługujący zamówienia i płatności.
• GoTrue
  Niewielki interfejs API typu open source napisany w języku Golang, który może działać jako samodzielna usługa API do obsługi rejestracji użytkowników i uwierzytelniania projektów. Opiera się na OAuth2 i JWT i obsługuje rejestrację użytkowników, uwierzytelnianie i niestandardowe dane użytkowników.

Każdy z tych elementów wymagał migracji i własnych unikalnych czynników, i chociaż nie ma ich w tym artykule, wszystkie zostały opisane w bezpłatnej książce, którą współautor Matt, zatytułowanej „ Nowoczesne tworzenie sieci Web na JAMstack ”. W kolejnych postach przeprowadzimy również kilka głębokich nurkowań, takich jak ta — z użytecznymi przykładami — w zakresie wyszukiwania i uwierzytelniania.

Wniosek

Migracja przebiegała płynnie. Rozbijająco? Eee… poszło dobrze. Smashing nie był karany za własny sukces — gdy pojawił się popularny artykuł, mógł wyświetlać zawartość w sposób spójny, nie obciążając już dużych ładunków. Wraz z tym przejście na infrastrukturę JAMstack przyniosło lepszą wydajność i bezpieczeństwo.

Markus Seyfferth, były dyrektor generalny Smashing Magazine, zauważył:

„Czas pierwszego ładowania jest o wiele krótszy niż wcześniej… wcześniej musieliśmy czekać na udostępnienie pliku HTML przez 800 ms , a teraz jest to 80 ms ”.

Ten proces zakończył się sukcesem i, jak w przypadku każdego wielkiego projektu inżynierskiego, po drodze wyciągnięto wnioski. W następnym artykule z tej serii omówimy samouczek i demo tego, co polecamy, biorąc pod uwagę to, czego się nauczyliśmy. Jeśli chcesz zmodernizować programowanie WordPress i czerpać korzyści z wydajności i bezpieczeństwa JAMstack, czytaj dalej!