Podstawy JAMstack: co, co i jak

Uwielbiamy przesuwać granice w sieci, dlatego postanowiliśmy spróbować czegoś nowego. Prawdopodobnie słyszałeś o JAMstack — nowym stosie internetowym opartym na JavaScript, interfejsach API i znacznikach — ale co to oznacza dla twojego przepływu pracy i kiedy ma to sens w twoich projektach?

W ramach naszego członkostwa Smashing co tydzień prowadzimy serię webinariów na żywo Smashing TV . Bez puchu — tylko praktyczne, dające możliwość działania webinaria z pytaniami i odpowiedziami na żywo, prowadzone przez szanowanych praktyków z branży. Rzeczywiście, program telewizyjny Smashing wygląda już dość napięty i jest bezpłatny dla członków Smashing Members, wraz z nagraniami — oczywiście .

Uprzejmie poprosiliśmy Phila Hawkswortha o przeprowadzenie webinaru wyjaśniającego, co tak naprawdę oznacza JAMStack i kiedy ma to sens, a także jak wpływa na narzędzia i architekturę front-end. Dostępne jest również jednogodzinne webinarium. Nie moglibyśmy być szczęśliwsi mogąc powitać Phila jako współ-MC w nadchodzącym SmashingConf Toronto (25-26 czerwca) i poprowadzić JAMStack_conf London, które współorganizujemy również w dniach 9-10 lipca tego roku. Więc przejdźmy do tego!

Phil Hawksworth: Świetnie, dobrze, więc przejdźmy do tego. W ramach bardzo szybkiego powitania, to znaczy, że już się przywitałem, Scott dał mi miłe wprowadzenie. Ale tak, obecnie pracuję w Netlify, pracuję tam w zespole developerskim. Mamy nadzieję, że będziemy mieć dużo czasu na pytania i odpowiedzi, ale, jak wspomniał Scott, jeśli nie będziesz miał okazji zadać tam pytań, lub jeśli po prostu wolisz, możesz wysłać je bezpośrednio do mnie na Twitterze, więc mój Twitter obsługuje to moje imię, to Phil Hawksworth, więc w każdej chwili możesz zadać mi pytania dotyczące JAMstack lub czegokolwiek na Twitterze.

Phil Hawksworth: Ale chciałbym zacząć dzisiaj od pewnego rodzaju cofnięcia się w czasie do tego cytatu, który naprawdę bardzo, bardzo mocno we mnie rezonuje. To cytat ze wspaniałego Aarona Schwartza, który oczywiście tak bardzo przyczynił się do Creative Commons i otwartej sieci, i napisał to na swoim blogu w 2002 roku, i powiedział: „Zależy mi na tym, żeby nie musiałem utrzymywać zepsutego Instalacje serwera AOL, Postgres i Oracle.” Serwer AOL, musiałem spojrzeć w górę, aby przypomnieć sobie, że w tamtym czasie był serwerem internetowym o otwartym kodzie źródłowym.

Phil Hawksworth: Ale to bardzo mocno do mnie pasuje. Nie chcę też utrzymywać infrastruktury, aby utrzymać bloga przy życiu, io tym właśnie mówił. I to było w tym wpisie na jego własnym blogu i nosiło tytuł „Piecz, nie smaż”. Wybierał termin, którego zaczął używać ktoś, kto niedawno zbudował CMS, i w pewnym sensie spopularyzował to określenie dotyczące pieczenia (piecz, nie smaż); to, o czym mówi, to wstępne renderowanie, a nie renderowanie na żądanie, więc pieczenie treści z wyprzedzeniem, zamiast smażenia jej na żądanie, gdy ludzie przychodzą i o to proszą — odsuwanie rzeczy od czasu żądania i na rodzaj czasu kompilacji.

Phil Hawksworth: A kiedy mówimy o prerenderowaniu i renderowaniu, rozumiemy przez to, że mówimy o generowaniu znaczników. Czuję się trochę skrępowany, mówiąc czasami o renderowaniu serwera lub renderowaniu izomorficznym lub wielu tego rodzaju modnych terminach; Zostałem wezwany kilka lat temu na konferencji Frontiers Conference w Amsterdamie, kiedy mówiłem o renderowaniu na serwerze i ktoś powiedział do mnie: „Masz na myśli generowanie HTML? Po prostu coś, co generuje kod HTML?” I to oczywiście mam na myśli.

Phil Hawksworth: Ale wszystko to znacznie ułatwia uproszczenie stosu. Kiedy myślimy o stosie, z którego obsługujemy strony internetowe; Staram się uprościć rzeczy, bardzo chętnie próbuję uprościć stos. I to jest w pewnym sensie sedno tej rzeczy zwanej „JAMstack” i chcę spróbować to trochę wyjaśnić. „JAM” w JAMstack oznacza JavaScript, API i znaczniki. Ale to naprawdę nie wystarczy, aby zrozumieć, co to znaczy — co to naprawdę oznacza?

Phil Hawksworth: Cóż, chciałbym spróbować i zrobić w ciągu najbliższych pół godziny, to chcę rozszerzyć tę definicję i podać więcej opisu tego, czym jest JAMstack. Chcę trochę opowiedzieć o wpływie i konsekwencjach JAMstack i, wiesz, zastanów się, co może nam to dać i dlaczego możemy go wybrać. Po drodze spróbuję wspomnieć o niektórych narzędziach i usługach, które będą przydatne, i mam nadzieję, że omówię niektóre zasoby, które możesz chcieć zagłębić i być może wymienię kilka pierwszych kroków, aby Cię zdobyć w toku.

Phil Hawksworth: A więc taki jest plan na następne pół godziny. Ale chciałbym, w pewnym sensie, wrócić do idei uproszczenia stosu, ponieważ miejmy nadzieję, że ludzie, którzy dołączą do tego lub przyszli obejrzeć ten film później, być może masz pojęcie o tym, czym jest JAMstack, lub może to zupełnie nowy termin, a ty jesteś po prostu ciekawy. Ale ostatecznie istnieje już wiele stosów. Istnieje wiele sposobów dostarczania strony internetowej. Wygląda na to, że od bardzo dawna budujemy różne rodzaje infrastruktury, niezależnie od tego, czy jest to stos LAMP, stos MAMP, czy — nie wiem — stos MEAN. Kilka z nich unosi się na ekranie. Jest ich bardzo dużo.

Phil Hawksworth: Więc po co, u licha, potrzebowalibyśmy jeszcze jednego? Cóż, JAMstack to, jak wspomniałem, JavaScript/API/Markup, ale jeśli spróbujemy trochę bardziej opisowo, JAMstack ma być nowoczesną architekturą, aby pomóc w tworzeniu szybkich i bezpiecznych stron oraz dynamicznych aplikacji z JavaScript/ Interfejsy API i wstępnie renderowane znaczniki, obsługiwane bez serwerów internetowych, i to jest ten ostatni punkt, który jest czymś, co go wyróżnia i być może czyni go trochę bardziej, w pewnym sensie, interesującym i niezwykłym.

Phil Hawksworth: To pojęcie serwowania czegoś bez serwerów internetowych, które brzmi albo magicznie, albo śmiesznie, i miejmy nadzieję, że dowiemy się, co po drodze. Ale aby spróbować rzucić nieco światła na to i opisać to nieco bardziej szczegółowo, czasami przydatne jest porównanie tego z czymś, co moglibyśmy nazwać tradycyjnym stosem lub tradycyjnym sposobem serwowania rzeczy w sieci. Więc zróbmy to tylko przez chwilę. Przyjrzyjmy się, być może, jak może wyglądać żądanie, gdy jest obsługiwane w tradycyjnym stosie.

Phil Hawksworth: W tym scenariuszu ktoś otwiera przeglądarkę internetową i zgłasza prośbę o wyświetlenie strony. I może to żądanie trafia do CDN, ale prawdopodobnie, bardziej prawdopodobne, uderzyło w inną infrastrukturę, którą hostujemy – jako ludzie, którzy są właścicielami tej witryny. Może staraliśmy się upewnić, że będzie się to skalować pod dużym obciążeniem, ponieważ oczywiście chcemy, aby widok był bardzo popularny i odnoszący sukcesy. Być może dostaliśmy load balancer, który ma w sobie pewną logikę, który obsłuży to żądanie do jednego z wielu serwerów internetowych, które zaaprowizowaliśmy, skonfigurowaliśmy i wdrożyliśmy. Może być kilka takich serwerów.

