W przeszłości Psono.com było napędzane przez Odoo v11. Odoo to świetny CMS, jednak jak musieliśmy się nauczyć, aktualizacje są trudne. Szczególnie moduł strony internetowej sprawiał nam wiele problemów podczas testów. Odoo v11 zakończy swoją żywotność pod koniec 2020 roku, dlatego byliśmy zmuszeni znaleźć rozwiązanie.
Rozważaliśmy różne opcje: aktualizację do Odoo v13 i ręczne migracje całej zawartości i dostosowań, zatrudnienie kogoś do przeprowadzenia migracji lub całkowitą migrację na nowy CMS. Postanowiliśmy całkowicie przenieść Psono.com i nadal korzystać z v11 za zaporą sieciową, a migrujemy go później (jeszcze się nie zdecydowaliśmy).
Powody tej decyzji były następujące:
- Mamy bardzo małą ilość zawartości, którą musielibyśmy przenieść dla Psono.com. Głównie kilka wpisów na blogu.
- Migracja do Odoo v13 odtworzyłaby ten sam problem za dwa lata, kiedy v13 osiągnie swój EOL, potencjalnie z znacznie większą ilością danych do migracji.
- Nie byliśmy zbyt zadowoleni z możliwości dostosowywania witryn Odoo v11. Wszystko jest bardzo skomplikowane, ponieważ ich szablony są przechowywane w bazie danych.
- Koszty. Zatrudnienie kogoś do przeprowadzenia migracji kosztowałoby nas co najmniej 5000 USD, a potencjalnie więcej.
- Społeczność Odoo była bardzo aktywna, ale z rozwojem w ostatnich latach zmian licencji i przenoszenia funkcjonalności oraz wtyczek na płatne rozwiązania i umieszczania wszystkiego za ścianą płatności, społeczność umarła.
- Psono.com to głównie statyczna witryna z treściami statycznymi. Jeśli potrzebujemy dynamicznej zawartości, możemy ją pobierać przez API.
Podróż
Po podjęciu decyzji o migracji musieliśmy zdecydować się na ramy. Istnieją klasyczne ramy, takie jak hugo, których używaliśmy, ale ich funkcjonalność jest ograniczona. Szukając alternatyw, znaleźliśmy kilka rozwiązań w świecie node / react.
Chciałem napisać tutaj "doskonałe rozwiązania", ale nie sądzę, że coś w obecnym zdezelowanym stanie rozwoju frontendu zasługuje na ten tytuł. Zdezelowane pytasz? Pamiętaj czasy, kiedy deweloperzy mogli tworzyć stronę internetową za pomocą index.html i tagu script do ładowania jquery i mogli rozpocząć tworzenie stron internetowych? Teraz potrzebujesz npm lub yarn, musisz rozumieć package.json, skrypty webpack, nowoczesne ramy, takie jak angular lub react, które przynoszą ze sobą własnego klienta. JSX lub typescript. Funkcje takie jak hot reloading nie działają niezawodnie (plik nie jest monitorowany, niektóre modyfikacje wymagają pełnego restartu, lub hot reloading jest wyzwalany zbyt wcześnie, więc musisz ręcznie odświeżyć stronę) więc kończysz zabijając serwery developerskie i czekasz minuty, aż wrócą (przynajmniej w większych projektach). (Tęsknię za naciśnięciem F5 i po prostu posiadaniem wszystkiego bez żadnych problemów!). Nie wspominając o nowym frameworku lub narzędziu co najmniej co pół roku, gdzie stare narzędzia są codziennie porzucane. Mogłbym łatwo wypełnić strony narzekaniem na obecny stan rozwoju frontendu. W każdym razie, wracając do rzeczywistego tematu.
W obliczu braku sensownych alternatyw, najlepszymi opcjami (w momencie pisania tego) były next.js i gatsby. Przynajmniej tak promowały je niektóre artykuły. Oba są równie popularne, jeśli porównać gwiazdki lub commity na Githubie. Jedyną różnicą, jaką mogliśmy zauważyć podczas wstępnej oceny, była potrzeba komponentu serwera dla next.js, podczas gdy gatsby tworzy strony statyczne (Proszę, nie zabijaj mnie teraz, jeśli istnieje opcja uruchomienia next.js bez aktywnego serwera! :D)
Więc trochę się pobawiliśmy z Gatsby i wyglądało to dobrze. Następnym krokiem było poszukiwanie motywu. Gatsby to "nowe" narzędzie, więc wszystkie motywy, które mogliśmy znaleźć, były jeszcze w bardzo podstawowym stanie. Trzydzieści minut i trzydzieści dolarów później mieliśmy wizualnie atrakcyjny motyw, który pokrywał przynajmniej niektóre z wymaganych komponentów, i zaczęliśmy go modyfikować.
Jako opcję hostingu można obecnie wybierać spośród wielu dostawców, takich jak Firebase, netlify, Cloudflare, Vercel, proste GCP Cloud storage lub AWS Cloudfront, własne serwery, kontenery Docker działające na Kubernetes (Musiałem to wspomnieć!), ... (Pamiętaj czasy, kiedy po prostu wynajmowałeś przestrzeń webową za 5 dolarów miesięcznie z PHP i bazą danych MySQL :D ... ale to temat na inny artykuł...)
Po ich porównaniu, przeczytaniu kilku opinii i sprawdzeniu możliwych kombinacji (jak Cloudflare przed Firebase) początkowo wypróbowaliśmy Cloudflare. Jako wielcy fani ich usługi był to naturalny wybór, jednak niestety ich narzędzie wrangler miało problemy. Najpierw ciągle rzucało błąd, a potem nie mogliśmy się uwierzytelnić... Początkowe błędy zniknęły następnego dnia (może nowy bash zrobił swoje), ale problem z uwierzytelnianiem trwał. Wierzę, że popełniłem jakiś błąd i po kilku godzinach czytania dokumentacji i próbowania różnych rozwiązań odpuściłem.
Netlify był kolejnym kandydatem, ale musisz albo połączyć go z dostawcą Git i pozwolić mu go zbudować (chcieliśmy użyć GitLab CI) albo ręcznie przesłać wyniki budowy. Może mają gdzieś opcję przesyłania wyników budowy przez API, ale nie mogłem jej znaleźć. Alternatywą byłby repozytorium, gdzie faktycznie przesyłamy wyniki budowy, ale to wydawało się niepotrzebnie skomplikowane... Kolejnym problemem dla mnie jest ich model cenowy. Pobierają opłatę za członka (!!!) całkiem znaczna kwota. Pamiętajcie, że to jest dla statycznej witryny. Stwierdzenia takie jak "4× szerokość pasma" przywołują złe wspomnienia "hostingu fair use", gdzie ludzie kopali cię, jeśli używasz za dużo...
Jako czwartą usługę wypróbowaliśmy Firebase (który jako benefit jest darmowy dla naszego docelowego pasma i liczby żądań) i wszystko działało od razu. Ich możliwości przekierowywania są nieco ograniczone, więc mapowanie starych URL-i na bardziej estetyczne stało się nieco żmudne, ale po kilku regułach przekierowania wszystko działało. Ich cennik wydaje się rozsądny i płacisz za zasoby serwera. Jednym powinno się trzymać z dala od wszystkich ich dodatkowych usług, aby uniknąć blokady dostawcy, jednak potrzebowaliśmy tylko hostingu.
Krótko sprawdziliśmy również Vercel, ale ich wymóg zalogowania się przy użyciu konta Github, a następnie pozwolenie z "Działaj w moim imieniu" odstraszyło mnie zanim jeszcze się zarejestrowałem.
Blog był najtrudniejszy do migracji. Ostatecznie ręcznie przenosiliśmy całą zawartość. To nie jest coś, co powinno się robić z większym blogiem, ale nasz miał tylko piętnaście postów. Gatsby obsługuje wiele mechanizmów, ale chcieliśmy coś prostego, co ktoś bez technicznego zaplecza mógłby użyć do tworzenia nowych postów na blogu. Zdecydowaliśmy się na markdown, więc musieliśmy nauczyć się, jak instruować Gatsby do odczytywania stron markdown. Faktystyczny mechanizm zajął nam około pół dnia z całą obsługą obrazów. Ładny motyw bloga i obrazy zajęły kolejne pół dnia.
Po migrowaniu całej zawartości i dalszym mocnym modyfikowaniu motywu zautomatyzowaliśmy nasze wdrożenie za pomocą Gitlab CI, więc proste wciśnięcie spowodowałoby uruchomienie naszej przepływu budowania i wdrożenie wszystkiego na Firebase.
Dlaczego Gitlab, a nie Github? Github ma przewagę ze względów historycznych. Obecnie mają co najmniej 80% wszystkich deweloperów i projektów. Gitlab z drugiej strony dostarcza funkcje. Dlatego w przeszłości zdecydowaliśmy się na Gitlab, ponieważ nie było żadnego realnego rozwoju funkcji w Github przez lata. To teraz dramatycznie się zmieniło, odkąd Microsoft kupił Github, a Github Actions są kamieniem milowym, ale Github nadal ma długą drogę do przebycia, jeśli chcą konkurować z Gitlab. Więc dla nas, którzy hostują wszystkie swoje projekty na Gitlab, był to naturalny wybór dla tego projektu również.
Wniosek
I tutaj jesteśmy teraz:
- Gatsby jako CMS
- Komercyjny motyw
- Blog oparty na markdown
- Gitlab CI do zautomatyzowanych wdrożeń
- Hosting Firebase
Byliśmy całkiem zadowoleni z tego rezultatu, a nowa strona wygląda znacznie lepiej!
