Budowanie naszej strony: Od Django i Wordpressa do generatora statycznego (część I)

1. Nasz stos do 2016 roku: Django i Wordpress
2. Jak nasza strona spoglądała wstecz w 2012 roku.
3. Wady
4. Marzenie dewelopera: stój
5. Wymagania dotyczące nowej witryny
6. URL
7. Sekcje i treść
8. Blog
9. Wybór statycznego generatora witryny
10. Ocena Jekyll
11. Wypróbowanie Hugo
12. Wniosek

Ostatnio ogłosił przeprojektowanie naszej strony internetowej i bloga. Do tej pory był to wielki sukces . Strona jest dużo szybsza, SEO jest lepsze niż kiedykolwiek (sygnalizowane wzrostem ruchu organicznego), wskaźniki odrzuceń użytkowników są niższe, liczba odwiedzanych stron wzrosła, podobnie jak czas trwania sesji. Hurra! :-)

Jednak zmiana była znacznie głębsza niż tylko wizualna modernizacja. Postanowiliśmy zrewidować stos technologii, który zasila witrynę od ponad 6 lat. Była to dobra okazja, aby stworzyć stronę, której zawsze chcieliśmy i nauczyć się w tym procesie.

W tym poście i kolejnych omówimy proces, przez który przeszliśmy i spróbujemy odpowiedzieć na kilka pytań:

• Co mieliśmy wcześniej?
• Dlaczego zmieniliśmy stronę na statyczną?
• Dlaczego wybraliśmy Hugo jako nasz generator witryn?
• Czego dowiedzieliśmy się o Hugo w tym procesie? Jak to się robiło, kilka wskazówek i może kilka hacków.
• W jaki sposób wykorzystaliśmy Hugo wraz z pakietem Webpack do naszego łączenia aktywów?
• Jak przeprowadziliśmy migrację i nie straciliśmy SEO? Adresy URL się zmieniły. Jak poradziliśmy sobie z przekierowaniami?
• Jak to jest wdrożone?
• W jaki sposób zautomatyzowaliśmy wdrażanie, więc wystarczy pojedynczy nadrzędny wzorzec git push?

W dalszej części skoncentrujemy się na pierwszych 3 pytaniach.

Nasz stos do 2016 roku: Django i Wordpress

Historycznie byliśmy użytkownikami Django ramy dla rozwoju aplikacji internetowych. Ogólnie podoba nam się to, łatwo jest nauczyć się początkujących, jest w zestawie z bateriami i pozwala na szybki cykl rozwoju. W ciągu ostatnich kilku lat ciągły rozwój społeczności Javascript przesunął Django do zaplecza (dziękuję, React.js i inni!). Jednak fakt, że szablony Django nie są już powszechnie używane do złożonych aplikacji internetowych, nie oznacza, że ​​ramy straciły swoją użyteczność. W przypadku małych aplikacji z ograniczoną interaktywnością w interfejsie szablony mogą nadal mieć sens.

Każda iteracja naszej strony została zbudowana przy użyciu Django i jego szablonów po stronie serwera. Mieliśmy modele większości treści (takich jak członkowie zespołu, klienci, referencje itp.), Więc można je edytować za pomocą interfejsu Django Admin.

Jak nasza strona spoglądała wstecz w 2012 roku.

Nasz stos był:

• Gunicorn jako serwer WSGI.
• Nginx przed gunicorn i służyć statycznym zasobom.
• Lakier jako caché przed nginx. Nie tak, jak było to absolutnie konieczne, ale chcieliśmy być przygotowani na wypadek, gdybyśmy opublikowali wiadomości i otrzymali wielu równoczesnych użytkowników (było to hostowane w małym Amazon EC2 instancja!).
• PostgreSQL jako nasza baza danych wyboru.

Nasz pierwszy blog został zbudowany przy użyciu aplikacji Django o nazwie Cynia . Zrobił to, co powinien, ale wymagał od nas zainwestowania czasu deweloperskiego, aby zrobić praktycznie wszystko. Na drugą iterację naszego bloga (w 2014 r.) Przeszliśmy na Wordpress ponieważ była znacznie lepiej obsługiwana przez społeczność i miała dostępne wtyczki dla prawie wszystkiego.

Wady

Działaliśmy od kilku lat, ale było kilka rzeczy, które nigdy nie zadowalały nas z tego stosu:

Jest takie powiedzenie, że syn szewca zawsze chodzi boso . Skonfigurowaliśmy serwery setki razy, ustawiliśmy zautomatyzowane alarmy CloudWatch , Datadog , Pingdom i wiele innych. Kiedy poważnie myślisz o aplikacji / witrynie, są one koniecznością.

Faktem jest:

Chcieliśmy całkowicie uniknąć serwerów i nie trzeba konfigurować żadnych alarmów związanych z naszą stroną / blogiem.