Phil Hawksworth: A te serwery wykonają pewną logikę, aby powiedzieć: „Ok, oto nasz szablon, musimy wypełnić go pewnymi danymi”. Możemy uzyskać nasze dane z jednego z wielu serwerów bazodanowych, które wykonają pewną logikę, aby wyszukać niektóre dane, zwrócić je do serwera WWW, utworzyć widok, który następnie prześlemy z powrotem przez system równoważenia obciążenia. Być może po drodze dzwonienie do CDN, przechowywanie niektórych zasobów w CDN i powinienem wyjaśnić, że CDN to sieć dostarczania treści, a więc sieć maszyn rozproszonych w Internecie, aby spróbować uzyskać obsługę żądań jak najbliżej do użytkownika i dodawać rzeczy, takie jak buforowanie.

Phil Hawksworth: Moglibyśmy więc przechowywać tam pewne zasoby, a ostatecznie przywrócić widok w przeglądarce, w oczy użytkownika, który będzie mógł następnie zapoznać się ze zbudowaną przez nas witryną. Więc oczywiście jest to albo nadmierne uproszczenie, albo bardzo ogólny pogląd na to, jak możemy obsłużyć żądanie w tradycyjnym stosie. Jeśli porównamy to do JAMstack, który obsługuje rzeczy w nieco inny sposób, tak może wyglądać.

Phil Hawksworth: I znowu, ten sam scenariusz, zaczynamy w przeglądarce internetowej. Wysyłamy prośbę o wyświetlenie strony, która jest już w sieci CDN. Stamtąd działa statycznie, więc jest zwracany do użytkownika, do przeglądarki i gotowe. A więc oczywiście bardzo uproszczony widok, ale od razu widać tu różnice pod względem złożoności. Jeśli chodzi o miejsca, w których potrzebujemy zarządzać kodem, kodować głęboko, wszystkie te różne rzeczy. Tak więc dla mnie jednym z podstawowych atrybutów JAMstack jest to, że oznacza to, że budujesz witrynę, która może być obsługiwana bezpośrednio z CDN, a nawet ze statycznego serwera plików. CDN to coś, co możemy chcieć wprowadzić, aby obsłużyć obciążenie, ale ostatecznie może to być obsługiwane bezpośrednio z dowolnego rodzaju statycznego serwera plików, rodzaju statycznej infrastruktury hostingowej.

Phil Hawksworth: JAMstack, w pewnym sensie, oferuje możliwość zmniejszenia złożoności. Porównując te dwie części diagramu, do których wrócimy kilka razy w ciągu najbliższych pół godziny, widać, że jest to okazja do zmniejszenia złożoności i zmniejszenia ryzyka. Oznacza to, że możemy zacząć czerpać korzyści z obsługi zasobów statycznych, a o tym, czym one są, opowiem nieco później. Ale być może patrzysz na to i myślisz: „Świetnie, ale czy to nie jest tylko nowa nazwa dla statycznych stron internetowych?” To rozsądna rzecz, aby się ze mną zmierzyć, kiedy mówię: „Zamierzamy służyć rzeczom statycznie”.

Phil Hawksworth: Ale chcę do tego wrócić. Chciałbym o tym porozmawiać trochę więcej, ale przede wszystkim chciałbym porozmawiać o tym pojęciu stosów i czym tak właściwie jest stos? I myślę o stosie jako o warstwach technologii, które dostarczają twoją stronę internetową lub aplikację. I nie mówimy o potoku kompilacji ani procesie rozwoju, ale z pewnością sposób, w jaki obsługujemy witryny, może mieć duży wpływ na to, jak programujemy i wdrażamy, i tak dalej.

Phil Hawksworth: Ale tutaj mówimy o stosie technologicznym, warstwach technologii, które faktycznie dostarczają Twoją witrynę i aplikację użytkownikom. Zróbmy więc kolejne małe porównanie. Porozmawiajmy przez chwilę o stosie LAMP.

Phil Hawksworth: Być może pamiętasz, że stos LAMP składa się z serwera WWW Apache, służącego do wykonywania takich czynności, jak routing HCP i obsługa zasobów statycznych. PHP, do wstępnego przetwarzania, więc ładne przetwarzanie hipertekstu; stosując logikę, może budując widoki dla szablonów i co masz. I ma pewien dostęp do twoich danych przez mój NISQL, a LINUX jest systemem operacyjnym, który znajduje się pod tym wszystkim, utrzymuje to wszystko. Możemy to połączyć teoretycznie jako ten serwer sieciowy. I możemy mieć wiele z tych serwerów, w pewnym sensie siedzących razem, aby obsługiwać witrynę internetową.

Phil Hawksworth: To rodzaj tradycyjnego spojrzenia na stos LAMP i jeśli porównamy go do stosu JAM, cóż, tutaj następuje krytyczna zmiana. Tutaj w rzeczywistości idziemy na wyższy poziom, zamiast myśleć o systemie operacyjnym i myśleć o tym, jak uruchamiamy logikę, aby dostarczyć stronę internetową. Tutaj zakładamy, że będziemy służyć tym rzeczom statycznie. Tak więc robimy routing ACP i udostępniamy zasoby ze statycznego serwera. Można to rozsądnie zrobić. Przez lata staliśmy się w tym bardzo dobrzy, budując sposoby dostarczania statycznych stron internetowych lub statycznych zasobów.

Phil Hawksworth: To może być CDN i znowu porozmawiamy o tym za chwilę. Ale obszar, który nas interesuje, dzieje się bardziej w przeglądarce. Tak więc tutaj jest dostarczany i analizowany nasz znacznik. To tutaj może wykonać JavaScript, a dzieje się to w przeglądarce. Pod wieloma względami przeglądarka stała się środowiskiem wykonawczym współczesnego internetu. Zamiast mieć środowisko uruchomieniowe w samej infrastrukturze serwera, teraz przenieśliśmy to na wyższy poziom, bliżej użytkownika i do przeglądarki.

Phil Hawksworth: Jeśli chodzi o dostęp do danych, cóż, dzieje się to prawdopodobnie za pośrednictwem zewnętrznych interfejsów API, wywoływania tych zewnętrznych interfejsów API za pośrednictwem JavaScriptu w celu uzyskania dostępu do serwera lub możemy myśleć o interfejsach API jako o interfejsach API przeglądarki, umożliwiających interakcję z JavaScriptem z możliwościami bezpośrednio w Twojej przeglądarce.

Phil Hawksworth: Tak czy inaczej, kluczem do JAMstack jest to, że mówimy o rzeczach, które są wstępnie renderowane: są wyświetlane statycznie, a następnie mogą być stopniowo ulepszane w przeglądarce, aby korzystać z interfejsów API przeglądarki, JavaScripts i co masz.

Phil Hawksworth: Zróbmy więc to małe porównanie. Ponownie, chcę tylko powtórzyć, że JAMstack przeniósł się na wyższy poziom w przeglądarce. A jeśli zobaczymy dwie strony tego diagramu, ze stosem LAMP po lewej stronie i faktycznie stosem JAM po prawej, możesz nawet pomyśleć, że nawet kiedy budowaliśmy rzeczy ze stosem LAMP, nadal jesteśmy wyprowadzanie marży. Nadal wysyłamy JavaScript. Być może nadal uzyskujemy dostęp do interfejsów API. Tak więc pod wieloma względami JAMstack jest prawie jak podzbiór tego, co budowaliśmy wcześniej.

Phil Hawksworth: Czasami mówiłem o JAMstack jako o gwarantowanym stosie, ponieważ zapewnia zestaw narzędzi i technologii, których potrzebujemy, aby dostarczyć witrynę. Ale tak czy inaczej, jest to znacznie uproszczony sposób dostarczania witryny, który w pewnym sensie eliminuje potrzebę wykonywania i wykonywania logiki na serwerze w czasie żądania.

Phil Hawksworth: Więc to może zrobić wiele rzeczy. To może, w pewnym sensie, uprościć wdrożenia i znowu będę od czasu do czasu odwoływać się do tego diagramu. Jeśli pomyślimy o tym, jak wdrażamy nasz kod i naszą witrynę, przy każdym wdrożeniu, od pierwszego, przez cały cykl rozwoju, aż do życia witryny. W tradycyjnym stosie być może będziemy musieli zmienić logikę i zawartość każdego pola na tym diagramie.

