Przebudowa dużej witryny e-commerce za pomocą Next.js (studium przypadku)

W naszej firmie Unplatform od dziesięcioleci budujemy witryny e-commerce. Przez te lata widzieliśmy, jak stos technologii ewoluował od stron renderowanych przez serwer z niewielkimi skryptami JavaScript i CSS do pełnych aplikacji JavaScript.

Platforma, z której korzystaliśmy w naszych witrynach e-commerce, była oparta na ASP.NET, a gdy odwiedzający zaczęli oczekiwać większej interakcji, dodaliśmy React do interfejsu. Chociaż mieszanie koncepcji architektury sieciowej serwera, takiej jak ASP.NET, z platformą sieciową po stronie klienta, taką jak React, komplikowało sprawę, byliśmy całkiem zadowoleni z rozwiązania. Tak było, dopóki nie przeszliśmy do produkcji z naszym klientem o największym natężeniu ruchu. Od momentu rozpoczęcia transmisji mieliśmy problemy z wydajnością . Kluczowe wskaźniki sieciowe są ważne, tym bardziej w e-commerce. W badaniu Deloitte: Milliseconds Make Millions badacze przeanalizowali dane z witryn mobilnych 37 różnych marek. W rezultacie odkryli, że poprawa wydajności o 0,1 s może prowadzić do 10% wzrostu konwersji.

Aby złagodzić problemy z wydajnością, musieliśmy dodać wiele (niezabudżetowanych) dodatkowych serwerów i musieliśmy agresywnie buforować strony na odwrotnym proxy. To nawet wymagało od nas wyłączenia części funkcjonalności witryny. Skończyło się na tym, że otrzymaliśmy naprawdę skomplikowane i drogie rozwiązanie, które w niektórych przypadkach po prostu statycznie obsługiwało niektóre strony.

Oczywiście nie wydawało się to w porządku, dopóki nie dowiedzieliśmy się o Next.js . Next.js to platforma internetowa oparta na React, która umożliwia statyczne generowanie stron, ale nadal możesz korzystać z renderowania po stronie serwera, dzięki czemu idealnie nadaje się do handlu elektronicznego. Może być hostowany w sieci CDN, takiej jak Vercel lub Netlify, co skutkuje mniejszym opóźnieniem . Vercel i Netlify również używają funkcji bezserwerowych do renderowania po stronie serwera, co jest najbardziej wydajnym sposobem skalowania.

Wyzwania

Programowanie za pomocą Next.js jest niesamowite, ale na pewno są pewne wyzwania. Doświadczenie programisty z Next.js to coś, czego po prostu musisz doświadczyć. Napisany przez Ciebie kod natychmiast wizualizuje się w Twojej przeglądarce, a produktywność rośnie w przestworzach. Jest to również ryzyko, ponieważ możesz zbytnio skoncentrować się na produktywności i zaniedbać konserwację kodu. Z biegiem czasu to i nieopisana natura JavaScriptu może prowadzić do degradacji bazy kodu. Liczba błędów wzrasta, a produktywność zaczyna spadać.

Może to być również wyzwaniem po stronie środowiska wykonawczego . Najmniejsze zmiany w kodzie mogą prowadzić do spadku wydajności i innych kluczowych wskaźników internetowych. Ponadto nieostrożne korzystanie z renderowania po stronie serwera może prowadzić do nieoczekiwanych kosztów obsługi.

Przyjrzyjmy się bliżej naszym lekcjom wyciągniętym z pokonywania tych wyzwań.

1. Modularyzuj swoją bazę kodów
2. Lint i sformatuj swój kod
3. Użyj TypeScript
4. Planuj wydajność i mierz wydajność
5. Dodaj kontrole wydajności do swojej bramki jakości
6. Dodaj testy automatyczne
7. Agresywnie zarządzaj swoimi zależnościami
8. Użyj usługi agregacji dzienników
9. Funkcjonalność przepisywania Next.js umożliwia stopniowe przyjmowanie
   

Wyciągnięta lekcja: Modularyzacja bazy kodu

Frameworki front-end, takie jak Next.js, ułatwiają rozpoczęcie pracy w dzisiejszych czasach. Po prostu uruchamiasz npx create-next-app i możesz zacząć kodować. Ale jeśli nie będziesz ostrożny i zaczniesz tworzyć kod, nie myśląc o projektowaniu, możesz skończyć z wielką kulą błota.

