// Jak stworzyłem bloga w Next.js (stack, CMS, hosting, SEO)

Uszanowanko!

Jak powstało buildandmarket.dev ?

Kiedy wpadłem na "genialny" pomysł, żeby zacząć pisać bloga o marketingu z punktu widzenia programisty, to pierwotnie najbardziej mnie kręciła strona techniczna. Mogę stworzyć nową stronkę. Nowy framework do przetestowania. Projektowanie UI. Ale cały myk tego bloga polega na tym, żeby więcej działać, a mniej kminić.

Decydując się na pisanie bloga, musiałem podjąć decyzję, w czym go stworzyć. Opcji było kilka:

• WordPress - archaiczne, chciałem coś świeższego
• Next.js - znana mi technologia, dobre pod SEO ze względu na SSG, lekki overkill jak na bloga
• Astro - fajne, szybkie, komponenty można pisać w różnych frameworkach
• Medium/Substack - nie chciałem vendor-lockin, dodatkowo łatwiej eksperymentować z SEO i konwersją jeśli mam pełną kontrolę nad blogiem

WordPressa odrzuciłem, bo jednak chciałem coś świeższego i z mniejszą ilością klikania po UI, żeby coś skonfigurować. Medium też odpadł, bo jednak chciałem mieć kontrolę nad każdym aspektem aplikacji.

Więc na co się zdecydowałem? ... werble ... Next.js

Tak wygląda cały blog pod maską

CMS do bloga

Ale właśnie. Blog nie kończy się na UI. Trzeba go jakoś zasilić treścią, więc do gry wkroczył Strapi jako CMS bloga, który hostuje na Railway. Rozważałem też Payload CMS, ale z tego już kiedyś korzystałem, więc teraz chciałem przetestować coś nowego. Na blogu może będą się czasem pojawiać jakieś fotki, a te trzeba gdzieś hostować i tu sięgnąłem po R2 storage na Cloudflare.

Jakie są korzyści z Next.js w blogu?

• łatwy hosting - repo na GitHubie podpiąłem do Vercel i automatycznie po merge PR do maina blog się przebudowuje i publikuje najnowszą wersję
• Server Actions - cała logika newslettera działa po stronie serwera, więc nic nie wycieknie do klienta
• React - bardzo szybkie budowanie UI, używam komponentów shadcn/ui, które odpowiednie wystylizowałem
• Server Components - zdecydowana większość komponentów jest generowana po stronie serwera, żeby ograniczyć wysyłany JS do przeglądarki do minimum
• SSG i ISR - SSG, czyli cała strona jest generowana po stronie serwera przy buildzie bloga, nic więcej nie trzeba dodawać. ISR, czyli Incremental Static Regeneration jest z deczka ciekawsze. Strony nadal są generowane po stronie serwera, ale jeśli zrobię jakąś zmianę po stronie CMS, np. dodam nowy, lub zedytuję istniejący post, to CMS strzela do aplikacji i Next.js automatycznie przebudowuje tylko te strony, które zedytowałem, więc nie muszę się niczym przejmować i zawsze mam wydajne strony, które same się przebudowują

Jak działa ISR w Next.js

Przy pobieraniu postów tworzę im odpowiedni tag:

fetchStrapi<StrapiPost[]>("posts", {
    tags: ["posts"],
}),

Odświeżanie postów poprzez tag:

if (payload.model === "post") {
    revalidateTag("posts", "max");
}

I to tyle. Dlaczego to jest lepsze niż pełny rebuild? Mając np. 200 postów, w dwóch wersjach językowych, to jest 400 stron do zbudowania. Dzięki ISR, jeśli zrobię zmianę tylko na jednej stronie, to przebudowuję jedną stronę, a nie 400.

Wynik Lighthouse dla posta buildandmarket.dev

Narzędzia, które wykorzystuję

Poza samym stackiem blog korzysta z kilku narzędzi marketingowych i analitycznych:

MailerLite

Zależały mi też na przechwyceniu części ruchu na stronie do newslettera dla zainteresowanych. Przez chwilę miałem pomysł na zbudowanie autorskiego systemu, ale na szczęście szybko to odrzuciłem - dla mojego użytku to byłby overkill. Lepiej skorzystać z gotowego rozwiązania i skupić się na tworzeniu treści. Więc sięgnałem po MailerLite. Całkiem fajne rozwiązanie. Mogę tam utworzyć dedykowane grupy dla każdej wersji językowej i dodać automatyzację, która wysyła powitalnego maila po zapisaniu się.

PostHog

Ekspertem od UI/UX to ja nie jestem, ale zrobiłem co mogłem na tym blogu. Ale właśnie "co mogłem" nie wystarczy, żeby wiedzieć czy to działa. Mogę zgadywać i udawać, że czytam ludziom w myślach, ale koniec końców to będzie moja subiektywna opinia. Skąd mam wiedzieć, czy ktoś rzeczywiście czyta moje posty, czy ucieka ze strony po przeczytaniu pierwszego zdania. Na ratunek przybył PostHog. Mogę zobaczyć co robi odwiedzający stronę, gdzie klika, a gdzie nie, jak daleko scrollował i po jakim czasie opuścił stronę. Dodatkowym atutem są europejskie serwery, na których jest hostowany PostHog. I oczywiście wszystko odpala się dopiero po zaakceptowaniu cookies. :)

Sentry

Potrzebowałem też w jakiś sposób śledzić potencjalne błędy, które mogą, acz nie muszą, się pojawiać (liczę, że to się raczej nie zdarzy, ale nigdy nie wiadomo). Tutaj wykorzystałem klasykę gatunku, czyli Sentry. Bardzo sprawna i przyjemna konfiguracja.

Dwujęzyczność (next-intl)

Bloga od początku tworzyłem pod kątem dwujęzyczności: polski i angielski. Dodawanie i18n w późniejszych etapach może być problematyczne, więc polecam zrobić to od razu. Do obsługi dwujęzyczności użyłem next-intl, co pozwoliło mi zlokalizować URL (nie tylko prefixy, ale całe ścieżki). Słownik pojęć jest dostępny pod /pl/slownik i /en/glossary, strona "o mnie" /pl/o-mnie i /en/about. Google widzi to jako dwie osobne strony z poprawnym hreflang, a nie duplikaty.

Podsumowanie