Phil Hawksworth: Podczas gdy w JAMstack, kiedy mówimy o wdrożeniu, mówimy o przekazywaniu rzeczy do CDN, przekazywaniu rzeczy na statyczny serwer i to jest to, co pociąga za sobą wdrożenie. Kompilacja, rodzaj logiki, która uruchamia kompilację — która może działać w dowolnym miejscu. To nie musi działać w tym samym środowisku, w którym znajduje się serwer sieciowy. W rzeczywistości tak nie jest! Uruchamia klucz do JAMstack. Oddzielamy to, co dzieje się w czasie żądania, obsługując te statyczne zasoby, w porównaniu z tym, co dzieje się w czasie kompilacji, co może być twoją logiką, którą uruchamiasz w celu kompilacji, a następnie wdrożenia.

Phil Hawksworth: Tak więc ten rodzaj oddzielenia jest kluczową rzeczą i wrócę do tego później. Jesteśmy bardzo dobrzy w udostępnianiu plików statycznych, a przesyłanie rzeczy do CDN lub do systemu plików (serwera plików) jest czymś, co zaobserwowaliśmy ogromny postęp w ciągu ostatnich kilku lat. Obecnie istnieje wiele narzędzi i procesów, które mogą nam w tym pomóc. Wystarczy przywołać kilka usług, które mogą dobrze obsługiwać zasoby statyczne i zapewnić przepływy pracy podczas przenoszenia kompilacji do tego środowiska, zwykle podejrzewasz, że możesz wyobrazić sobie dostawców infrastruktury dużych chmur, takich jak Azure, AWS i Google Cloud.

Phil Hawksworth: Ale są też inne. Tak więc górna po prawej to usługa o nazwie Surge, która istnieje od kilku lat. Umożliwia uruchamianie polecenia w środowisku kompilacji i wdrażanie zasobów w środowisku hostingu. Netlify, następny niżej, to miejsce, w którym pracuję i robimy bardzo to samo, ale mamy też inną automatyzację. Mogę wejść w to innym razem. A ta na dole, kolejna strona ze statycznym środowiskiem hostingowym, o nazwie Now.

Phil Hawksworth: Jest więc wiele różnych opcji, aby to zrobić, a wszystkie te przestrzenie zapewniają różne narzędzia do dotarcia do CDN tak szybko, jak to możliwe. Wdrażanie witryn w najbardziej bezproblemowy sposób. I wszystkie mają coś wspólnego, ponieważ opierają się na zasadzie prowadzenia czegoś lokalnie. Często myślę o generatorze statycznych witryn jako o czymś, co możemy uruchomić w kompilacji, która po uruchomieniu pobiera takie rzeczy, jak zawartość i szablony, a może dane z różnych usług, i generuje coś, co może być obsługiwane statycznie.

Phil Hawksworth: Możemy to sprawdzić lokalnie na naszym statycznym serwerze. Coś, co jest dość proste do zrobienia w dowolnym lokalnym środowisku programistycznym, a następnie proces wdrażania, który polega na przeniesieniu tego do środowiska hostingowego, a najlepiej do sieci CDN w celu uzyskania pewnego rodzaju skali. Tak więc, mając taki fundament, chcę zająć się trochę powszechnym nieporozumieniem, jeśli chodzi o strony JAMstack. I nie zrobiłem sobie żadnej przysługi, otwierając to jako opisujące witryny JAMstack jako JavaScript, API i znaczniki. Ponieważ powszechnym błędnym przekonaniem jest to, że każda witryna JAMstack musi zawierać JavaScript, API i znaczniki, ale przeoczyliśmy to, że nie musimy używać wszystkich trzech — każda z nich jest czymś w rodzaju , opcjonalny. Możemy ich używać tak dużo lub tak mało, jak tylko chcemy. W ten sam sposób, w jaki witryna stosu LAMP niekoniecznie musiałaby trafiać do bazy danych. Teraz zbudowałem w przeszłości rzeczy, które są obsługiwane przez serwer Apache, na maszynie z systemem Linux i używałem PHP, ale nie uderzałem w bazę danych i nie zacząłbym zmieniać nazwy stosu koniecznie do tego.

Phil Hawksworth: Więc jeśli pomyślimy o tym, czym jest strona JAMstack, może to być kilka różnych rzeczy. Może to być coś, co jest zbudowane za pomocą statycznego generatora witryn, takiego jak Jekyll, pobierającego zawartość z plików YAML w celu zbudowania witryny, która nie ma JavaScript, w ogóle nie trafia do interfejsów API, a my obsługujemy ją na czymś, takim jak GitHub Pages. Albo byłaby to witryna JAMstack. A może używamy generatora stron statycznych, takiego jak Gatsby, który jest raczej w środowisku Ruby dla Jekyll, teraz jest to generator stron statycznych JavaScript zbudowany w ekosystemie React.

Phil Hawksworth: To może być znowu ściąganie zawartości i porządkowanie plików Markdown. Może wzbogacić to o wywołania API, API GraphQL. Może to być wykonywanie czynności w przeglądarce, na przykład hydratacja JavaScript w wypełnianiu szablonów bezpośrednio w przeglądarce. I może być obsługiwany na Amazon S3. Czy to strona JAMStack? Tak oczywiście!

Phil Hawksworth: Przechodząc do innego generatora stron statycznych, Hugo, który jest zbudowany z Go! Ponownie, możemy organizować zawartość w plikach Markdown, dodając interakcje w przeglądarce za pomocą JavaScript. Może nie wywoływanie żadnych zewnętrznych interfejsów API i może hostowanie ich w Google Cloud. Czy to JAMstack? Absolutnie! Widzisz, buduję tutaj temat. Używając czegoś takiego jak Nuxt, innego statycznego generatora witryn, teraz wbudowanego w ekosystem View. Może to ściąganie treści z różnych sąsiednich plików? Ponownie, możemy używać interakcji JavaScript w przeglądarce, być może wywołując interfejsy API do robienia takich rzeczy jak e-commerce, udostępniając mu inną statyczną witrynę. Inna infrastruktura hostingowa, taka jak Netlify, czy to JAMstack? Tak to jest!

Phil Hawksworth: Ale możemy nawet przejść, no wiesz, odejść również na ten boczny koniec skali. I pomyśl o ręcznie robionej, progresywnej aplikacji internetowej, którą zbudowaliśmy ręcznie, ręcznie w języku JavaScript, którą zbudowaliśmy sami. Pakujemy to w webpack. Być może używamy tokenów internetowych JavaScript i wywołujemy interfejsy API w celu uwierzytelniania, interakcji z różnymi interfejsami API przeglądarki i hostowania ich na platformie Azure. Tak, to też JAMstack!

Phil Hawksworth: I wiesz, wszystkie te rzeczy i wiele innych można uznać za JAMstack, ponieważ wszystkie mają wspólny atrybut, a to oznacza, że ​​żadna z nich nie jest obsługiwana przez serwer pochodzenia. Żaden z nich nie musi trafić na serwer, który wykonuje logikę w czasie żądania. Są one obsługiwane jako zasoby statyczne, a następnie wzbogacane o JavaScript i wywołania API.

Phil Hawksworth: Więc znowu chcę tylko powtórzyć, że JAMstack oznacza, że ​​można go obsługiwać bezpośrednio z CDN. Tak więc, chciałbym tylko przywołać niektóre skutki i implikacje tego, ponieważ dlaczego mielibyśmy to robić? Cóż, pierwsze pojęcie dotyczy bezpieczeństwa, a tutaj mamy znacznie zmniejszoną powierzchnię do ataku. Jeśli myślimy (powracając do tego starego schematu) o miejscach, w których możemy mieć do czynienia z atakiem, musimy zabezpieczyć takie rzeczy jak load balancer, serwery WWW, serwery baz danych. Wszystkie te rzeczy musimy upewnić się, że nie zostaną przeniknięte przez jakikolwiek atak, a także CDN.

Phil Hawksworth: Im więcej elementów uda nam się wyciągnąć z tej układanki, tym mniej miejsc do zaatakowania i tym mniej miejsc, które musimy zabezpieczyć. Posiadanie kilku ruchomych części do ataku jest naprawdę bardzo cenne. W Netlify obsługujemy własne sieci CDN, więc możemy sobie pozwolić na luksus monitorowania ruchu, który na nie trafia, i chociaż wszystkie witryny hostowane na Netlify, wszystkie witryny JAMstack, które możesz sobie wyobrazić, żadna z nich mieć na nich stronę administratora WordPress, ponieważ jest całkowicie oddzielona. Nie ma administratora WordPress, ale widzimy ogromny ruch, sondujący takie rzeczy, jak WP Admin, szukający sposobów, szukający wektorów ataku.