Po uruchomieniu npx create-next-app , będziesz mieć strukturę folderów podobną do poniższej (tak jest również struktura większości przykładów):

 /public logo.gif /src /lib /hooks useForm.js /api content.js /components Header.js Layout.js /pages Index.js

Zaczęliśmy od tej samej struktury. Mieliśmy kilka podfolderów w folderze components dla większych komponentów, ale większość komponentów znajdowała się w folderze root components. Nie ma nic złego w tym podejściu i sprawdza się w przypadku mniejszych projektów. Jednak wraz z rozwojem naszego projektu coraz trudniej było zrozumieć komponenty i miejsce ich użycia. Znaleźliśmy nawet komponenty, które w ogóle nie były już używane! Promuje również wielką kulę błota, ponieważ nie ma jasnych wskazówek, jaki kod powinien być zależny od innego kodu.

Aby rozwiązać ten problem, zdecydowaliśmy się na refaktoryzację bazy kodu i pogrupowanie kodu według modułów funkcjonalnych (coś w rodzaju modułów NPM) zamiast koncepcji technicznych:

 /src /modules /catalog /components productblock.js /checkout /api cartservice.js /components cart.js

W tym małym przykładzie mamy moduł kasy i moduł katalogu. Grupowanie kodu w ten sposób prowadzi do lepszej wykrywalności: wystarczy spojrzeć na strukturę folderów, aby dokładnie wiedzieć, jaki rodzaj funkcjonalności znajduje się w bazie kodu i gdzie ją znaleźć. Ułatwia to również wnioskowanie o zależnościach . W poprzedniej sytuacji między komponentami było dużo zależności. Otrzymaliśmy prośby o zmiany w kasie, które również wpłynęły na komponenty katalogu. Zwiększyło to liczbę konfliktów scalania i utrudniło wprowadzanie zmian.

Najlepszym rozwiązaniem dla nas było ograniczenie zależności między modułami do absolutnego minimum (jeśli naprawdę potrzebujesz zależności, upewnij się, że jest ona jednokierunkowa) i wprowadzenie poziomu „projektu”, który wszystko spaja:

 /src /modules /common /atoms /lib /catalog /components productblock.js /checkout /api cartservice.js /components cart.js /search /project /layout /components /templates productdetail.js cart.js /pages cart.js

Wizualny przegląd tego rozwiązania:

Poziom projektu zawiera kod układu strony e-commerce i szablony stron. W Next.js składnik strony jest konwencją i prowadzi do fizycznej strony. Z naszego doświadczenia wynika, że ​​strony te często wymagają ponownego wykorzystania tej samej implementacji, dlatego wprowadziliśmy pojęcie „szablonów stron”. Szablony stron wykorzystują komponenty z różnych modułów, na przykład szablon strony szczegółów produktu będzie używał komponentów z katalogu do wyświetlania informacji o produkcie, ale także komponentu dodawania do koszyka z modułu kasy.

Mamy też wspólny moduł, ponieważ jest jeszcze trochę kodu, który musi zostać ponownie wykorzystany przez moduły funkcjonalne. Zawiera proste atomy, które są komponentami React używanymi do zapewnienia spójnego wyglądu i stylu. Zawiera również kod infrastruktury, pomyśl o pewnych ogólnych hakach reakcji lub kodzie klienta GraphQL.

Ostrzeżenie : Upewnij się, że kod we wspólnym module jest stabilny i zawsze zastanów się dwa razy przed dodaniem kodu tutaj, aby zapobiec plątaninie kodu.

Mikro-front-endy

W jeszcze większych rozwiązaniach lub podczas pracy z różnymi zespołami sensowne może być rozbicie aplikacji jeszcze bardziej na tak zwane mikro-frontendy. Krótko mówiąc, oznacza to jeszcze większy podział aplikacji na wiele aplikacji fizycznych, które są hostowane niezależnie pod różnymi adresami URL. Na przykład: checkout.mydomain.com i katalog.mojadomena.com. Są one następnie integrowane przez inną aplikację, która działa jako proxy.

Funkcjonalność przepisywania Next.js jest do tego świetna, a używanie jej w ten sposób jest obsługiwane przez tak zwane Multi Zones.

