PRPL pattern

PRPL pattern, czyli wzorzec przyszłości

Jakie cechy powinny posiadać dzisiejsze nowoczesne aplikacje? Większość pewnie od razu pomyśli „mobile-friendly„. To prawda – strony, które nie są responsywne, nie działają na tabletach/smartfonach maści wszelakiej – nie mają prawa bytu. A druga cecha? Wydajność, szybkość. Zgadłam? I tu pojawia się konflikt interesów. Zauważmy, że dzisiejsze serwisy są bardziej złożone niż hello world sprzed kilku lat. Okazuje się, że napisanie wydajnej, mobilnej aplikacji nie jest już takie proste.

Na pewno znacie to uczucie, kiedy czekacie na załadowanie się jakiejś strony. Z nadzieją w oczach obserwujemy, jak poszczególne składowe aplikacji ładują się na naszym małym ekranie. Potulnie czekamy, aż zniknie ten ostatni loader.

prpl pattern
Źródło: https://medium.com/@addyosmani/progressive-web-apps-with-react-js-part-2-page-load-performance-33b932d97cf2

Fioletowy wzorzec

I tak powstał wzorzec PRPL (wymawiany jak słowo purple). To nie jest zbiór technologii, nawet nie do końca zbiór technik. Jak sama dokumentacja mówi, to wizja stron responsywnych ORAZ szybkich, sposób myślenia o nich w kontekście ich optymalizacji, zwiększenia wydajności. Wszystko to, co pojawia się na stronie, ma być w mgnieniu oka interaktywne, w pełni funkcjonalne i użyteczne dla użytkownika. Zero klikania na przycisk, który jeszcze nie zdążył zaciągnąć obsługującego go skryptu.

Przykład strony napisanej zgodnie ze wzorcem PRPL znajdziecie TUTAJ.

PRPL to wzorzec, według którego powinno budować się PWA (aplikacje progresywne – opisywałam je już TUTAJ). Został on wymyślony przez developerów frameworka Polymer, bazuje na najnowszych technologiach. Jego twórcy ochoczo zachęcają do samodzielnej pracy nad ich wizją, adaptacji własnych pomysłów, ścigania nieistniejącego jeszcze ideału PRPL. Jednocześnie podają kilka kroków, które stanowią bazę całej magii.

PUSH critical resources for the initial route
RENDER the initial route and get it interactive asap
PRE-CACHE code for remaining routes
LAZY LOAD & create next routes on-demand

PUSH

Pobierz na początku najważniejsze elementy strony. Serwer wysyła minimum zasobów, które są wymagane do poprawnego działania konkretnej ścieżki URL. Skorzystaj z HTTP2 push. Pobrane źródła zapisz w pamięci podręcznej za pomocą Service Workerów. Przy ich kolejnym żądaniu załadują się błyskawicznie.

RENDER

Wyrenderuj totalne minimum, które uczyni stronę w pełni funkcjonalną dla użytkownika w ułamku senkundy.

PRE-CACHE

W czasie, kiedy użytkownik przegląda stronę pod ścieżką A, pobierz i zapisz w pamięci podręcznej pozostałe zasoby potrzebne dla kolejnych ścieżek, które nie są aktywne. Skorzystaj z Service Workerów (opisywałam je krótko przy okazji PWA TUTAJ). Renderowanie ścieżek, dla których zasoby są już zapisane w cache SW, będzie następowało super-giga-szybko. Mało tego – w trybie offline użytkownik korzysta ze wszystkiego, co już zostało zapisane w cache SW. To zawsze więcej niż szary dinozaur z chrome.

LAZY LOAD

Dynamicznie ładuj treści z pamięci podręcznej wtedy, kiedy one będą potrzebne – kiedy użytkownik przejdzie na kolejną zakładkę, zażąda dane dla kolejnej ścieżki. Jeśli zażądane zasoby nie są jeszcze w cache SW, pobierz je, wyrenderuj co trzeba, a następnie zapisz w pamięci podręcznej.

Koniec z bundlowaniem

Już nam nie zależy na bundlowaniu zasobów. Ładowanie całego serwisu niezależnie od interesującej nas zakładki musi być niewydajne. To tak, jakbyś chciał zjeść najpierw pierwsze danie – zupę ogórkową, a następnie deser – lody truskawkowe. A kelnerzy na siłę wcisnęliby Ci pierwsze danie, drugie, trzecie plus deser, a następnie po chwili to samo – pierwsze danie, drugie, trzecie i deser. Olaboga!

Aby to wszystko działało, serwer musi umieć zidentyfikować zasoby, które są wymagane dla konkretnych ścieżek. Zamiast pakowania wszystkich zasobów do jednej paczki i wysłania ich za pomocą HTTP2, PRPL korzysta z innej super mocy HTTP2 – obsługi mechanizmu push dla serwera. Serwer dynamicznie, na bieżąco ma dostarczać poszczególne zasoby, które są potrzebne do wyrenderowania konkretnej ścieżki.

Nie wszystko złoto, co się świeci…

Fioletowy wzorzec wykorzystuje świetne, nowoczesne technologie: HTTP2 server push, Service Workers. Polega on też na rozbijaniu aplikacji na małe komponenty, a jego twórcami są ludzie od Polymera, także wzorzec chcąc nie chcąc reklamuje też mocno Web Components.

Czy możemy już tak od dziś budować aplikacje zgodnie z PRPL? Oczywiście, że tak. Jednak nie możemy zapominać o średnim wsparciu pushy z HTTP2 wśród przeglądarek/serwerów albo o przeciętnym wsparciu przeglądarek dla Service Workerów. Oczywiście da się zrobić PRPL-alike aplikację bez pushy i SW. Wilk syty i owca cała. Mimo to owe pushe i SW to najlepsze praktyki i chcąc rozwijać internety powinniśmy z nich korzystać.

Uwaga! Nigdy nie napisałam żadnej apki zgodnie z PRPL. Zabieram się do mojej pierwszej PWA. Powyższe informacje to mój internetowy research na temat PRPL. Jeśli coś tu mieszam, koniecznie dajcie znać w komentarzach! Edukujmy się nawzajem

Dla zainteresowanych

Jeśli chcecie trochę kodu i technicznego mięska: KLIK!

Jeśli wolicie słuchać youtuba zamiast czytać długie artykuły: KLIK! (od 28:29), KLIK! (od 34:09)

Taka w sumie „dokumentacja”: KLIK!

Artykuły, które mogą Ci się spodobać...

Wpisz hasło, którego szukasz i naciśnij ENTER, aby je wyszukać. Naciśnij ESC, aby anulować.

Dawaj na górę