Phil Hawksworth: Naprawdę uwielbiam niektóre rzeczy, które zrobił Kent C. Dodds. Nie wiem, czy znasz społeczność Reacta, prawdopodobnie spotkałeś się z Kent C. Doddsem w przeszłości. Nie używa WordPressa, ale nadal kieruje ten adres URL, WPAdmin. Myślę, że zwykł przekierowywać go do wideo Rick Rolla na YouTube. Z pewnością troluje ludzi, którzy wyruszyli na poszukiwania. Ale chodzi o to, że rozdzielając rzeczy w ten sposób i przenosząc rzeczy, które się wydarzają, czas budowania od tego, co dzieje się w czasie żądania, możemy po prostu drastycznie zmniejszyć naszą ekspozycję. Na żądanie nie mamy żadnych ruchomych części. Wszystkie ruchome części są całkowicie oddzielone w czasie budowy. Potencjalnie na zupełnie, no, koniecznie na zupełnie innej infrastrukturze.

Phil Hawksworth: To oczywiście również ma wpływ na wydajność. Wracając do naszego starego przyjaciela tutaj, miejsc, w których moglibyśmy chcieć spróbować poprawić wydajność na całym stosie, gdy istnieje logika, która musi być wykonana w tych różnych miejscach. Sposób, w jaki często się to dzieje w tradycyjnych stosach, polega na tym, że zaczynają dodawać warstwy, dodawać warstwy statyczne, aby poprawić wydajność. Innymi słowy, spróbuj znaleźć sposoby, dzięki którym możemy zacząć zachowywać się tak, jakby była statyczna. Nie trzeba wykonywać tej logiki na każdym poziomie stosu, aby przyspieszyć działanie. Tak więc zaczynamy wprowadzać takie rzeczy, jak buforowanie w całej infrastrukturze i oczywiste miejsca, które możemy znaleźć do zrobienia, które znajdują się na serwerze sieciowym, zamiast wykonywać tę logikę, chcemy obsłużyć coś natychmiast bez wykonywania tej logiki.

Phil Hawksworth: Więc jest to krok w stronę pseudo-statycznego bycia. Podobnie w przypadku serwerów bazodanowych, chcemy dodać warstwy buforowania do zapytań cache-com. Nawet przy niskim saldzie, cały CDN można traktować jako pamięć podręczną. Ale na tradycyjnym stosie musimy dowiedzieć się, jak zarządzać tą pamięcią podręczną, ponieważ nie wszystko zostanie zbuforowane. Więc jest trochę logiki. Co należy zapełnić dynamicznie, a co można buforować. A w modelu JAMstack wszystko jest buforowane. Całość jest buforowana od momentu wykonania wdrożenia, więc możemy myśleć o tym zupełnie inaczej.

Phil Hawksworth: To też zaczyna w pewnym sensie wskazywać na skalowanie. A w skali, mówię o tym, jak radzimy sobie z dużym natężeniem ruchu? Tradycyjne stosy zaczną dodawać infrastrukturę w celu skalowania. A więc tak, do buforowania. Zaczynamy wprowadzać nasz tradycyjny stos. To pomoże — do pewnego stopnia. Zwykle dzieje się tak, że aby obsłużyć duży ruch, zaczniemy rozbudowywać infrastrukturę i dodawać kolejne serwery, więcej elementów do obsługi tych żądań, kosztowanie tych rzeczy i szacowanie obciążenia jest dużym kosztem ogólnym i może być bólem głowy dla każdego, kto zajmuje się architekturą techniczną. Z pewnością było to dla mnie, dlatego zacząłem bardziej skłaniać się ku podejściu JAMstack, w którym po prostu wiem, że wszystko jest obsługiwane z CDN, który jest domyślnie zaprojektowany do obsługi skali, do obsługi wydajności zaraz po wyjściu z bramki .

Phil Hawksworth: Chciałbym również ukłonić się w stronę doświadczenia deweloperów i wpływu, jaki może to mieć na to. Teraz doświadczenie programisty nigdy nie powinno być postrzegane jako coś, co przebija wrażenia użytkownika, ale wierzę, że dobre wrażenia programisty mogą zmniejszyć tarcia, mogą pozwolić programistom na znacznie lepszą pracę w budowaniu wspaniałych doświadczeń użytkowników!

Phil Hawksworth: Tak więc, kiedy myślimy o tym, gdzie mieszka programista i gdzie znajdują się obszary zainteresowania programisty: cóż, w tradycyjnym stosie, być może będziemy musieli zastanowić się, w jaki sposób dostajemy kod do wszystkich tych różnych części infrastruktury i jak wszystkie one ze sobą współgrają. W świecie JAMstack naprawdę mówimy o tym pudełku na dole. Wiesz, jak uruchomiliśmy kompilację i ich, jak zautomatyzować wdrożenie, aby coś zostało obsłużone w pierwszej kolejności? I fajną rzeczą jest to, że w modelu JAMstack to, co zrobisz w tej wersji, zależy wyłącznie od Ciebie.

Phil Hawksworth: To naprawdę dobrze zdefiniowana przestrzeń problemów, ponieważ ostatecznie próbujesz zbudować coś, co możesz obsłużyć bezpośrednio z CDN. Chcesz coś wstępnie wyrenderować, używając dowolnych narzędzi: niezależnie od tego, czy jest to statyczny generator witryn zbudowany w Ruby, Pythonie, JavaScript, Go czy PHP, masz swobodę wyboru. W ten sposób możesz stworzyć znacznie przyjemniejsze środowisko do pracy. Stwarza to również szansę na uzyskanie prawdziwej pewności programisty, ponieważ prawdziwym atrybutem witryn JAMstack jest to, że można je znacznie łatwiej obsługiwać jako niezmienne i atomowe wdrożenie.

Phil Hawksworth: I chciałbym na chwilę oderwać się od slajdów, aby opisać, co to oznacza, ponieważ wdrożenie niezmienne i wdrożenie atomowe może… (to może brzmieć trochę jak marketing), ale co mam zamiar zrobić, to wskoczyć do mojej przeglądarki. Teraz… właściwie, wrócę na chwilę. Pozwól mi… po prostu to zrobić.

Phil Hawksworth: Oto jesteśmy. To będzie łatwiejsze. Skok prosto na stronę. Teraz, Scott, powiesz mi Scott, jeśli nie widzisz mojej przeglądarki, mam nadzieję. Teraz zakładając, że wszyscy widzą moją przeglądarkę.

Scott: Wszystko wygląda dobrze.

Phil Hawksworth: Świetnie ! Dziękuję bardzo!

Phil Hawksworth: Więc to, co tutaj robię, to używam Netlify jako przykładu, jako przykładu usługi. Jest to jednak atrybut wspólny dla witryn, które mogą być hostowane statycznie. Tak więc, kiedy mówimy o niezmiennym wdrożeniu, mamy na myśli to, że każde wdrożenie kodu musi dotykać wielu różnych części infrastruktury i zmieniać wiele rzeczy, tutaj nie mutujemy stanu witryny na serwer. Dla każdego wdrożenia, które miało miejsce, tworzymy zupełnie nową instancję witryny. I możemy to zrobić, ponieważ witryna jest zbiorem statycznych zasobów.

Phil Hawksworth: Tutaj patrzę na wdrożenie, które miało miejsce z mojej własnej strony internetowej. Dam ci smakołyk. Oto jesteś, tak to wygląda. To tylko blog, nie wygląda na coś szczególnie niezwykłego ani ekscytującego. Jest to blog generowany statycznie, ale to, co mam tutaj, to każde wdrożenie, które kiedykolwiek miało miejsce, żyje w nieskończoność, ponieważ jest to zbiór statycznych zasobów, które są obsługiwane z CDN. Teraz mógłbym cofnąć się tak daleko, jak tylko moja historia może mnie ponieść, i spojrzeć na stronę, tak jak było w… kiedy to było? To był sierpień 2016 r. Dzięki temu, że jest to zestaw statycznych zasobów, jesteśmy w stanie przechowywać to pod własnym adresem URL, który działa bez końca, a gdybym chciał, mógłbym go opublikować zastosowanie.

Phil Hawksworth: Więc teraz każdy, kto przegląda moją witrynę, jeśli wrócę do mojej witryny tutaj, odświeżę tę stronę, teraz jest ona obsługiwana bezpośrednio z CDN z zasobami, które były tam wcześniej. Teraz mogę znowu nawigować. Tutaj możesz zobaczyć. Słuchaj, gadałem o tym, używałem tych okropnych terminów, takich jak renderowanie izomorficzne i mówiłem o JAMstack w 2016 roku. Więc to jest teraz wyświetlane na żywo na mojej stronie. Znowu, ponieważ istnieją wzajemne wdrożenia, które po prostu żyją wiecznie. Zamierzam po prostu zapewnić sobie spokój ducha, zamierzam — czy to jest pierwsza strona? Tak. Wrócę do mojego ostatniego wdrożenia. Będę musiał ponownie się zamknąć i przenieść mnie z powrotem do prawdziwego świata. Upewnię się tylko, że wszystko w porządku.