Zaletą wielu stref jest to, że każda strefa zarządza własnymi zależnościami. Ułatwia również stopniową ewolucję bazy kodu: jeśli pojawi się nowa wersja Next.js lub React, możesz aktualizować strefy jedna po drugiej, zamiast aktualizować cały kod na raz. W organizacji wielozespołowej może to znacznie zmniejszyć zależności między zespołami.

Dalsza lektura

• „Struktura projektu Next.js”, Yannick Wittwer, Medium
• „Przewodnik 2021 dotyczący strukturyzowania projektu Next.js w elastyczny i wydajny sposób”, Vadorequest, Dev.to.
• „Mikro frontendy”, Michael Geers

Wyciągnięta lekcja: lint i formatowanie kodu

To jest coś, czego nauczyliśmy się we wcześniejszym projekcie: jeśli pracujesz w tej samej bazie kodu z wieloma osobami i nie używasz programu formatującego, Twój kod wkrótce stanie się bardzo niespójny. Nawet jeśli używasz konwencji kodowania i robisz przeglądy, wkrótce zaczniesz zauważać różne style kodowania, dając niechlujne wrażenie kodu.

Linter sprawdzi Twój kod pod kątem potencjalnych problemów, a program formatujący upewni się, że kod jest sformatowany w spójny sposób. Używamy ESLint i ładniejszych i uważamy, że są niesamowite. Nie musisz myśleć o stylu kodowania, zmniejszając obciążenie poznawcze podczas programowania.