Mamy głównie zawartość statyczną; tak naprawdę nie jesteśmy aplikacją interaktywną, więc jaka jest prawdziwa zaleta korzystania z Django dla zaplecza?

Marzenie dewelopera: stój

Mogłem sobie wyobrazić scenariusz, w którym nasza strona to tylko kilka plików .html w jakimś folderze, tak jak w starych dobrych czasach . Czy możemy zbudować w 100% statyczną stronę internetową?

Statyczne generatory witryn nie są nowe. Jekyll jest najpopularniejszym, będącym de facto generatorem w Strony GitHub usługa. Tam są wiele innych , napisany w kilku językach.

Pomysł naprawdę spodobał się wszystkim programistom w zespole. Być w stanie pisać w Markdown, zatwierdzać w git (dostajesz kontrolę wersji za darmo!) I mieć jakiś system, który automatycznie wdraża się, gdy rzeczy są wypychane do określonej gałęzi. Czy możemy przekonać nielicznych techników, że mamy taką drogę? ;)

Wymagania dotyczące nowej witryny

Wszystko miało sens, więc nadszedł czas, aby zacząć pracować. Obawiano się jednak, że w trakcie tworzenia nowej witryny i bloga dowiemy się, że niektóre funkcje były nieobsługiwane lub bardzo trudne do osiągnięcia za pomocą wybranego przez nas generatora statycznego. Gdyby tak się stało, albo skończylibyśmy z migracją naszego kodu do innego generatora (zwiększając nasz czas i koszty) lub, z wielkim smutkiem, musielibyśmy ponownie rozważyć naszą decyzję o przejściu w stan statyczny.

Aby uniknąć niefortunnego scenariusza, mądrą rzeczą było zapisanie wymagań dotyczących nowej witryny i bloga. W ten sposób możemy wcześniej wykryć potencjalnie problematyczne rzeczy.

URL

Witryna powinna być hostowana pod adresem https://tryolabs.com i blog w https://tryolabs.com/blog/ .

W naszej poprzedniej witrynie adres URL bloga był http://blog.tryolabs.com . Używanie tej samej domeny zamiast subdomeny bloga jest (prawdopodobnie) lepsze dla SEO.

Chcemy mieć ładne adresy URL i nic „paskudnego” kończącego się na .html.

Sekcje i treść

Główna strona powinna zawierać sekcje, takie jak Nasza praca , Zespół , Co robimy itd. Nic wielkiego, ale do budowy strony musimy pamiętać, że niektóre sekcje na stronie odnoszą się do bloga:

• Z naszego bloga na stronie głównej wyświetlane są 2 ostatnie wpisy na blogu.
• Informacje o członkach każdego zespołu na stronie zespołu pokazują ostatni wpis na blogu napisany przez członka zespołu.

Blog

Oprócz standardowego stylu blogu ze stroną główną zawierającą wszystkie posty w porządku chronologicznym i stronicowanym , mieliśmy następujące wymagania:

• Posty mają jedną kategorię i mogą mieć przypisane kilka tagów .
• Mamy strony z listą wszystkich postów z określonym tagiem lub kategorią.
  • Każda z tych stron jest podzielona na strony, podobnie jak strona główna bloga.
• Posty mają przypisanego autora .
  • Każdy autor ma swoją stronę ze zdjęciem i mini biografią.
  • Każda z tych stron ma listę postów wspomnianego autora, paginowaną .
• Blog powinien mieć możliwości wyszukiwania .
• Każdy adres URL bloga jest zagnieżdżony pod prefiksem / blog. Na przykład:
  • / blog / kategorie / nauka maszynowa /
  • / blog / tagi / strona internetowa /
  • / blog / autorzy / alan-descoins / strona / 2 /
  • itp.
• Adres URL postów na blogu musi być taki jak / blog / RRRR / MM / dd / post-slug /. Jeśli to możliwe, chcielibyśmy zachować format adresów URL witryny Wordpress.

Wybór statycznego generatora witryny

Widząc kilka wygenerowanych statycznie blogów (jak każda strona na stronach GitHub) wiedzieliśmy, że wiele rzeczy można już zrobić. Nie byliśmy tak pewni następujących wymagań:

1. Tagi i kategorie dla postów.
2. Kategoria i strony tagów. Pogrupowane .
3. Strony autorskie z mini bio i listą postów. Pogrupowane .
4. Funkcja wyszukiwania.

Nadszedł czas, aby trochę zagłębić się w to, jak sobie z tym poradzimy.

Ocena Jekyll

Ze względu na duży ekosystem Jekyll gdzie zaczęliśmy szukać.