Phil Hawksworth: OK! Świetnie! A więc teraz wracam do obsługi mojej poprzedniej wersji lub najnowszej wersji witryny. Wrócę do przemówienia. Jest to więc możliwe, ponieważ rzeczy są niezmienne i atomowe. Atomowa część tego oznacza ponownie, że wdrożenie jest całkowicie ograniczone. Tak więc nigdy nie dojdziesz do punktu, w którym niektóre zasoby są dostępne na serwerze sieciowym, ale niektóre z nich nie. Dopiero gdy wszystko jest w kontekście i wszystko jest kompletne, przełączamy obsługę witryny do nowej wersji. Ponownie, jest to coś, co możesz zrobić znacznie łatwiej, jeśli tworzysz witrynę JAMstack, która służy bezpośrednio z CDN jako zbiór zasobów.

Phil Hawksworth: Zauważyłem, że mój timer zresetował się po przejściu wstecz i do przodu od prezentacji, więc myślę, że zostało mi około sześciu lub siedmiu minut. Powiedz mi, Scott, jeśli…

Scott: Więc tak, nadal jesteśmy dobrzy przez około dziesięć minut.

Phil Hawksworth: Dziesięć minut? W porządku, cudownie!

Scott: Nie ma pośpiechu.

Phil Hawksworth: Dziękuję, to powinno być dobre!

Phil Hawksworth: Tak więc, po prostu zmieniając trochę sprzęt i rozmawiając o API i usługach (ponieważ API jest częścią JAMstack), rodzaj usług, z których możemy wtedy korzystać, to głównie JAMstack. Wiesz, być może korzystamy z usług, które zbudowaliśmy we własnym zakresie, lub możemy korzystać z usług zakupionych. Jest wielu różnych dostawców, którzy mogą coś dla nas zrobić, a to dlatego, że to ich wiedza. Za pośrednictwem interfejsów API możemy pobierać treści z systemów zarządzania treścią jako usługę, a istnieje grupa różnych dostawców, którzy specjalizują się w zapewnianiu doskonałego zarządzania treścią, a następnie udostępnianiu treści za pomocą interfejsu API, więc kiedyś byłeś w stanie ich wciągnąć.

Phil Hawksworth: Podobnie istnieją różne sposoby obsługi zasobów. Ludzie tacy jak Cloudary są w tym świetni, jeśli chodzi o optymalizację obrazu, udostępnianie zasobów bezpośrednio w witrynach, ponownie za pośrednictwem interfejsów API. A co z e-commerce? Wiesz, są miejsca takie jak Stripe lub Snipcart, które mogą dostarczyć nam API, dzięki czemu nie musimy sami budować tych usług i wchodzić w bardzo złożone problemy, które pojawiają się przy próbie zbudowania silnika e-commerce. Podobnie tożsamość od osób takich jak Auth0, które używają Oauth. Dostępnych jest wiele usług i możemy je wykorzystywać za pośrednictwem interfejsów API, w przeglądarce lub w czasie kompilacji, a czasami kombinacji obu.

Phil Hawksworth: Now, some people might think, “Well, that's fine, but I don't want to give the keys to the kingdom away. I don't want to risk giving these services over to external providers,” and to that, I say, well, you know, vendors who provide a single service really depend on its success. If there's a company that's core business, or entire business, is in building-out an e-Commerce engine, an e-Commerce service for you, they're doing that for all of their clients, all of their customers, so they really depend on its success and they have the specialist skills to do that.

Phil Hawksworth: So, that kind of de-risks it from you a great deal. Especially when you start to factor in the fact that you can have your technical and service-level contracts to give you that extra security. But it's not all about bought services, it's also about services you can build yourselves. Now, there's a number of ways that this can happen, but sometimes, you absolutely need a little bit of logic on the server. And so far, I've just been talking about taking the server out of the equation. So, how do we do that?

Phil Hawksworth: Well, this is where serverless can really come to the rescue. Serverless and JAMstack, they just fit together really beautifully. And when I'm talking about serverless, I'm talking about no functions as a service. I know that serverless can be a bit of a loaded term, but here, I'm talking about functions as a service. Because functions as a service can start to enable a real micro-services architecture. Using things like AWS Lambda or Google Cloud functions or similar functions as a service, can allow you to build out server infrastructure without a server. Now, you can start deploying JavaScript logic to something that just runs on demand.

Phil Hawksworth: And that means, you can start supplementing some of these other services with, maybe, very targeted small services you build yourselves that can run the serverless functions. These kind of smaller services are easier to reason about, understand, build out and they create much greater agility. I want to just mention a few examples and results from JAMstack sites. I'm not going to go down the server list avenue too much, right now. We can, maybe, come back to that in the questions. I really just kind of want to switch gear and, thinking about time a little bit, talk about some examples and results.

Phil Hawksworth: Because there are some types of sites that lend themselves in a very obvious way to a JAMstack site. Things like the documentation for React, or Vuejs, those [inaudible 00:32:40], pre-rendered JAMstacks sites. As do sites for large companies, such as Citrix, this is a great example of Citrix multi-language documentation. You can actually view the video from the JAMstack conference that happened in New York, where Beth Pollock had worked on this project, talked about the change that went on in that project. From building on traditional, non-enterprised infrastructure to a JAMstack approach and building with Jekyll, which is not necessarily the fastest generating static site generator, but still, they saw a huge improvement.

Phil Hawksworth: Beth talked about the turnaround time for updates went from weeks to minutes. Maybe people are kind of frowning at the idea of weeks for updates to sites, but sometimes in big complex infrastructure, with lots of stakeholders and lots of moving parts, this really is the situation we're often finding ourselves in. Beth also talked about estimating the annual cost savings for this move to a JAMstack site. To get the site running properly, estimated their savings of around 65%. That's huge kind of savings. Changing gear to a slightly different type of site, something a little closer to home, Smashing Magazine itself is a JAMstack site, which might be a little bit surprising, because on one hand, yes, there's lots of articles and it's also content, which is published regularly, but not every minute of the day, for sure.

Phil Hawksworth: So, that might lend itself, perhaps, for something that's pre-generated, but of course, there's also a membership area and an event section, and a job board, and e-Commerce, and all of these things. This is all possible on the JAMstack because not only are we pre-rendering, but we're also enriching things with JavaScript and the front end to call out to APIs, which let some of these things happen. The project that I think I saw Vitaly arrive in the call, so that's going to be good, we might be able to come back to this in a few minutes.

Phil Hawksworth: But the project that migrated, Smashing Magazine onto a JAMstack approach, I believe, simplified the number of platforms from five, effectively down to one. And I'm using Vitaly's words directly here: Vitaly talked about having some caching issues, trying to make the site go quickly, using probably every single WordPress caching plug-in out there, and goodness knows, there are a few of them! So, Smashing Magazine saw an improvement in performance, time to first load went from 800 milliseconds to 80 milliseconds. Again, I'm simplifying the infrastructure that served the site up in the first place. So, it's kind of interesting to see the performance gains that can happen there.

Phil Hawksworth: Another totally different type of site. This is from the Google Chrome team, who built this out to demonstrate at Google I/O this year. This very much feels like an application. This is Minesweeper in a browser. I apologize if you're watching me play this. I'm not playing it while talking to you; I recorded this sometime ago and it's agony to see how terrible I seem to be at Minesweeper while trying to record. That's not a mine, that can't be!

Phil Hawksworth: Anyway, we'll move on.

Phil Hawksworth: The point of that is, this is something that feels very much more like an app, and it was built in a way to be very responsible about the way it used JavaScript. The payload to interactive was 25KB. This progressively would download and use other resources along the way, but it meant that the time to interact was under five seconds on a very slow 3G network. So, you can be very responsible with the way you use JavaScript and still package up JavaScript, as part of the experience for a JAMstack site.