Na szczęście Next.js 11 obsługuje teraz ESLint po wyjęciu z pudełka (https://nextjs.org/blog/next-11), dzięki czemu konfiguracja jest bardzo łatwa dzięki uruchomieniu npx next lint. Oszczędza to dużo czasu, ponieważ zawiera domyślną konfigurację dla Next.js. Na przykład jest już skonfigurowany z rozszerzeniem ESLint dla Reacta. Co więcej, jest wyposażony w nowe rozszerzenie specyficzne dla Next.js, które wykryje nawet problemy z Twoim kodem, które mogą potencjalnie wpłynąć na kluczowe wskaźniki sieciowe Twojej aplikacji! W następnym akapicie porozmawiamy o bramkach jakości, które mogą pomóc w zapobieganiu wypychaniu kodu do produktu, który przypadkowo uszkadza Twoje kluczowe elementy sieci. To rozszerzenie zapewnia znacznie szybsze przekazywanie informacji zwrotnych, dzięki czemu jest świetnym dodatkiem.

Dalsza lektura

• „ESLint”, Next.js Docs
• „ESLint”, oficjalna strona internetowa

Wyciągnięta lekcja: Użyj TypeScript

Gdy komponenty zostały zmodyfikowane i zrefaktoryzowane, zauważyliśmy, że niektóre właściwości komponentów nie były już używane. Ponadto w niektórych przypadkach napotkaliśmy błędy z powodu brakujących lub nieprawidłowych typów rekwizytów przekazywanych do komponentów.

TypeScript to nadzbiór JavaScriptu i dodaje typy, co pozwala kompilatorowi na statyczne sprawdzanie kodu, coś w rodzaju lintera na sterydach.

Na początku projektu nie widzieliśmy tak naprawdę wartości dodawania TypeScriptu. Czuliśmy, że to tylko niepotrzebna abstrakcja. Jednak jeden z naszych kolegów miał dobre doświadczenia z TypeScript i przekonał nas do spróbowania. Na szczęście Next.js ma świetną obsługę TypeScript po wyjęciu z pudełka, a TypeScript umożliwia stopniowe dodawanie go do rozwiązania. Oznacza to, że nie musisz przepisywać ani konwertować całego kodu za jednym razem, ale możesz zacząć go używać od razu i powoli konwertować resztę kodu.

Gdy rozpoczęliśmy migrację komponentów do TypeScript, natychmiast znaleźliśmy problemy z przekazywaniem błędnych wartości do komponentów i funkcji. Ponadto pętla informacji zwrotnych od deweloperów uległa skróceniu i otrzymujesz powiadomienia o problemach przed uruchomieniem aplikacji w przeglądarce. Inną dużą korzyścią, którą odkryliśmy, jest to, że znacznie ułatwia refaktoryzację kodu: łatwiej jest zobaczyć, gdzie kod jest używany i od razu zauważasz nieużywane właściwości komponentów i kod. Krótko mówiąc, zalety TypeScript:

1. Zmniejsza liczbę błędów
2. Ułatwia refaktoryzację kodu
3. Kod staje się łatwiejszy do odczytania

Dalsza lektura

• „TypeScript”, Next.js Docs
• TypeScript, oficjalna strona internetowa

Wyciągnięta lekcja: Planuj wydajność i mierz wydajność

Next.js obsługuje różne typy renderowania wstępnego: generowanie statyczne i renderowanie po stronie serwera. Aby uzyskać najlepszą wydajność, zaleca się stosowanie generowania statycznego, co ma miejsce w czasie kompilacji, ale nie zawsze jest to możliwe. Pomyśl o stronach szczegółów produktu, które zawierają informacje o stanie magazynowym. Tego rodzaju informacje często się zmieniają, a uruchamianie kompilacji za każdym razem nie skaluje się dobrze. Na szczęście Next.js obsługuje również tryb o nazwie Incremental Static Regeneration (ISR), który wciąż statycznie generuje stronę, ale co x sekund generuje nową w tle. Dowiedzieliśmy się, że ten model świetnie sprawdza się w większych aplikacjach. Wydajność jest nadal świetna, wymaga mniej czasu procesora niż renderowanie po stronie serwera i skraca czas kompilacji: strony są generowane tylko przy pierwszym żądaniu. Dla każdej dodanej strony powinieneś pomyśleć o rodzaju potrzebnego renderowania. Najpierw sprawdź, czy możesz użyć generowania statycznego; jeśli nie, wybierz przyrostową regenerację statyczną, a jeśli to również nie jest możliwe, nadal możesz korzystać z renderowania po stronie serwera.

Next.js automatycznie określa typ renderowania na podstawie braku na stronie metod getServerSideProps i getInitialProps . Łatwo o pomyłkę, która może spowodować, że strona będzie renderowana na serwerze, zamiast być generowana statycznie. Dane wyjściowe kompilacji Next.js pokazują dokładnie, która strona używa jakiego typu renderowania, więc sprawdź to. Pomaga również monitorować produkcję i śledzić wydajność stron oraz zaangażowany czas procesora. Większość dostawców usług hostingowych pobiera opłaty na podstawie czasu procesora, co pomaga uniknąć nieprzyjemnych niespodzianek. Opiszę, jak to monitorujemy w wyciągniętej lekcji: Użyj akapitu usługi agregacji logów.

Rozmiar pakietu

Aby uzyskać dobrą wydajność, kluczowe jest zminimalizowanie rozmiaru pakietu. Next.js ma wiele funkcji, które pomagają, np. automatyczne dzielenie kodu. Dzięki temu na każdej stronie zostanie załadowany tylko wymagany JavaScript i CSS. Generuje również różne pakiety dla klienta i serwera. Jednak ważne jest, aby mieć na to oko. Na przykład, jeśli zaimportujesz moduły JavaScript w niewłaściwy sposób, JavaScript serwera może trafić do pakietu klienta, znacznie zwiększając rozmiar pakietu klienta i obniżając wydajność. Dodanie zależności NPM może również znacząco wpłynąć na rozmiar pakietu.

Na szczęście Next.js zawiera analizator pakietów, który daje wgląd w to, który kod zajmuje jaką część pakietów.

Dalsza lektura

• „Next.js + analizator pakietów Webpack”, Vercel, GitHub
• „Pobieranie danych” Next.js Docs

Wyciągnięta lekcja: Dodaj testy wydajności do swojej bramki jakości

Jedną z dużych korzyści płynących z używania Next.js jest możliwość statycznego generowania stron i możliwość wdrażania aplikacji na brzegu sieci (CDN), co powinno skutkować doskonałą wydajnością i kluczowymi działaniami sieciowymi. Dowiedzieliśmy się, że nawet przy świetnej technologii, takiej jak Next.js, uzyskanie i utrzymanie świetnego wyniku latarni morskiej jest naprawdę trudne. Kilka razy zdarzyło się, że po wdrożeniu pewnych zmian w produkcji punktacja latarni znacznie spadła. Aby odzyskać kontrolę, do naszej bramki jakości dodaliśmy automatyczne testy latarni. Dzięki tej akcji Github możesz automatycznie dodawać testy latarni do swoich żądań ściągnięcia. Używamy Vercel i za każdym razem, gdy tworzone jest żądanie ściągnięcia, Vercel wdraża je pod adresem URL podglądu i używamy akcji Github do uruchamiania testów latarni względem tego wdrożenia.

Jeśli nie chcesz samodzielnie konfigurować akcji GitHub lub jeśli chcesz zrobić to jeszcze dalej, możesz również rozważyć usługę monitorowania wydajności innej firmy, taką jak DebugBear. Vercel oferuje również funkcję Analytics, która mierzy kluczowe wskaźniki sieciowe wdrożenia produkcyjnego. Vercel Analytics faktycznie zbiera pomiary z urządzeń użytkowników, więc te wyniki są naprawdę tym, czego doświadczają użytkownicy. W chwili pisania tego tekstu Vercel Analytics działa tylko we wdrożeniach produkcyjnych.

Wyciągnięta lekcja: Dodaj testy automatyczne

Gdy baza kodu staje się większa, trudniej jest określić, czy zmiany w kodzie mogły zepsuć istniejącą funkcjonalność. Z naszego doświadczenia wynika, że ​​niezbędny jest dobry zestaw kompleksowych testów jako siatki bezpieczeństwa. Nawet jeśli masz mały projekt, możesz znacznie ułatwić sobie życie, gdy wykonasz przynajmniej kilka podstawowych testów dymu. Używamy do tego Cypressa i absolutnie go uwielbiamy. Połączenie wykorzystania Netlify lub Vercel do automatycznego wdrażania Twojego żądania Pull w środowisku tymczasowym i przeprowadzania testów E2E jest bezcenne.

Używamy cypress-io/GitHub-action aby automatycznie uruchamiać testy cypress dla naszych pull requestów. W zależności od typu oprogramowania, które budujesz, cenne może być również posiadanie bardziej szczegółowych testów przy użyciu Enzyme lub JEST. Kompromis polega na tym, że są one ściślej powiązane z twoim kodem i wymagają więcej konserwacji.

Wyciągnięta lekcja: agresywnie zarządzaj swoimi zależnościami

Zarządzanie zależnościami staje się czasochłonną, ale jakże ważną czynnością przy utrzymywaniu dużej bazy kodu Next.js. NPM sprawił, że dodawanie pakietów jest tak łatwe i wydaje się, że w dzisiejszych czasach istnieje pakiet na wszystko. Patrząc wstecz, wiele razy, gdy wprowadzaliśmy nowy błąd lub mieliśmy spadek wydajności, miało to coś wspólnego z nowym lub zaktualizowanym pakietem NPM.

Dlatego przed zainstalowaniem pakietu zawsze powinieneś zadać sobie następujące pytania:

• Jaka jest jakość opakowania?
• Co będzie oznaczać dodanie tego pakietu dla mojego rozmiaru pakietu?
• Czy ten pakiet jest naprawdę potrzebny, czy są alternatywy?
• Czy pakiet jest nadal aktywnie utrzymywany?

Aby utrzymać mały rozmiar pakietu i zminimalizować wysiłek potrzebny do utrzymania tych zależności, ważne jest, aby liczba zależności była jak najmniejsza. Twoje przyszłe ja podziękuje Ci za to, gdy będziesz utrzymywać oprogramowanie.

Porada : Rozszerzenie VSCode Import Cost automatycznie pokazuje rozmiar importowanych pakietów.

Bądź na bieżąco z wersjami Next.js

Nadążanie za Next.js i React jest ważne. Nie tylko zapewni ci dostęp do nowych funkcji, ale nowe wersje będą również zawierać poprawki błędów i poprawki potencjalnych problemów z bezpieczeństwem. Na szczęście Next.js sprawia, że ​​aktualizacja jest niezwykle łatwa, dostarczając Codemods (https://nextjs.org/docs/advanced-features/codemods. Są to automatyczne przekształcenia kodu, które automatycznie aktualizują Twój kod.

Aktualizuj zależności

Z tego samego powodu ważne jest, aby wersje Next.js i React były aktualne; ważne jest również zaktualizowanie innych zależności. Dependabot Github (https://github.com/dependabot) może tutaj naprawdę pomóc. Automatycznie utworzy pull requesty ze zaktualizowanymi zależnościami. Jednak aktualizowanie zależności może potencjalnie zepsuć różne rzeczy, więc posiadanie zautomatyzowanych testów end-to-end może naprawdę uratować życie.

Wyciągnięta lekcja: Użyj usługi agregacji dzienników

Aby upewnić się, że aplikacja działa poprawnie i zapobiegawczo znajdować problemy, stwierdziliśmy, że absolutnie konieczne jest skonfigurowanie usługi agregacji dzienników. Vercel umożliwia logowanie się i przeglądanie dzienników, ale są one przesyłane strumieniowo w czasie rzeczywistym i nie są utrwalane. Nie obsługuje również konfigurowania alertów i powiadomień.

Niektóre wyjątki mogą zająć dużo czasu. Na przykład skonfigurowaliśmy nieaktualność podczas sprawdzania poprawności dla konkretnej strony. W pewnym momencie zauważyliśmy, że strony nie są odświeżane i podawane są stare dane. Po sprawdzeniu rejestrowania Vercel odkryliśmy, że podczas renderowania strony w tle wystąpił wyjątek. Korzystając z usługi agregacji dzienników i konfigurując alert o wyjątkach, moglibyśmy to zauważyć znacznie wcześniej.

Usługi agregacji dzienników mogą być również przydatne do monitorowania limitów planów cenowych firmy Vercel. Strona użytkowania Vercel również daje wgląd w to, ale korzystanie z usługi agregacji dzienników umożliwia dodawanie powiadomień po osiągnięciu określonego progu. Lepiej zapobiegać niż leczyć, zwłaszcza jeśli chodzi o rachunki.

Vercel oferuje szereg gotowych integracji z usługami agregacji dzienników, w tym Datadog, Logtail, Logalert, Sentry i nie tylko.

Dalsza lektura

• „Integracje”, Vercel

Wyciągnięta lekcja: Funkcja przepisywania Next.js umożliwia stopniowe przyjmowanie

O ile nie ma poważnych problemów z obecną witryną, niewielu klientów będzie podekscytowanych przepisaniem całej witryny. Ale co by było, gdybyś mógł zacząć od przebudowy tylko tych stron, które mają największe znaczenie pod względem wskaźników internetowych? Dokładnie to zrobiliśmy dla innego klienta. Zamiast przebudowywać całą witrynę, odbudowujemy tylko te strony, które mają największe znaczenie dla SEO i konwersji. W tym przypadku szczegóły produktu i strony kategorii. Przebudowując te z Next.js, wydajność znacznie wzrosła.

Funkcjonalność przepisywania Next.js jest do tego świetna. Zbudowaliśmy nowy interfejs Next.js zawierający strony katalogu i wdrożyliśmy go w sieci CDN. Wszystkie inne istniejące strony są przepisywane przez Next.js do istniejącej witryny. W ten sposób możesz zacząć czerpać korzyści z witryny Next.js przy niewielkim nakładzie pracy lub przy niskim ryzyku.

Dalsza lektura

• „Przepisuje”, Next.js Docs

Co dalej?

Kiedy wydaliśmy pierwszą wersję projektu i zaczęliśmy przeprowadzać poważne testy wydajności, byliśmy zachwyceni wynikami. Nie tylko czasy odpowiedzi strony i wskaźniki sieciowe były znacznie lepsze niż wcześniej, ale koszty operacyjne były również ułamkiem tego, co było wcześniej. Next.js i JAMStack generalnie umożliwiają skalowanie w najbardziej opłacalny sposób.

Przejście z architektury bardziej zorientowanej na back-end na coś takiego jak Next.js to duży krok. Krzywa uczenia się może być dość stroma i początkowo niektórzy członkowie zespołu naprawdę czuli się poza swoją strefą komfortu. Małe poprawki, które wprowadziliśmy, wnioski wyciągnięte z tego artykułu, naprawdę w tym pomogły. Ponadto doświadczenie programistyczne z Next.js zapewnia niesamowity wzrost wydajności. Cykl opinii programistów jest niesamowicie krótki!

Dalsza lektura

• „Przechodzenie do produkcji”, Next.js Docs