Szukaliśmy witryn wygenerowanych za pomocą Jekyll, aby sprawdzić, czy możemy znaleźć coś na tyle podobnego do tego, co zamierzaliśmy zbudować. Z naszych ustaleń wynika, że ​​paginacja wydaje się największym problemem. W szczególności paginacja według autora / tagu / kategorii. Z Jekyllem może robić tagi i kategorie ale były to strony, które wymieniały je wszystkie, zamiast oddzielnych stron dla tagów / kategorii z obsługą stronicowania.

Cieszyliśmy się, że dowiedzieliśmy się, że Blog StackExchange jest otwarte źródło i zbudowany z Jekyll, więc spojrzeliśmy tutaj. Wyjaśniło, że Jekyll może pobrać kilka dość skomplikowanych witryn; i to wydawało się bardzo zbliżone do tego, czego potrzebowaliśmy. Posiada strony z tagami i autorami z podziałem na strony! Jak to zrobili? Z +400 liniami kodu Ruby niestandardowa wtyczka do paginacji Zbudowali. Nie podobało nam się to, modyfikowanie tej wtyczki w celu dostosowania jej do naszej rzeczywistości było trochę za dużo.

Wygląda na to, że Jekyll może nie pasować najlepiej. Może był jakiś inny generator statyczny z wbudowaną obsługą tego?

Wypróbowanie Hugo

Kiedy po raz pierwszy się dowiedziałem Hugo , Byłem pod wrażeniem i miałem nadzieję, że pewnego dnia znajdę wymówkę, by go wypróbować. Mówimy o generatorze statycznym, który jest dostarczany jako pojedynczy plik wykonywalny (wbudowany w Go), który nie wymaga uruchamiania ani żadnych wtyczek - kontrast do Jekylla, który zależy od ekosystemu Ruby. Międzyplatformowy, szybki (czas budowy ~ 1 ms na stronę), z przeładowaniem na żywo dla łatwego rozwoju. Mam nadzieję, że funkcje są na tym samym poziomie.

Zdecydowaliśmy, że musimy dać Hugo szansę (gra słów przeznaczona).

Pierwszą rzeczą, jaką zauważyliśmy, było to, że w przeciwieństwie do Jekylla, Hugo ma rodzime wsparcie dla pojęcia taksonomie . Te taksonomie dają nam sposób klasyfikowania treści, jak nam się podoba. Na przykład możemy dodać taksonomię dla szeregu powiązanych postów.

Domyślne taksonomie to kategorie i znaczniki , których potrzebowaliśmy. Czy moglibyśmy także zbudować taksonomię dla autora, a także posty pogrupowane według autora? Okazuje się, że jest to banalne. Pod warunkiem, że istnieją poprawne szablony, Hugo automatycznie utworzy strony dla całej zawartości w każdej taksonomii, a te zostaną podzielone na strony . To zabiło wymagania 1 i 2.

W przypadku wymagania 3 musieliśmy przechowywać strony autorów z obrazem profilu, małą biografią i innymi danymi. Czytając dokumentację, wyglądało na to, że może się nadawać pliki danych gdzie możemy mieć każdego autora jako plik toml. Jest nawet Problem z GitHubem otwarty od Hugo 0.16 w celu ujednolicenia tego, więc powinniśmy mieć jeszcze lepsze wsparcie w przyszłości. Ok, wymóg 3 został oficjalnie zabity.

Przed uruchomieniem implementacji pozostało tylko jedno: jak poradzić sobie z funkcją wyszukiwania w witrynach statycznych? Odkryliśmy, że istnieją dwie opcje:

1. Skorzystaj z usług dostawcy wyszukiwania. Najczęstsze są Algolia i Google Custom Search .
2. Zaimplementuj nasze własne indeksowanie i wyszukiwanie za pomocą biblioteki wyszukiwania pełnotekstowego po stronie klienta, takiej jak lunr lub elasticlunr .

Pozostawilibyśmy ten wybór na później; na tym etapie musieliśmy tylko wiedzieć, czy było to możliwe. Odpowiedź brzmiała tak: wymóg 4 nie był już problemem.

Wniosek

Z perspektywy czasu decyzja o użyciu Hugo okazała się bardzo udana. Cała witryna jest tworzona w czasie krótszym niż 400 ms , a każdy programista w biurze może poprawnie zainstalować Hugo w ciągu kilku sekund w celu rozwoju lokalnego.

Dziękuje spf13 i wszystko ludzie, którzy zbudowali Hugo . Stworzyłeś niesamowite narzędzie!

W następnym poście zagłębimy się w to, jak strona jest rzeczywiście generowana i jak rozwiązaliśmy niektóre z pojawiających się problemów. Zaprezentujemy nowoczesny przepływ pracy dla strony statycznej, używając Hugo i Webpack . Jeśli nie chcesz tego przegapić, upewnij się Zapisz się do naszego newslettera .