Phil Hawksworth: So, I'm kind of mindful of time. We're almost out of time, so what is the JAMstack? Well, it's kind of where we started from. JAMstack sites are rendered in advance: they're not dependent on an origin server (that's kind of key), and they may be progressively enhanced in the browser with JavaScript. But as we've shown, you don't have to use JavaScript at all. You might just be serving that statically, ready to go, without that. It's an option available to you.

Phil Hawksworth: This key tenant, I think of, JAMstack sites is they're served without web service. They're pre-rendered and done in advance.

Phil Hawksworth: If you're interested in more, it's already been mentioned a little bit, there is a conference in London in July — July 9th and 10th. The speakers are going to be talking about all kinds of things to do with performance in the browser, things that you can do in the browser, results of building on the JAMstack and things to do with serverless.

Phil Hawksworth: There's also a bunch of links in this deck that I will share, after this presentation, including various bits and pieces to do with static site generation, things like headless CMS, the jamstack.org site itself, and a great set of resources on a website called “The New Dynamic” which is just always full of latest information on JAMstack. We're out of time, so I'll wrap it up there, and then head back across to questions. So, thanks very much for joining and I'd love to take questions.

Scott: Thanks, Phil. That was amazing, thank you. You made me feel quite old when you pulled up the Minesweeper reference, so—

Phil Hawksworth: (laughs) Yeah, I can't take any credit for that, but it's kind of fascinating to see that as well.

Scott: So, I do think Vitaly is here.

Vitaly: Yes, always in the back.

Phil Hawksworth: I see Vitaly's smiling face.

Vitaly: Hello everyone!

Phil Hawksworth: So, I'm going to hand it over to Vitaly for the Q&A, because I seem to have a bit of a lag on my end, so I don't want to hold you guys up. Vitaly, I'll hand it over to you.

Scott: Okay. Thanks, Scott.

Vitaly: Thanks, Scott.

Vitaly: Hello—

Vitaly: Oh, no, I'm back. Hello everyone. Now Scott is back but Phil is gone.

Scott: I'm still here! Still waiting for everything.

Vitaly: Phil is talking. Aw, Phil, I've been missing you! I haven't seen you, for what, for days, now? It's like, “How unbelievable!” Phil, I have questions!

Vitaly: So, yeah. It's been interesting for us, actually, to move from WordPress to JAMstack — it was quite a journey. It was quite a project, and the remaining moving parts and all. So, it was actually quite an undertaking. So, I'm wondering, though, what would you say, like if we look at the state of things and if we look in the complexes, itself, that applications have. Especially if you might deal with a lot of legacy, imagine you have to deal with five platforms, maybe seven platforms here, and different things. Maybe, you have an old legacy project in Ruby, you have something lying on PHP, and it's all kind of connected, but in a hacky way. Prawidłowy? It might seem like an incredible effort to move to JAMstack. So, what would be the first step?

Scott: So … I mean, I think you're absolutely right, first of all. Re-platforming any site is a big effort, for sure. Particularly if there's lots of legacy. Now, the thing that I think is kind of interesting is an approach that I've seen getting more popular, is in identifying attributes of the site, parts of the site, that might lend themself more immediately to being pre-generated and served statically than others. You don't necessarily have to everything as a big bang. You don't have to do the entire experience in one go. So, one of the examples I shared, kind of, briefly was the Citrix documentations site.

Scott: They didn't migrate all of Citrix.com across to being JAMstack. They identified a particular part that made sense to be pre-rendered, and they built that part out. And then, what they did was they started to put routing in front of all the requests that would come into their infrastructure. So, it would say, “Okay, well, if it's in this part of the past the domain, either in the sub-domain or maybe, through to a path, route that through something which is static, then the rest of it, pass that through to the rest of the infrastructure.

Scott: And I've seen that happen, time and time again, where with some intelligent redirects, which, thankfully, is something that you can do reasonably simply on the JAMstack. You can start to put fairly expressive redirect engines in front of the site. It means that you can pass things through just that section of the site that you tried to take on as a JAMstack project. So, choosing something and focusing on that first, rather than trying to do a big bang, where you do all of the legacy and migration in one. I think that's key, because, yeah, trying to do everything at once is pretty tough.

Vitaly: It's interesting, because just, I think, two days, maybe even today, Chris Coyier wrote an article renaming JAMstack to SHAMstack where, essentially, it's all about JavaScript in which we need think about steady coasting, because JavaScript could be hosted steadily as well. And it's interesting, because he was saying exactly that. He actually — when we think about JAMstack, very often, we kind of tend to stay in camps. It's either, fully rendered and it lives a static-thing. Somewhere there, in a box and it's served from a city and that's it, or it's fully-expressive and reactive and everything you ever wanted. And actually, he was really right about a few things, like identifying some of the things that you can off-load, to aesthetic-side, generated assets, so to say, to that area.

Vitaly: And, JAMstackify, if you might, say some of the fragments of your architecture. Well, that's a new term, I'm just going to coin, right there! JAMstackify.

Phil Hawksworth: I'm going to register the domain quickly, before anybody else.

Phil Hawksworth: And it's a nice approach. I think, it kind of makes my eye twitch a little bit when I hear that Chris Coyier has been redubbing it the SHAMstack, because it makes it sound like he thinks it's a shambles. But I know that he's really talking about static-hosting and markup, which I—

Vitaly: Yes, that's right.

Phil Hawksworth: Bardzo mi się podoba, ponieważ termin JAMstack może być naprawdę mylący, ponieważ stara się obejmować tak wiele różnych rzeczy, a celem, do którego próbowałem, prawdopodobnie wielokrotnie wbijałem na tym slajdzie, jest to, że może być wszelkiego rodzaju od rzeczy. Jest tak szeroki, ale kluczem jest wstępne renderowanie i statyczne hostowanie rdzenia witryn. Bardzo łatwo jest nam wdać się w wojny religijne o to, gdzie musi to być strona React. Musi to być aplikacja React, aby być witryną JAMstack, lub aplikacja React, więc nie może być JAMstack. Ale tak naprawdę sednem tego jest to, czy używasz JavaScript, czy nie, czy wywołujesz API, czy nie, jeśli wstępnie renderujesz i przenosisz rzeczy do statycznego hosta, który może być bardzo wydajny, to jest sedno JAMstack.

Witalij: Tak, absolutnie.

Phil Hawksworth: Jesteśmy bardzo szczęśliwi, że przeglądarki stają się o wiele bardziej wydajne, a interfejsy API, które znajdują się w samych przeglądarkach, pozwalają nam również na znacznie więcej. Tak więc otwiera to drzwi jeszcze bardziej, ale nie oznacza to, że wszystko, co tworzymy jako witryna JAMstack, musi wykorzystywać wszystko. W zależności od tego, co staramy się dostarczyć, w ten sposób powinniśmy zacząć wybierać narzędzia, którymi się bawimy, aby wdrażać te rzeczy.

Witalij: Absolutnie. Mamy tu Dorana. Doranie, chyba wiem, Doranie. Mam wrażenie, że znam Dorana. Pyta: „Czy spodziewasz się, że bezserwerowy będzie zmierzał w kierunku bezproblemowej integracji z JAMstack od [niesłyszalne 00:44:36]? Co jest określane jako A w JAM.

Phil Hawksworth: To świetne pytanie, ponieważ myślę, że funkcje bezserwerowe są — po prostu tak dobrze pasują do witryn JAMstack, ponieważ pod wieloma względami, w rzeczywistości, myślę, że ktoś mnie kiedyś zapytał, czy witryny JAMstack są bezserwerowe, więc kręciłem się wokół to pytanie, bo serverless to taki obciążony termin. Ale pod wieloma względami jest to strzał w dziesiątkę, ponieważ wielokrotnie mówiłem o tym, że nie ma serwera pochodzenia. Nie musisz zarządzać infrastrukturą serwerową. Właściwie kiedyś napisałem post na blogu zatytułowany „Bez serwera sieci Web”, ponieważ świat potrzebuje innego hasła, prawda?

Phil Hawksworth: I rzeczywiście, chodziło o to, że tak, budujemy rzeczy bez serwerów. Nie chcemy zarządzać tymi serwerami, a funkcje bezserwerowe lub funkcje jako usługa idealnie do tego pasują. Tak więc w przypadkach, w których potrzebujesz interfejsu API, do którego chcesz wysłać żądanie, w rzeczywistości nie ma sensu wysyłać tego żądania bezpośrednio z przeglądarki. Na przykład, jeśli w tym żądaniu znajdują się sekrety lub klucze, możesz nie chcieć, aby te żądania — te informacje — zostały kiedykolwiek ujawnione w kliencie. Ale z pewnością możemy proxy tych rzeczy, i zazwyczaj, tradycyjnie, to, co musimy zrobić, to uruchomić serwer, mieć infrastrukturę, która skutecznie robiła niewiele więcej niż obsługa żądań, dodawanie do niego uwierzytelniania bezpieczeństwa i przekazywanie tych żądań dalej , przekazując je z powrotem.

Phil Hawksworth: Funkcje bezserwerowe są do tego idealne. Są do tego absolutnie idealne. Tak więc czasami myślę o funkcjach bezserwerowych lub funkcjach usługi, prawie jak o luku ewakuacyjnym, w którym potrzebujesz tylko trochę logiki na serwerze, ale nie chcesz tworzyć całej infrastruktury. I możesz z tym zrobić coraz więcej i powstrzymać potoki programistyczne dla przepływów pracy programistycznej, ponieważ funkcje jako usługa dojrzewają. Programiści JavaScript stają się coraz bardziej dostępni, aby móc tworzyć te rzeczy. Więc tak, naprawdę uważam, że te dwie rzeczy bardzo dobrze do siebie pasują.

Witalij: W porządku, to bardzo wyczerpująca odpowiedź. Właściwie niedawno uczestniczyłem w rozmowie, podczas której inżynier front-end z Amazon mówił o funkcjach serverless i Lambda, których używają — prawie mnie nie było. Zawsze mówił o Dockerze i Kubernetesie i wszystkich tych rzeczach, Devox World. Siedziałem tam i myślałem: „Jak on tam trafił. Nie rozumiem, co się dzieje!” Nie miałem pojęcia, co się dzieje.

Phil Hawksworth: Dokładnie, ale chodziło o to, że kiedyś… byłem… Zaakceptowałem, że nie rozumiem nic z tego świata, ale nie miałem ochoty, ponieważ dotyczyło to zupełnie innej dyscypliny . I ta dyscyplina jest nadal bardzo ważna. Wiesz, ludzie, którzy projektują infrastrukturę — ​​to wciąż jest naprawdę kluczowe. Ale teraz czuję, że czuję pokusę. Jako ktoś, kto ma doświadczenie w programowaniu front-endu, jako programista JavaScript, mam o wiele większą ochotę na zabawę w tym świecie, ponieważ narzędzia zbliżają się, jakby, bliżej mnie.

Phil Hawksworth: Jest znacznie bardziej prawdopodobne, że będę w stanie użyć niektórych z tych rzeczy i dostarczyć je w pewien sposób bezpiecznie, a nie tylko jako własny eksperyment, w którym kiedyś daplowałem. Tak więc wydaje mi się, że jako twórcy stron internetowych stajemy się coraz bardziej potężni, co jest dla mnie ekscytujące.

Witalij: Jak Power Rangers, co?

Witalij: Ale o jedno chcę cię zapytać, a właściwie o tym dyskutowaliśmy już, może tydzień temu, ale nadal chciałem to poruszyć, ponieważ jedyną rzeczą, o której wspomniałeś podczas sesji, było pojęcie posiadania niezależnej instancji każdego wdrożenia, co jest naprawdę fajne. Pytanie brzmi jednak, że jeśli masz duże zadanie, z dziesiątkami tysięcy stron, naprawdę nie chcesz ponownie wdrażać wszystkich rzeczy za każdym razem. Tak więc, zasadniczo, jeśli masz, na przykład, jeśli używasz głównie statycznej strony rzeczy. Więc mieliśmy ten pomysł od jakiegoś czasu i wiem, że jest to coś, o czym wspomniałeś ostatnio. Idea wdrożeń atomowych.

Witalij: Gdzie właściwie, dosłownie, otrzymałeś coś w rodzaju podziału między dwiema różnymi wersjami migawek konfiguracji. Jeśli więc powiesz, zmień wszędzie nagłówek, wtedy oczywiście każda strona musi zostać ponownie wdrożona. Ale jeśli zmienisz być może komponent, taki jak powiedzmy karuzela, który może mieć wpływ tylko na 1000 stron, wtedy sensowne byłoby ponowne rozmieszczenie 15000 stron. Ale tylko ten 1000. Czy możemy się tam dostać? Czy jest to magiczny pomysł, który tam jest, czy jest to coś, co jest w tym momencie całkiem namacalne?

Phil Hawksworth: Myślę, że jest to prawdopodobnie Święty Graal dla generatorów statycznych stron i tego rodzaju modelu, ponieważ z pewnością zidentyfikowałeś prawdopodobnie największą przeszkodę do pokonania. Albo największy sufit, na który wpadasz. Są to strony internetowe, które mają wiele, dziesiątki tysięcy, setki tysięcy lub miliony adresów URL — przekonanie, że kompilacja może stać się bardzo długa. Możliwość wykrycia, które adresy URL ulegną zmianie na podstawie zmiany kodu, jest wyzwaniem. Nie jest nie do pokonania, ale to duże wyzwanie. Zrozumienie, czym jest wykres zależności w całej witrynie, a następnie inteligentne wdrożenie go — to naprawdę trudne do zrobienia.

Phil Hawksworth: Ponieważ, jak wspomniałeś, zmiana komponentu może mieć bardzo daleko idące konsekwencje, ale ty — zawsze trudno jest wiedzieć, jak to zadziała. Tak więc istnieje wiele statycznych generatorów witryn, projektów, które kładą nacisk na to wyzwanie i próbują dowiedzieć się, w jaki sposób wykonują częściową regenerację i kompilacje przyrostowe. Jestem bardzo podekscytowany perspektywą rozwiązania tego dnia, ale w tej chwili jest to zdecydowanie duże wyzwanie. Możesz zacząć robić takie rzeczy, jak próba logicznego udostępnienia swojej witryny i ponownie pomyśleć o czymś podobnym do problemu z migracją. Cóż, ta sekcja, o której wiem, jest niezależna pod względem rodzaju niektórych zasobów, z których korzysta, lub rodzaju zawartości, która tam występuje, więc mogę je wdrażać indywidualnie.

Phil Hawksworth: Ale to nie jest dla mnie idealne. To naprawdę nie jest idealny scenariusz. Jednym z podejść, które trochę zbadałem, podobnie jak w przypadku weryfikacji koncepcji, jest myślenie o tym, jak robisz rzeczy, na przykład inteligentne wykorzystanie błędów 404. Tak więc, na przykład, dużym przypadkiem użycia dla bardzo dużych znaków, być może witryn z wiadomościami, jest to, że gdy potrzebują adresu URL, gdy dzieje się najświeższa historia, muszą być pierwsi, aby go tam wdrożyć. Muszą tam uzyskać adres URL. Rzeczy takie jak BBC News, zobaczysz, że wiadomości będą pojawiać się na stronie internetowej, a potem z czasem będą dodawać do nich, stopniowo, ale dotarcie tam jako pierwsze jest kluczowe. Tak więc posiadanie kompilacji, która zajmuje 10 minut, 20 minut, cokolwiek to będzie, może stanowić problem.

Phil Hawksworth: Ale jeśli są treścią, jest abstrakcyjna i być może była wywoływana z API. Wspomniałem o abstrakcyjnych systemach zarządzania treścią, takich jak Contentful, Sanity lub kilka takich. Wszystko, co ma interfejs API treści, zmienia strukturę treści, co spowoduje uruchomienie kompilacji, a my przejdziemy do uruchomienia, ale inną rzeczą, która może się zdarzyć, jest to, że jeśli opublikujesz swój adres URL w tym celu, a następnie opublikujesz ten adres URL , nawet jeśli kompilacja nie została uruchomiona, jeśli ktoś oszuka ten adres URL, jeśli pierwszym przystankiem na jego 404 zamiast powiedzenia „Nie mamy tego”, jest w rzeczywistości bezpośrednie trafienie do tego interfejsu API, wtedy możesz powiedzieć , „Cóż, kompilacja jeszcze się nie zakończyła, ale mogę to zrobić w kliencie”. Mogę przejść bezpośrednio do API, dostać to, wypełnić w kliencie.

Witalij: Hmm, ciekawe.

Phil Hawksworth: Tak więc, nawet gdy kompilacja wciąż trwa, możesz zacząć wypełniać te rzeczy. A potem, gdy kompilacja zostanie ukończona, oczywiście nie pojawi się 404. Uderzyłbyś w tę statycznie działającą stronę. Tak więc, są techniki i strategie, aby temu zaradzić, ale wciąż jest to bardzo długa, chaotyczna odpowiedź, przepraszam, ale mój wniosek jest taki, to jest wyzwanie. Trzymamy kciuki, otrzymamy lepsze strategie.

Witalij: Tak, to świetnie. Zastanawiam się więc, więc w tym momencie tak naprawdę nie myślimy nie tylko o wydajności pod względem dostarczania treści, ale o wydajności pod względem szybkości kompilacji. Jak rozmieszczenie budynków. Więc to jest również coś, nad czym się zastanawiamy, również od dłuższego czasu.

Witalij: Jeszcze jedna rzecz, o którą chciałem cię zapytać. To jest interesujące, podobnie jak ta technika, o której wspomniałeś. Jak się o tym dowiesz? Jest to po prostu coś, co ludzie zwykle publikują na własnych blogach, czy jest to jakieś medium, czy też istnieje centralne repozytorium, w którym można znaleźć coś w rodzaju studiów przypadków, o tym, jak JAMstack – jak firmy poruszały się podczas rozładowywania lub nie przeniosły się do Stos JAM.

Phil Hawksworth: Tak więc w tej chwili ten krajobraz trochę dojrzeje. Mam na myśli, że niektóre z tych przykładów, myślę, że jestem w bardzo szczęśliwej sytuacji, pracuję gdzieś w roli, którą bawię się zabawkami, wymyślam ciekawe sposoby jej wykorzystania i zaczynam eksperymentować z nimi. Tak więc te dowody koncepcji są czymś, z czym mogę eksperymentować i próbować sprostać tym wyzwaniom. Ale, jak wspomniałem wcześniej, studium przypadku, które zostało pokazane na konferencji JAMstack w Nowym Jorku, i oczywiście podczas takich wydarzeń, zaczynamy widzieć, jak mówi się o najlepszych praktykach lub praktykach branżowych i podejściach branżowych. z wydarzeń. I z pewnością chcę widzieć więcej i pracować nad większą ilością studiów przypadków, aby dostać się w miejsca takie jak Smashing Magazines, abyśmy mogli łatwiej udostępniać te informacje.

Phil Hawksworth: Myślę, że duże firmy i przestrzeń korporacyjna stopniowo wdrażają JAMstack, w różnych miejscach, na różne sposoby, ale świat wciąż jest pochylony, aby się tam dostać, więc myślę, że za każdym razem, gdy firma go przyjmuje i dzieli się swoimi doświadczenie, wszyscy możemy się z tego nauczyć. Ale naprawdę chcę, aby coraz więcej takich studiów przypadku było publikowanych, abyśmy mogli się szczególnie oprzeć na tym, jak pokonywać tego rodzaju wyzwania.

Witalij: W porządku, więc może tylko ostatnie pytanie ode mnie, ponieważ zawsze lubię czytać pytania. Tak więc, JAMstack, jeśli mógłbyś coś zmienić, może jest coś, co desperacko chciałbyś zobaczyć, poza wdrożeniami. Coś jeszcze, co by cię naprawdę uszczęśliwiło? To sprawi, że twój dzień? Co by to było? Co jest na twojej liście życzeń dla JAMstack?

Phil Hawksworth: Co za pytanie. To znaczy, gdybyśmy nie rozmawiali o kompilacjach przyrostowych, to byłoby…

Witalij: Zrobiliśmy. Już za późno. Ta karta została już przekazana. Potrzebujemy czegoś innego.

Phil Hawksworth: Więc…

Witalij: Mam na myśli, jak na platformie, jeśli spojrzysz na tylną platformę, dzieje się tak wiele ekscytujących rzeczy. Mamy Houdini, nadchodzą komponenty sieciowe i wszystko inne, ponieważ możesz zmienić cały krajobraz wszystkich właściwych komponentów. Z drugiej strony mamy cały ten magiczny, fantazyjny świat z SS NGS i oczywiście mamy też aplikacje jednostronicowe iw ogóle. Co cię najbardziej ekscytuje?

Phil Hawksworth: Będę tępy, ponieważ dzieje się tak wiele rzeczy, jest to ekscytujące i jest tak wiele nowych możliwości, z których możesz skorzystać w przeglądarce. To, co mnie naprawdę ekscytuje, to ludzie okazujący powściągliwość (śmiech) i, jak powiedziałem, nudne odpowiedzi, ale uwielbiam oglądać wspaniałe egzekucje, które są wykonywane z umiarem, w zamyśleniu — o szerszej publiczności. To naprawdę fajna i satysfakcjonująca kompilacja z nową, błyszczącą biblioteką JavaScript lub nowym interfejsem API przeglądarki, który, nie wiem, potrafi zdrapywać i podsłuchiwać w przeglądarce, czego rozpaczliwie potrzebujemy, każdego dnia.

Phil Hawksworth: Ale naprawdę lubię widzieć rzeczy, o których wiem, że zadziałają w wielu, wielu miejscach. Będą naprawdę wydajni, będą sympatyzować z istniejącymi przeglądarkami — nie tylko na biurkach dyrektorów generalnych i dyrektorów ds. technicznych, którzy mają odlotowe zabawki, ale także ludzi, którzy mają urządzenia o znacznie mniejszym poborze mocy, albo oni”. Mam trudne warunki sieciowe i tego typu rzeczy. Lubię oglądać ciekawe i bogate doświadczenia, dostarczane w sposób, który jest przyjazny dla platformy i współczujący dla szerszej publiczności, ponieważ myślę, że sieć sięga znacznie dalej niż my, programiści, którzy budują dla niej rzeczy . I ekscytuję się widząc ciekawe rzeczy zrobione w sposób, który dociera do większej liczby osób.

Phil Hawksworth: To prawdopodobnie nie jest odpowiedź, którą byłeś koniecznie-

Witalij: Och, to miłe zakończenie. Dziękuję bardzo. Nie, to jest idealne, to naprawdę jest. W porządku, czułem, że wszystko poszło dobrze! Dziękuję bardzo, że jesteś z nami! Rozdaję Scottowi!

Phil Hawksworth: Świetnie!

Witalij: Jestem tu tylko po to, żeby zagrać w pytania i odpowiedzi. Więc bardzo ci dziękuję, Phil! Nadal tu jestem, ale Scott, scena jest teraz twoja! Może podzielisz się z nami tym, co nadchodzi w Smashing TV?

Scott: Zrobię to, ale najpierw, Phil, nie mogę się doczekać, aby zobaczyć, jak działa implementacja API scratch-and-sniff. Brzmi bardzo interesująco. A Witalij, JAMstackify jest już zajęty.

Witalij: (przygnębiony) Zabrany?! Czy możemy to kupić?

Scott: Nie, istnieje!

Witalij: Cóż, za późno. Zawsze się spóźniam.

Phil Hawksworth: To na swój sposób ekscytujące.

Witalij: To historia mojego życia. Zawsze się spóźniam.

Scott: Członkowie nadchodzący jako następni, jak sądzę, w czwartek, 13, mamy mojego starego, Zacha Leathermana, który mówi o tym, o czym mówi najlepiej, czyli o czcionkach. Więc mówi o pięciu Y implementacji czcionek. A poza tym bardzo interesuje mnie ten, który pojawi się 19-go, czyli montaż wideo za pomocą JavaScript i CSS z Evą Farią. Więc bądźcie czujni na oba te elementy.

Scott: To znowu w przyszły czwartek z Zachem Leathermanem, a 19-go z Evą, która będzie opowiadać o edycji wideo w JavaScript i CSS. Więc w tej notatce, Phil, już cię nie widzę, nadal tam jesteś?

Phil Hawksworth: Jestem tutaj!

Scott: W związku z tym bardzo dziękuję wszystkim! Poza tym, czy ktoś jest w pobliżu Toronto? A może ktoś, kto kiedykolwiek chciał odwiedzić Toronto? Pod koniec czerwca zbliża się konferencja, a zostało jeszcze kilka biletów. Więc może zobaczymy tam niektórych z was.

Witalij: Dziękuję bardzo wszystkim innym!

Witalij: A tak przy okazji, jeszcze tylko jedna rzecz! Może Phil o tym wspomniał, ale w lipcu mamy również konferencję JAMstack w Londynie. Więc to też jest coś, na co należy uważać. Ale podpisuję się i idę po moją sałatkę! Nie jestem pewien, co ty…

Scott: Dobra, do widzenia, wszyscy!

Witalij: W porządku, do widzenia, wszyscy.

To jest okład!

Z całego serca dziękujemy członkom Smashing Members za ich ciągłe i życzliwe wsparcie — i nie możemy się doczekać kolejnych webinariów w przyszłości.

Ponadto Phil będzie MC MC na SmashingConf Toronto 2019 w przyszłym tygodniu i na JAMstack_conf — również chcielibyśmy cię tam zobaczyć!

Daj nam znać, jeśli uznasz tę serię wywiadów za przydatną i z kim chciałbyś przeprowadzić wywiad lub jakie tematy chciałbyś, abyśmy omówili, a my od razu zabierzemy się do tego.