Smashing Podcast Episode 22 z Chrisem Coyierem: Co to jest Serverless?

Dzisiaj mówimy o architekturach bezserwerowych. Co to oznacza i czym różni się od tego, w jaki sposób możemy obecnie tworzyć witryny? Rozmawiałem z Chrisem Coyierem, żeby się dowiedzieć.

Pokaż notatki

• Mikrowitryna Chrisa The Power of Serverless dla programistów front-end
• Chris na Twitterze
• ShopTalk Pokaż podcast

Cotygodniowa aktualizacja

• „Konfigurowanie Redux do użytku w rzeczywistej aplikacji”
  Jerry Navi
• „Czy możesz zaprojektować stronę internetową dla pięciu zmysłów?”
  przez Suzanne Scacca
• „Tworzenie statycznego bloga z Saperem i Strapi”
  autor: Daniel Madalitso Phiri
• „Praktyczny przewodnik po prezentacjach produktów w aplikacjach React”
  przez błogosławieństwo Krofegha
• „Jak stworzyć Porsche 911 za pomocą szkicu”
  autor: Nikola Lazarević

Transkrypcja

Drew McLellan: Jest projektantem stron internetowych i programistą, którego możesz znać z CSS-Tricks, strony internetowej, którą założył ponad 10 lat temu i która pozostaje fantastycznym źródłem wiedzy dla tych, którzy tworzą strony internetowe. Jest współzałożycielem CodePen, opartego na przeglądarce internetowej placu zabaw i społeczności wykorzystywanej przez front-endowców na całym świecie do dzielenia się tym, co tworzą i znajdowania inspiracji od tych, których obserwują. Wraz z Davem Rupertem jest współgospodarzem ShopTalk Show, podcastu poświęconego tworzeniu stron internetowych. Więc wiemy, że wie dużo o tworzeniu stron internetowych, ale czy wiesz, że kiedyś wygrał konkurs w jedzeniu hot dogów, używając tylko swojego uroku? Moi miażdżący przyjaciele, proszę powitajcie Chrisa Coyiera. Witaj Chris, jak się masz?

Chris Coyier: Hej, miażdżę.

Drew: Chciałem dzisiaj z tobą porozmawiać nie o CodePen i niekoniecznie chcę rozmawiać o CSS-Tricks, które są jednym z tych niesamowitych zasobów, o których jestem pewien, że wszyscy wiedzą, że pojawiają się na samej górze Google Wyniki wyszukiwania podczas szukania odpowiedzi na dowolne pytanie dotyczące programistów internetowych. Pojawia się Twoja twarz i pojawia się przydatny post na blogu napisany przez Ciebie lub jednego z Twoich współtwórców gości.

Chris: Och, kiedyś to robiłem. Było… nie wiem, prawdopodobnie było to w czasach, gdy Google miał tę dziwną sieć społecznościową. Co to było? Google Plus?

Drew: Och, plus, tak.

Chris: Tak, gdzie powiązaliby stronę internetową z kontem Plus, więc moje konto Plus miało awatar, a awatar to ja, więc pojawiał się w wynikach wyszukiwania. Myślę, że te czasy już minęły. Myślę, że jeśli…

Drew: Tak myślę, tak-

Chris: Tak.

Drew: Ale chciałem z tobą porozmawiać o czymś, co było trochę bardziej twoim pobocznym zainteresowaniem, a to jest koncepcja architektur bezserwerowych.

Chris: Mm (tak).

Drew: To jest coś, o czym uczysz się trochę więcej od jakiegoś czasu. Czy to prawda?

Chris: Tak, tak. Jestem tylko fanem. Wydaje się, że to naturalne dopasowanie do ewolucji front-end developmentu, w którym mam wrażenie, że mam przynajmniej trochę wiedzy. Uważam się za o wiele bardziej… o wiele bardziej przydatnego na froncie niż na zapleczu, nie żebym… robię to przez te wszystkie dni. Jestem już na tyle długo, że nie boję się spojrzeć na mały kod Ruby, to na pewno. Ale wolę front-end. Studiowałem to więcej. Uczestniczyłem w projektach bardziej na tym poziomie, a potem pojawia się taki mały nowy paradygmat, który mówi: „Możesz używać swoich umiejętności JavaScript na serwerze” i jest to interesujące. Wiesz, że? Tak o tym myślę. Jest w tym o wiele więcej, ale właśnie dlatego zależy mi na tym, ponieważ czuję, że programiści front-end tak głęboko zagłębili się w JavaScript. A teraz możemy użyć tego samego zestawu umiejętności gdzie indziej. Mm, całkiem fajnie.

Drew: Wygląda na to, że otworzył się zupełnie nowy świat, podczas gdy gdybyś był tylko front-endowym koderem… Mówię, że front-endowym koderem, nie powinienem. Jeśli jesteś programistą front-end i jesteś przyzwyczajony do współpracy z kolegą lub przyjacielem, aby pomóc ci w implementacji back-endu, nagle to się otwiera. I jest to coś, czym możesz samodzielnie zarządzać większą częścią całego stosu.

Chris: Tak, tak. Otóż ​​to.

Drew: Zwracając się do słonia w pokoju, na samej górze. Mówimy o bezserwerowym i oczywiście nazywanie rzeczy jest trudne. Wszyscy to wiemy. Architektura bezserwerowa nie oznacza, że ​​nie ma serwerów, prawda?

Chris: Myślę, że jest to obowiązkowe, na przykład jeśli to jest pierwszy podcast, o którym słyszysz, lub w pierwszym… słyszysz słowo „bezserwerowy” tylko w pierwszym tuzinie razy, kiedy je słyszałeś, obowiązkowe jest, abyś mieć instynktowną reakcję i mieć coś w rodzaju: „Och, ale wciąż są kelnerzy”. W porządku. Jeśli to się teraz dzieje z tobą, po prostu wiedz o tym, jest to wymagany krok w tym kierunku. To jak wszystko inne w życiu. Są etapy do zrozumienia. Za pierwszym razem, gdy coś słyszysz, musisz to trochę odrzucić, a dopiero po kilkunastu razach, czy po tym, jak ci trochę udowodni, że jest to dla ciebie warte, możesz przejść do dalszych etapów zrozumienia tutaj. Ale słowo zwyciężyło, więc jeśli nadal walczysz ze słowem „bezserwerowy”, nie chcę ci mówić, że pociąg wyjechał tam ze stacji. Słowo już się powiodło. Nie wygrasz tego. Więc przepraszam.

Chris: Ale myślę, że to interesujące, że… zaczyna być tak, że może rzeczywiście czasami nie są zaangażowane serwery. Myślę, że jedną z rzeczy, które zamknęły w koncepcji serverless, była AWS Lambda. Byli jakby pierwszymi na scenie. Lambda jest jak funkcja, którą dajesz do AWS i umieszcza ją w magicznym niebie, a potem… ma adres URL i możesz go nacisnąć, a uruchomi tę funkcję i zwróci coś, jeśli chcesz. Wiesz, że? To tylko HTTP lub cokolwiek. Tak to działa, co… kiedy słyszysz to po raz pierwszy, myślisz: „Dlaczego? Nie obchodzi mnie to." Ale jest w tym kilka oczywistych rzeczy. Może znać moje klucze API, do których nikt inny nie ma dostępu. Właśnie dlatego uruchamiasz back-end na początku, ponieważ zna on tajne rzeczy, które nie muszą znajdować się w JavaScript po stronie klienta. Więc jeśli potrzebuje rozmawiać z bazą danych, może to zrobić. Może to zrobić bezpiecznie, bez konieczności ujawniania kluczy API w innym miejscu. Lub nawet gdzie te dane są lub jak je pobierają, to…

Chris: Więc to jest całkiem fajne. Potrafię napisać funkcję, która komunikuje się z bazą danych, pobiera dane, zwraca je. Fajny. Lambda jest taka, ale AWS działa. Musisz wybrać region. Mówisz: „Nie wiem. Gdzie to powinno być, Virginia? Oregon? Czy powinienem wybrać australijski? Nie wiem." Mają 20, 30. Nie wiem nawet, ile mają obecnie, ale nawet lambdy miały regiony. Myślę, że obecnie mają Lambda@Edge, co oznacza, że ​​są to wszystkie regiony, co jest całkiem fajne. Ale oni byli pierwsi, a teraz każdy ma coś takiego jak Lambda. Wszystkie usługi w chmurze. Chcą jakiejś służby na tym świecie. Jednym z nich jest CloudFlare. CloudFlare ma pracowników. Mają znacznie więcej lokalizacji niż AWS, ale wykonali to też w innym czasie… tak jak pracownik CloudFlare… jest to podobne do lambda, ponieważ możesz uruchomić Node. Możesz uruchomić JavaScript. Możesz uruchomić wiele innych języków, ale… Myślę o tym w dużej mierze, najbardziej interesującym językiem jest JavaScript, tylko ze względu na jego powszechność.

Chris: To się dzieje tylko na poziomie CDN, który, jak sądzę, jest serwerem, ale raczej nie myślę o CDN jako o serwerze. Nie tak oczywiste jak coś innego. Ostatnio zaczyna się czuć jeszcze bardziej bezserwerowo. Czy CDN jest serwerem? To znaczy, myślę, że to gdzieś komputer, ale wydaje się, że jest jeszcze mniej server-y.

Drew: Wydaje się, że tak, CDN może być serwerem, ale jest to najbardziej minimalna wersja serwera. To jak cienki serwer, jeśli chcesz.

Chris: Tak. Pewny.

Drew: W porządku. Słyszałem, że mówiono… Niestety nie pamiętam źródła, na które można by wierzyć, ale słyszałem, że serverless jest opisane jako „jak korzystanie z usługi współdzielenia przejazdów, takiej jak Uber lub Lyft” lub cokolwiek innego. Możesz być bez samochodu i nie posiadać samochodu, ale to nie znaczy, że nigdy nie używasz samochodu.

Chris: Tak, to nie znaczy, że samochody nie istnieją. Mm, to miłe.

Drew: Przyzywasz jeden, kiedy go potrzebujesz, ale jednocześnie nie płacisz z góry kosztów zakupu samochodu. Nie płacisz konserwacji ani paliwa lub-

Chris: Zgadza się, a ceny też mają sens, prawda? To miłe. Myślę, że to niezła analogia. A ponieważ jest również na poziomie CDN, po prostu przechwytuje żądania HTTP, które już się zdarzają, co oznacza, że ​​o to nie pytasz… nie wysyłasz do niego żądania, a on wysyła żądanie z powrotem. Dzieje się to naturalnie podczas żądania, co również sprawia, że ​​wydaje się mniej serwerowe. Nie wiem, to ciekawe. Na pewno jest to interesujące. Więc to wielka sprawa, że ​​wspomniałeś o cenie. Że płacisz tylko za to, z czego korzystasz. To też jest znaczące, ponieważ… powiedzmy, że jesteś deweloperem back-endowym, który przez całe życie rozkręcał serwery. Ponoszą koszty: „Potrzebuję tego rodzaju serwera z tego rodzaju pamięcią i takim rodzajem procesora i tego rodzaju specyfikacjami. I tyle to będzie kosztować”. Pojawia się Serverless i odcina głowę z tych cen.

Chris: Tak więc, nawet jeśli jesteś deweloperem back-endu, który po prostu nie lubi tego tak bardzo, że po prostu nie jest w tym, tak jak twój zestaw umiejętności jest taki, jaki jest przez lata, porównujesz cenę a ty mówisz: „Co? Mogę płacić 1% tego, co wcześniej płaciłem?” Nie wolno ci się tym nie przejmować, prawda? Jeśli jesteś twórcą back-endu, który płaci za swoje usługi sto razy więcej, niż musi płacić, to jesteś po prostu kiepski w swojej pracy. Przykro mi to mówić. To się pojawiło i na wiele sposobów zrujnowało ceny. Musisz się tym zająć. I fajnie, że ktoś inny jest… To nie tak, że w ogóle nie musisz się martwić o bezpieczeństwo, ale to nie jest twój serwer. Nie masz… funkcji lambda lub chmury, pracownika lub czegokolwiek innego nie znajduje się na serwerze, który znajduje się tuż obok naprawdę wrażliwych danych w Twojej sieci. Nie znajduje się tuż obok Twojej bazy danych.

Chris: Jeśli ktoś pisze kod, który w jakiś sposób próbuje wysunąć się z robota lub lambdy, czy czegokolwiek, i próbuje uzyskać dostęp do innych rzeczy na swój sposób, nie ma nic do zdobycia. Więc bezpieczeństwo to też wielka sprawa, więc znowu, jeśli to jest twoja praca jako administratora serwera, to zajmować się bezpieczeństwem tego czegoś. Uruchamiając go, uruchamiając pewne rzeczy w Lambdzie, uzyskujesz dzięki temu naturalne zabezpieczenie, co jest świetne. Więc jest o wiele taniej. Jest o wiele bezpieczniejszy. Zachęca do małej architektury modułowej, co może być dobrym pomysłem. Wydaje się, że jest to domino po dominie dobrych pomysłów. Dlatego jest godny uwagi. Wiesz, że?

Drew: Tak, mam na myśli, tradycyjnie z architekturą opartą na serwerze, którą używamy od dziesięcioleci w sieci, masz serwer sieciowy, który sam zarządzasz. Zawiera twój kod front-end, twój kod back-end, twoją bazę danych i wszystko. Następnie trzeba to utrzymać, utrzymywać w ruchu i płacić rachunki, a nawet jeśli nie jest używane, to nalicza rachunki. Użytkownik wysyłał żądanie, a on budował wszystkie te zapytania HTML z bazy danych i wysyłał je dalej do przeglądarki. Ten proces działa. W ten sposób buduje się mnóstwo rzeczy. To prawdopodobnie większość tego, jak budowana jest sieć. Tak działa WordPress. Czy to naprawdę problem, który musimy rozwiązać? To znaczy, rozmawialiśmy trochę o kosztach. Jakie są inne problemy z tym, że jesteśmy… które musimy rozwiązać, i że serverless może nam pomóc?

Chris: Tak, problemy ze starym podejściem do szkoły. Tak, nie wiem, może nie ma. To znaczy, nie mówię, że cała sieć musi zmienić całą swoją… całość z dnia na dzień. Nie wiem Może tak nie jest, ale myślę, że otwiera drzwi. Wygląda na to, że kiedy dobre pomysły pojawiają się w ten sposób, po prostu powoli zmieniają sposób działania sieci. Tak więc, jeśli istnieje jakiś CMS zbudowany w jakiś sposób, który oczekuje, że będzie tam baza danych, oznacza to, że być może gospodarze przyszłości zaczną to wykorzystywać w interesujący sposób. Może wydaje ci się, że jest to nadal tylko tradycyjny serwer, ale sami gospodarze wyhodowali go, jak działają, do architektur bezserwerowych. Więc nawet tak naprawdę nie wiesz, że tak się dzieje, ale znaleźli sposób na obniżenie kosztów, hostując potrzebne rzeczy w sposób bezserwerowy. Może tak, nie musisz się nawet przejmować jako programista, ale na poziomie meta tak właśnie się dzieje. Być może. Nie wiem

Chris: To też nie znaczy, że… Bazy danych wciąż tam są. Jeśli okaże się, że architektonicznie posiadanie relacyjnej bazy danych jest właściwym sposobem przechowywania tych danych, świetnie. Wspominam o tym, ponieważ świat Serverless dorasta w tym samym czasie, co JAMstack. A JAMstack to taka architektura, która brzmi: „Powinieneś obsługiwać swoją witrynę z hostów statycznych, które nie uruchamiają niczego poza…” Są jak małe sieci CDN. Mówią: „Nic nie mogę zrobić. Nie używam PHP. Nie prowadzę Rubiego. Nic nie biegam. Korzystam z małego, małego serwera internetowego, który jest przeznaczony tylko do obsługi plików statycznych”.

Chris: „A potem, jeśli musisz zrobić więcej, jeśli chcesz pobrać dane z relacyjnej bazy danych, zrób to w innym czasie, a nie na serwerze. Możesz to zrobić w procesie kompilacji z wyprzedzeniem i wyciągnąć te rzeczy z bazy danych, wstępnie skompilować pliki statyczne, a ja je obsłużę, lub zrobić to w czasie wykonywania”. Oznacza to, że otrzymujesz tę powłokę dokumentu, a następnie wykonuje ona żądanie JavaScript, aby uzyskać pewne dane, a następnie je wstępnie wypełnia. Więc robisz to z wyprzedzeniem lub po czasie, ale nie oznacza to: „Nie używaj relacyjnej bazy danych”. Oznacza to po prostu: „Nie pozwól, aby serwer generował go w momencie żądania dokumentu”, co jest… nie wiem, to trochę zmiana paradygmatu.

Chris: To nie tylko JAMstack. Żyjemy również w czasach frameworków JavaScript. Żyjemy w czasach, w których nieco bardziej oczekuje się, że sposób uruchamiania aplikacji JavaScript polega na tym, że montuje ona niektóre komponenty, a gdy te komponenty się montują, prosi o dane, których potrzebuje. I tak, może być naturalne, że coś takiego jak strona React wygląda tak: „No cóż, po prostu użyję funkcji bezserwerowej, aby zebrać potrzebne dane. Zasadniczo uderza w niektóre API JSON. Otrzymuję potrzebne dane JSON i konstruuję się z tych danych, a następnie renderuję na stronie”. Teraz, niezależnie od tego, czy jest to dobre, czy złe dla sieci, jest to tak: „Nie wiem. Szkoda. Statek wypłynął. W ten sposób wiele osób buduje place. To tylko rzeczy renderowane przez klienta. Tak więc bezserwerowy i nowoczesny JavaScript idą w parze.

Drew: Przypuszczam, że nie musisz hurtowo… przyglądać się takiej czy innej architekturze. Zgaduję, że pośrodku jest obszar, w którym części infrastruktury mogą być bardziej tradycyjne, a części mogą być bezserwerowe?

Chris: Tak. Cóż, i tak próbują ci to powiedzieć. Każdy, kto chce ci sprzedać jakąkolwiek część swojej architektury, mówi: „Nie musisz teraz w ogóle kupować. Po prostu zrób to trochę. Ponieważ oczywiście chcą, abyś zanurzył palec w tym, co sprzedają, ponieważ gdy zanurzysz palec u nogi, szanse, że wskoczysz do basenu, są znacznie większe. Więc myślę, że… to niekoniecznie kłamstwo, chociaż znajduję trochę mniej szczęścia w… Nie chcę, żeby mój stack był po trochu wszystkim. Myślę, że jest tam jakaś techniczna śmierć, której nie zawsze chcę przełknąć.

Drew: Mm (tak).

Chris: Ale jest to możliwe. Myślę, że najczęściej cytowany jest… powiedzmy, że mam witrynę, która ma element eCommerce, co oznacza… i powiedzmy eCommerce na dużą skalę, czyli 10 000 produktów lub coś takiego, że ta architektura JAMstack nie dotarła do punktu, w którym to zawsze jest szczególnie wydajne, aby odbudować to statycznie. Tak więc myślenie brzmi: „W takim razie nie rób tego”. Niech ta część naturalnie się uwodni dzięki… uderzeniu w funkcje bezserwerowe, zdobyciu potrzebnych danych i zrobieniu tego wszystkiego. Ale reszta witryny, która nie jest… nie ma tylu stron, nie ma tak dużo danych, można ją wstępnie renderować lub cokolwiek innego. Więc trochę obu.

Drew: Oczywiście, wiele osób ma do czynienia ze starszymi systemami, które… jakaś stara baza danych, która została zbudowana w 2000 roku, a oni mogą być w stanie umieścić coś w rodzaju warstwy API JSON na…

Chris: Tak.

Drew: … i zbuduj coś bardziej nowoczesnego i być może bezserwerowego, a następnie nadal wchodź w interakcję z tymi starszymi systemami, sklejając je w dziwny sposób.

Chris: Tak. Ale to mi się podoba, prawda? Czy… większość witryn już istnieje. Ilu z nas to całkowicie zielone strony internetowe? Większość z nas pracuje nad jakimś gównem, które już istnieje, które z jakiegoś powodu trzeba przeciągnąć w przyszłość, bo nie wiem, programiści chcą pracować szybciej, albo nie możesz już zatrudniać nikogo w COBOL, czy jakakolwiek historia jest. Wiesz, że?

Drew: Jeśli chodzi o terminologię, mówimy o JAMstack, który jest metodologią uruchamiania kodu prawie w przeglądarce, obsługującego go z CDN. Więc nie ma niczego dynamicznego na serwerze. A kiedy mówimy o bezserwerowym, mówimy o tych małych fragmentach funkcjonalności, które działają na ich serwerze gdzie indziej. Czy to prawda? Że mówiliśmy o tych funkcjach w chmurze, rodzaj-

Chris: Tak, mam na myśli, po prostu tak się składa, że ​​w tej chwili są to rodzaje gorących pomysłów. Więc dość łatwo jest rozmawiać o jednym i rozmawiać o drugim. Ale niekoniecznie muszą być razem. Możesz uruchomić witrynę JAMstack, która nie ma nic wspólnego z niczym bezserwerowym. Po prostu to robisz, po prostu wstępnie budujesz witrynę i uruchamiasz ją, a możesz używać bezserwerowego, nie przejmując się JAMstack. W rzeczywistości CodePen w ogóle nie robi JAMstack. Nie, że chcemy koniecznie rozmawiać o CodePen, ale jest to aplikacja Ruby on Rails. Działa na całej masie instancji AWS EC2 i wielu innych architekturach, aby to się stało. Ale używamy rzeczy bezserwerowych, kiedy tylko możemy, do wszystkiego, co możemy, ponieważ jest tani i bezpieczny, a także po prostu przyjemny sposób pracy. Tak więc w ogóle nie jest używany stos JAM, ale w całym miejscu nie ma serwera.

Drew: To całkiem interesujące. Jakie zadania wykonujesz bezserwerowo w CodePen?

Chris: Cóż, jest cała masa rzeczy. Jednym z nich jest, mam nadzieję, dość oczywiste, że potrzebuję… Celem CodePen jest to, że piszesz każdy kod HTML, CSS i JavaScript w przeglądarce i renderuje go przed tobą, prawda? Ale możesz również wybrać języki preprocesora. Powiedzmy, że lubisz Sassa. Włączasz Sassa w CSS i piszesz Sassa. Cóż, coś musi przetworzyć Sassa. W dzisiejszych czasach Sass jest napisany w Dart czy coś takiego.

Chris: Teoretycznie można to zrobić w kliencie. Ale te biblioteki, które wykonują wstępne przetwarzanie, są dość duże. Nie sądzę, że chcę ci wysłać całą bibliotekę Sassa, tylko po to, żeby to uruchomić. Nie chcę… po prostu nie jest, to niekoniecznie odpowiednia architektura. Może to jest dalej, to znaczy, moglibyśmy porozmawiać o bzdurach offline, bla, bla, Web Workers. Jest milion architektonicznych rzeczy, które moglibyśmy zrobić. Ale oto jak to teraz działa, czy jest lambda. Przetwarza Sassa. Ma jedną malutką, malutką, malutką, małą pracę.

Chris: Wysyłasz mu ten blob Sassa, a on odeśle ci rzeczy z powrotem, czyli przetworzony CSS, może mapę witryny, cokolwiek. Ma jedną maleńką robotę i prawdopodobnie płacimy za tę lambdę, jakieś cztery centy czy coś takiego. Ponieważ lambdy są po prostu niewiarygodnie tanie i można je też młotkować. Nie musisz się martwić o skalę. Po prostu uderzasz w tę rzecz, ile chcesz, a Twój rachunek będzie zadziwiająco tani. Są chwile, w których serverless zaczyna przekraczać granicę bycia zbyt drogim. Nie wiem co to jest, nie jestem mistrzem takich rzeczy. Ale ogólnie rzecz biorąc, każdy bezserwerowy program, który robimy, w zasadzie… prawie wszystkie liczą się jako darmowe, ponieważ są tak tanie. Ale jest jeden dla Sassa. Jest jeden za mniej. Jest jeden dla Babbel. Jest jeden dla TypeScript. Jest jeden dla… Wszystkie to indywidualne lambdy, które uruchamiamy. Oto jakiś kod, daj go lambdzie, on wraca i robimy z nim wszystko, co zamierzamy. Ale używamy go do znacznie więcej, nawet ostatnio.

Chris: Oto przykład. Każde pióro w CodePen ma zrzut ekranu. To całkiem fajne, prawda? Więc ludzie tworzą coś, a potem potrzebujemy PNG lub JPEG, albo coś w tym stylu, abyśmy mogli… w ten sposób, kiedy to tweetniesz, otrzymasz mały podgląd tego. Jeśli udostępnisz go w Slacku, otrzymasz jego mały podgląd. Używamy go w samej witrynie do renderowania… zamiast iframe, gdybyśmy mogli wykryć, że pióro nie jest animowane, ponieważ obraz iframe jest znacznie jaśniejszy, więc dlaczego nie użyć tego obrazu? I tak nie jest animowany. Po prostu zyskuje wydajność. Więc każdy z tych zrzutów ekranu ma oczywiście adres URL. Zaprojektowaliśmy go tak, aby ten adres URL był w rzeczywistości funkcją bezserwerową. To pracownik. I tak, jeśli ten adres URL zostanie trafiony, możemy naprawdę szybko sprawdzić, czy zrobiliśmy już ten zrzut ekranu, czy nie.

Chris: Jest to faktycznie włączone przez CloudFlare Workers, ponieważ CloudFlare Workers to nie tylko funkcja bezserwerowa, ale mają też magazyn danych. Mają to coś, co nazywa się magazynem klucz-wartość, więc identyfikator tego, możemy po prostu sprawdzić bardzo szybko i będzie to: „Prawda czy fałsz, masz to czy nie?” Jeśli to ma, to służy. I obsługuje go przez CloudFlare, który jest bardzo szybki na początek. A potem daje ci całą tę zdolność. Ponieważ jest to obrazowa sieć CDN, możesz powiedzieć: „Dobrze, podawaj ją w optymalnym formacie. Służcie temu jako te wymiary”. Nie muszę robić obrazu w tych wymiarach. Po prostu wstawiasz wymiary w adresie URL, a magicznie powraca on w tym rozmiarze. Więc to jest naprawdę miłe. Jeśli go nie ma, prosi inną funkcję bezserwerową, aby zrobić to naprawdę szybko. Więc zrobi to, a potem wrzuci gdzieś do wiadra… bo trzeba mieć pochodzenie obrazu, prawda? Zwykle musisz go gdzieś hostować. Więc wkładamy go do wiadra S3 naprawdę szybko, a następnie serwujemy.

Chris: Więc nie ma serwera kolejkowania, nie ma nic. To tak, jakby funkcje bezserwerowe zarządzały tworzeniem, przechowywaniem i udostępnianiem tych obrazów. I jest ich jakieś 50 lub 80 milionów czy coś takiego. To dużo, więc całkiem nieźle radzi sobie z tym jako skalą. Po prostu nawet tego nie dotykamy. To się po prostu dzieje. Wszystko dzieje się bardzo szybko. Super miły.

Drew: Myślę, że… cóż, funkcja bezserwerowa idealnie nadaje się do zadania, które wymaga bardzo małej wiedzy o stanie rzeczy. Chodzi mi o to, że wspomniałeś o zdolności CloudFlare do przechowywania par klucz-wartość, aby sprawdzić, czy masz już coś w pamięci podręcznej, czy nie.

Chris: Tak. Właśnie to próbują rozwiązać za pomocą tych. Te pary klucz-wartość to… Myślę, że tradycyjnie było to prawdą. Mówią: „Unikaj stanu rzeczy”, ponieważ po prostu nie możesz na to liczyć. A pracownicy CloudFlare mówią: „Tak, właściwie możesz do pewnego stopnia radzić sobie ze stanem”. To nie jest tak wyszukane jak… nie wiem, to są wartości kluczowe, więc jest to klucz w wartości. To nie jest zagnieżdżona, relacyjna fantazyjna rzecz. Więc prawdopodobnie istnieją pewne ograniczenia. Ale to są dni dziecka. Myślę, że te rzeczy będą ewoluować, aby stać się potężniejsze, więc masz pewną zdolność do robienia rzeczy podobnych do stanu.

Drew: A czasami ograniczenie, taka ograniczona zdolność do utrzymania stanu, albo fakt, że nie masz… nie chcesz w ogóle utrzymywać żadnego stanu, popycha cię do architektury, która daje ci tego rodzaju… Cóż, kiedy mówimy o filozofii oprogramowania „Small Pieces Loosely Joined”, prawda?

Chris: Mm (tak).

Drew: Gdzie każdy mały element robi jedną rzecz i robi to dobrze. I tak naprawdę nie wie o reszcie otaczającego go ekosystemu. I wydaje się, że naprawdę odnosi się to do koncepcji funkcji bezserwerowych. Czy sie zgadzasz?

Chris: Tak. Myślę, że można przeprowadzić filozoficzną debatę, czy to dobry pomysł, czy nie. Wiesz, że? Myślę, że niektórzy ludzie lubią ten monolit. Myślę, że jest to możliwe… są sposoby, aby przesadzić i zrobić zbyt wiele małych części, które są zbyt trudne do przetestowania. Fajnie jest mieć test typu: „Och, zastanawiam się, czy moja funkcja Sassa działa. Cóż, napiszmy na to mały test i upewnijmy się, że tak jest.” Ale powiedzmy, że dla użytkownika liczy się ciąg siedmiu z nich. Jak przetestować wszystkie siedem z nich razem? Myślę, że ta historia trochę się komplikuje. Nie wiem, jak przemawiać super inteligentnie do tych wszystkich rzeczy, ale wiem, że niekoniecznie tak jest, jeśli korzystasz ze wszystkich funkcji bezserwerowych, co automatycznie jest lepszą architekturą niż jakakolwiek inna architektura. Lubię to. Ładnie mi to rozumuje, ale nie wiem, czy to koniec wszystkich architektur. Wiesz, że?

Drew: Dla mnie jest to bardzo podobne do sieci, ponieważ… tak właśnie działa HTML, prawda? Dostarczysz trochę kodu HTML, a przeglądarka przejdzie i pobierze twoje obrazy, pobierze kod JavaScript i pobierze kod CSS. Wygląda na to, że to rozszerzenie tego -

Chris: To miłe.

Drew: … rodzaj pomysłu. Ale jedną rzeczą, jaką wiemy o sieci, jest to, że jest ona zaprojektowana tak, aby była odporna, ponieważ sieć jest delikatna.

Chris: Mm (tak).

Drew: Jak solidne jest podejście bezserwerowe? Co się stanie, jeśli coś… jeśli jeden z tych małych kawałków zniknie?

Chris: To byłoby bardzo złe. Wiesz, że? To byłaby katastrofa. Twoja witryna ulegnie awarii, tak jak każdy inny serwer, jeśli zdarzy się, że ulegnie awarii.

Drew: Czy są sposoby na złagodzenie tego, które są szczególnie -

Chris: Nie wiem.

Drew: … pasuje do tego rodzaju podejścia, z którym się spotkałeś?

Chris: Może. To znaczy, tak jak powiedziałem, naprawdę super wymyślną, solidną rzeczą może być… powiedzmy, że odwiedzasz CodePen i załóżmy, że jest implementacja JavaScript w Sass i zauważyliśmy, że jesteś w dość szybkiej sieci i że jesteś bezczynny już teraz. Może weźmiemy ten JavaScript i wrzucimy go do service workera. Następnie, jeśli wykryjemy, że lambda zawodzi, lub coś takiego, albo że masz już to zainstalowane, wtedy zamiast lambda trafimy na Service Worker i Service Workery będą mogły pracować w trybie offline. Więc to też jest miłe. To interesujące. Mam na myśli, że są w tym samym języku. Service Workery to JavaScript, a wiele funkcji Cloud to JavaScript, więc jest trochę… Myślę, że to jest możliwe, chociaż to… to tylko poważne techniczne… Po prostu przeraża mnie, że mam ten kawałek JavaScript, który dostarczyłeś do ilu tysięcy użytkowników, że niekoniecznie wiesz, co mają i jaką mają wersję. Eww, ale to tylko moje własne przerażenie. Jestem pewien, że niektórzy ludzie wykonali dobrą robotę z tego typu rzeczami.

Chris: Właściwie nie wiem. Może znasz strategie, których ja nie znam, dotyczące odporności serwera bez serwera.

Drew: Wydaje mi się, że istnieje tryb awarii, styl awarii, który może się zdarzyć w przypadku funkcji bezserwerowych, w którym uruchamiasz funkcję raz i kończy się ona niepowodzeniem, a możesz uruchomić ją po raz drugi zaraz potem i to się powiedzie, ponieważ może to uderzyć zupełnie inny serwer. Albo jaki był problem, kiedy ten przebieg może nie istnieć przy drugim żądaniu. Problemy związane z awarią całego hosta to jedno, ale może są… masz indywidualne problemy z maszyną. Masz konkretny serwer, na którym zepsuła się jego pamięć, i generuje mnóstwo błędów, a przy pierwszym uruchomieniu zakończy się niepowodzeniem. Po raz drugi problem mógł być zakorzeniony.

Chris: Firmy, które mają tendencję do oferowania tej technologii, trzeba im zaufać, ale zdarzają się też firmy, które… to jest ich duma. To jest powód, dla którego ludzie ich używają, ponieważ są niezawodne. Jestem pewien, że ludzie mogą wskazać na niektóre przestoje AWS z przeszłości, ale są one raczej rzadkie i niezbyt częste. Jeśli prowadziłeś własne bzdury, założę się, że pokonali cię z poziomu procentowego SLA. Wiesz, że? Więc to nie jest tak: „Nie buduj w elastyczny sposób”, ale generalnie firmy, które oferują takie rzeczy, są cholernie niezawodne. Szanse na to, że upadniesz, ponieważ schrzaniłeś tę funkcję, są znacznie większe niż dlatego, że ich architektura zawodzi.

Drew: Przypuszczam, że tak jak wszystko, w którym używasz API lub coś, co może się nie powieść, po prostu upewniasz się, że ustrukturyzowałeś swój kod, aby poradzić sobie z tym trybem awarii i wiedzieć, co dzieje się dalej, zamiast po prostu rzucać do błędu użytkownika, lub po prostu umiera, lub co masz. Jest tego świadomy i prosi użytkownika, aby spróbował ponownie. Albo próbować ponownie samemu, czy coś.

Chris: Tak, podoba mi się pomysł spróbowania więcej niż raz, a nie tylko: „O nie. Ponieść porażkę. Anulować." „Nie wiem, dlaczego nie spróbujesz ponownie tam, kolego?”

Drew: Mam na myśli, że jeśli chodzi o testowanie i rozwój funkcji bezserwerowych, coś w rodzaju funkcji w chmurze, czy jest to coś, co można zrobić lokalnie? Czy trzeba to robić w chmurze? Czy są sposoby na zarządzanie tym?

Chris: Myślę, że jest kilka sposobów. Nie wiem, czy historia jest równie niesamowita. To wciąż stosunkowo nowa koncepcja, więc myślę, że jest coraz lepiej. Ale z tego, co wiem, po pierwsze, piszesz całkiem normalną funkcję węzła. Zakładając, że używasz do tego JavaScript, a wiem, że w szczególności w Lambdzie obsługują one różne rzeczy. Możesz napisać cholerną funkcję PHP Cloud. Możesz napisać Funkcję Ruby Cloud. Więc wiem, że mówię konkretnie o JavaScript, ponieważ mam wrażenie, że większość z tych rzeczy to JavaScript. Nawet bez względu na język, to znaczy, możesz przejść do wiersza poleceń lokalnie i wykonać to. Niektóre z tych testów to… po prostu testujesz to tak, jak każdy inny kod. Po prostu wywołujesz funkcję lokalnie i sprawdzasz, czy działa.

Chris: To trochę inna historia, kiedy mówisz o żądaniu HTTP do niego, to jest rzecz, którą próbujesz przetestować. Czy prawidłowo odpowiada na żądanie? I czy zwraca towar prawidłowo? Nie wiem Sieć może się tam zaangażować. Więc możesz chcieć pisać testy na tym poziomie. W porządku. Nie wiem Jaka jest tam normalna historia? Rozkręcasz jakiś lokalny serwer lub coś, co mu służy. Użyj listonosza, nie wiem. Ale jest… Frameworki też próbują pomóc. Wiem, że bezserwerowa „.com”, która jest po prostu strasznie zagmatwana, ale istnieje dosłownie firma o nazwie Serverless, która tworzy ramy do pisania funkcji bezserwerowych, które pomagają je wdrażać.

Chris: Więc jeśli lubisz bezserwerową instalację NPM, dostaniesz ich framework. I jest powszechnie uważany za bardzo dobry, ponieważ jest po prostu bardzo pomocny, ale nie mają własnej chmury ani nic podobnego. Piszesz je, a to pomaga w uzyskaniu prawdziwej lambdy. Lub może współpracować z wieloma dostawcami chmury. W dzisiejszych czasach nawet nie wiem, ale ich celem jest ułatwienie historii wdrożenia. Nie wiem co… AWS nie słynie z prostoty. Wiesz, że? Istnieje cały świat narzędzi, które pomogą Ci korzystać z AWS i są jednym z nich.

Chris: Mają jakiś płatny produkt. Nawet nie wiem, co to dokładnie jest. Myślę, że jedną z rzeczy, które robią, jest… celem ich używania jest testowanie, posiadanie środowiska programistycznego, które służy do testowania funkcji bezserwerowych.

Drew: Tak, ponieważ myślę, że to całkiem duża część przepływu pracy, prawda? Jeśli napisałeś swoją funkcję JavaScript, przetestowałeś ją lokalnie, wiesz, że wykona swoje zadanie. How do you actually pick which provider it's going to go into and how do you get it onto that service? Now, I mean, that's a minefield, isn't it?

Chris: Tak. I mean, if you want to use no tooling at all, I think they have a really… like AWS, specifically, has a really rudimentary GUI for the thing. You can paste the code in there and hit save and be like, “Okay, I guess it's live now.” That's not the best dev story, but I think you could do it that way. I know CloudFlare workers have this thing called Wrangler that you install locally. You spin it up and it spins up a fake browser on the top and then dev tools below. Then you can visit the URL and it somehow intercepts that and runs your local cloud function against it. Because one of the interesting things about workers is… you know how I described how it… you don't hit a URL and then it returns stuff. It just automatically runs when you… when it intercepts the URL, like CDN style.

Chris: So, one of the things it can do is manipulate the HTML on the way through. The worker, it has access to the complete HTML document. They have a jQuery-esque thing that's like, “Look for this selector. Get the content from it. Replace it with this content. And then continue the request.” So you can mess with code on the way through it. To test that locally, you're using their little Wrangler tool thing to do that. Also, I think the way we did it was… it's also a little dangerous. The second you put it live, it's affecting all your web traffic. It's kind of a big deal. You don't want to screw up a worker. You know? You can spin up a dev worker that's at a fake subdomain, and because it's CloudFlare, you can… CloudFlare can just make a subdomain anyway. Nie wiem It's just kind of a nice way to do a… as you're only affecting sub-domain traffic, not your main traffic yet. But the subdomain's just a mirror of a production anyway, so that's kind of a… that's a testing story there.

Chris: It brings up an interesting thing, though, to me. It's like… imagine you have two websites. One of them is… for us it's like a Ruby on Rails app. Whatever. It's a thing. But we don't have a CMS for that. That's just like… it's not a CMS, really. I think there's probably Ruby CMSs, but there's not any renowned ones. You know? It seems like all the good CMSs are PHP, for some reason. So, you want a quality CMS. Drew, you've lived in the CMS market for a long time -

Drew: Absolutely.

Chris: … so you know how this goes. Let's say you want to manage your sites in Perch or whatever, because it's a good CMS and that's the proper thing to use to build the kind of pages you want to build. But you don't want to run them on the same server. Unless you want to manage the pages on one site, but show them on another site. Well, I don't know, there's any number of ways to do that. But one JavaScript way could be, “Okay, load the page. There's an empty div there. Run some JavaScript. Ask the other site for the content of that page and then plunk it out on the new page.” That's fine, I guess, but now you're in a client side rendered page. It's going to be slow. It's going to have bad SEO, because… Google will see it eventually, but it takes 10 days or something. It's just a bad story for SEO. It's not very resilient, because who knows what's going to happen in the network. It's not the greatest way to do this kind of “content elsewhere, content on site B, show page of site A”, situation.

Chris: You could also do it on the server side, though. Let's say you had… Ruby is capable of granting a network request too, but that's even scarier because then if something fails on the network, the whole page could die or something. It's like a nervous thing. I don't love doing that either. But we did this just recently with a worker, in that we… because the worker's JavaScript, it can make a fetch request. So, it fetches site A, it finds this div on the page, and then it goes and asks site B for the content. Gets the content. Plugs it into that div, and serves the page before it gets anything. So it looks like a server rendered page, but it wasn't. It all happened at the… on the edge, at the worker level, at the serverless level.

Chris: So it's kind of cool. I think you can imagine a fetch request on the browser probably takes, I don't know, a second and a half or something. It probably takes a minute to do it. But because these are… site B is hosted on some nice hosting and Cloudflare has some… who knows what kind of super computers they use to do it. They do. Those are just two servers talking to each other, and that fetch request happens just so super duper, duper fast. It's not limited to the internet connection speed of the user, so that little request takes like two milliseconds to get that data. So it's kind of this cool way to stitch together a site from multiple sources and have it feel like, and behave like, a server rendered page. I think there's a cool future to that.

Drew: Are there any sort of conventions that are sort of springing up around serverless stuff. I'm sort of thinking about how to architect things. Say I've got something where I want to do two sort of requests to different APIs. I want to take in a postal address and geocode it against one, and then take those coordinates and send that to a florist who's going to flower bomb my front yard or something. How would you build that? Would you do two separate things? Or would you turn that into one function and just make the request once from the browser?

Chris: Mm (affirmative). That's a fascinating question. I'd probably have an architect function or something. One function would be the one that's in charge of orchestrating the rest of them. It doesn't have to be, your website is the hub and it only communicates to this array of single sources. Serverless functions can talk to other serverless functions. So I think that's somewhat common to have kind of an orchestrator function that makes the different calls and stitches them together, and returns them as one. I think that is probably smart and faster, because you want servers talking to servers, not the client talking to a whole bunch of servers. If it can make one request and get everything that it needs, I think that's probably generally a good idea-

Drew: Yeah, that sounds smart. Tak.

Chris: But I think that's the ultimate thing. You get a bunch of server nerds talking, they'll talk about the different approaches to that exact idea in 10 different ways.

Drew: Tak. No, that sounds pretty smart. I mean, you mentioned as well that this approach is ideal if you're using APIs where you've got secret information. You've got API keys or something that you don't want to live in the client. Because I don't know, maybe this florist API charges you $100 dollars every time flower bomb someone.

Chris: Easily.

Drew: You can basically use those functions to almost proxy the request and add in the secret information as it goes, and keep it secret. That's a viable way to work?

Chris: Yeah, yeah. I think so. I mean, secrets are, I don't know, they're interesting. They're a form of buy in I think to whatever provider you go with, because… I think largely because of source control. It's kind of like, you could just put your API key right in the serverless function, because it's just going to a server, right? You don't even have to abstract it, really. The client will never see that code that executes, but in order for it to get there, there's probably a source control along the way. It's probably like you commit to master, and then master… then some kind of deployment happens that makes that thing go to the serverless function. Then you can't put your API key in there, because then it's in the repo, and you don't put your API keys in repos. That's good advice. Now there's stuff. We've just done… at CodePen recently, we started using this git-crypt thing, which is an interesting way to put keys safely into your repos, because it's encrypted by the time anybody's looking at that file.

Chris: But only locally they're decrypted, so they're useful. So it's just kind of an interesting idea. I don't know if that helps in this case, but usually, cloud providers of these things have a web interface that's, “Put your API keys here, and we'll make them available at runtime of that function.” Then it kind of locks… it doesn't lock you in forever but it kind of is… it's not as easy to move, because all your keys are… you put in some input field and some admin interface somewhere.

Drew: Yeah, I think that's the way that Netlify manage it.

Chris: They all do, you know?

Drew: Tak. You have the secret environment variables that you can set from the web interface. That seems to work quite nicely.

Chris: Yeah, right. But then you got to leave… I don't know, it's not that big of a deal. I'm not saying they're doing anything nefarious or anything. How do you deal with those secrets? Well, it's a hard problem. So they kind of booted it to, I don't know, “Just put them in this input field and we'll take care of it for you, don't worry about it.”

Drew: Is there anything that you've seen that stands out as an obvious case for things that you can do with serverless, that you just couldn't do with a traditional kind of serverfull approach? Or is it just taking that code and sort of almost deploying it in a different way?

Chris: It's probably mostly that. I don't know that it unlocks any possibility that you just absolutely couldn't run it any other way. Yeah, I think that's a fair answer, but it does kind of commoditize it in an interesting way. Like, if somebody writes a really nice serverless function… I don't know that this exists quite yet, but there could kind of a marketplace, almost, for these functions. Like, I want a really good serverless function that can take a screenshot. That could be an open source project that lots of eyeballs around, that does a tremendously good job of doing it and solves all these weird edge cases. That's the one I want to use. I think that's kind of cool. You know? That you can kind of benefit from other people's experience in that way. I think that will happen more and more.

Drew: I guess it's the benefit that we talked about, right at the top, of enabling people who write JavaScript and may have written JavaScript only for the front-end, to expand and use those skills on the back-end as well.

Chris: Tak, tak. Myślę, że tak, myślę, że to jest… ponieważ zdarzają się takie momenty, jak… nie trzeba mieć ogromnych umiejętności, aby wiedzieć, co jest odpowiednie, a co nie dla strony internetowej. Na przykład, zrobiłem mały samouczek w zeszłym tygodniu, gdzie był ten błąd, używa ich… kiedy oszczędzasz usterkę, dają ci ślimaka za twoją rzecz, którą zbudowałeś, to jest: „Whisky, tango, fokstrot. 1000”. To jak sprytna mała rzecz. Szanse na to, że będzie wyjątkowy, są bardzo wysokie, ponieważ myślę, że nawet dodają do niego liczbę lub coś takiego. Ale w końcu są tymi zabawnymi drobiazgami. Otwierają swoją bibliotekę, która zawiera wszystkie te słowa, ale to jest jak sto tysięcy słów. Plik jest ogromny. Wiesz, że? To tylko megabajty słownika słów. Prawdopodobnie w pierwszym roku programowania nauczyłeś się: „Nie wysyłaj pliku JavaScript, który ma megabajty słownika”. Wysyłanie tego nie jest dobre. Wiesz, że? Ale Node to nie obchodzi. Możesz wysłać ich setki. Nie ma to znaczenia dla szybkości serwera.

Drew: Tak.

Chris: To nie ma znaczenia na serwerze. Więc mógłbym powiedzieć: „Hmm, cóż, wtedy zrobię to po prostu w Node”. Będę miał stwierdzenie, które mówi: „Słowa równe wymagają słów” lub cokolwiek, a na górze notatkę: „Niech to będzie losowo liczba. Wyciągnij go z tablicy i zwróć. Tak więc ta funkcja bezserwerowa to osiem wierszy kodu z pakietem@JSON, który pobiera tę bibliotekę open source. A potem mój kod front-endowy, jest adres URL do funkcji bezserwerowej. Trafia na ten adres URL. Adres URL zwraca jedno słowo lub grupę słów lub cokolwiek innego. Budujesz do tego swój własny mały interfejs API. A teraz mam naprawdę fajną, wydajną rzecz. Co było w tym miłe, to takie proste. Nie martwię się o bezpieczeństwo tego. Ja nie… wiesz?

Chris: Myślę, że po prostu… bardzo przeciętny lub początkujący programista JavaScript może to zrobić, co jest fajne. To jest możliwość, której wcześniej nie mieli. Wcześniej mówili: „Cóż, oto tablica słów o wielkości 2 MB”. „Och, nie mogę tego wysłać do klienta”. – Och, wtedy po prostu się wyłączysz. Możesz uderzyć w tę ścianę w stylu: „Po prostu nie mogę wtedy wykonać tej części. Muszę poprosić kogoś innego, żeby mi w tym pomógł, albo po prostu tego nie robił, albo zbierał więcej nudnych ślimaków czy coś…”. Po prostu musisz iść inną drogą, która jest dla ciebie ścianą, ponieważ nie mogłeś tego zrobić. A teraz mówisz: „No cóż, po prostu…” Zamiast umieszczać to w moim ukośniku skryptu lub w folderze źródłowych skryptów ukośnika, umieszczę to w folderze funkcji.

Chris: Tak jakby przeniosłeś skrypt z jednego folderu do drugiego. I tak się składa, że ​​zamiast tego zostanie wdrożony jako funkcja bezserwerowa. Jakie to jest świetne? Wiesz, że? Używasz prawie tego samego zestawu umiejętności. Wciąż jest w nim kilka ostrych krawędzi, ale jest całkiem blisko.

Drew: Jest super. Utworzyłeś coś w rodzaju małej mikro-strony poświęconej tym pomysłom, prawda?

Chris: Tak. Byłem trochę za wcześnie w grze. Jednak po prostu dzisiaj nad tym pracowałem, ponieważ… dostaje pull requesty. Pomysł… cóż, jest na serverless.css-tricks.com i… nawiasem mówiąc, jest myślnik w CSS-Tricks. Jest to więc subdomena CSS-Tricks, którą też zbudowałem bezserwerowo, więc to jest… CSS-Tricks jest jak witryna WordPress, ale to jest statyczna witryna generatora witryn. Cała jego zawartość znajduje się w repozytorium GitHub, które jest open-source. Więc jeśli chcesz zmienić zawartość witryny, możesz po prostu przesłać prośbę o ankietę, co jest miłe, ponieważ z biegiem czasu było ich około setki. Ale zbudowałem całą oryginalną zawartość.

Drew: To bardzo przydatne miejsce, ponieważ zawiera listę… Jeśli myślisz: „Tak, chcę zacząć od funkcji bezserwerowych”, zawiera listę wszystkich dostawców, których możesz wypróbować i…

Chris: To wszystko, w zasadzie, to listy technologii. Tak.

Drew: Co jest świetne, bo w przeciwnym razie po prostu googlujesz i nie wiesz, co znajdujesz. Tak, to listy dostawców API, które pomagają robić tego typu rzeczy.

Chris: Formularze są jednym z przykładów, ponieważ… więc w chwili, w której zdecydujesz się… powiedzmy, że pójdziesz na JAMstack, co wiem, że niekoniecznie o to chodzi, ale widzisz, jak one są ze sobą w parze . Nagle nie masz pliku PHP lub czegokolwiek do przetworzenia tego formularza. Jak wypełniasz formularze na stronie JAMstack? Cóż, można to zrobić na wiele sposobów. Najwyraźniej wszyscy i ich siostra chcą pomóc ci rozwiązać ten problem. Myślę więc, że gdybym był wynalazcą słowa JAMstack, starają się ci pomóc w naturalny sposób, ale nie musisz ich używać.

Chris: Właściwie byłem bardzo zaskoczony, tworząc tę ​​stronę. Zobaczmy. Istnieje sześć, dziewięć, dwanaście, piętnaście, osiemnaście, dwadzieścia jeden, dwadzieścia dwa serwisy, które chcą pomóc ci teraz bezserwerowo przetwarzać twoje formularze na tej stronie. Jeśli chcesz być 23., to zapraszamy, ale masz konkurencję. Ideą, która się za tym kryje, jest to, że piszesz formularz w HTML, jak dosłownie element formularza. A następnie atrybut akcji formularza, nie może on nigdzie wskazywać wewnętrznie, ponieważ nie ma na co wskazywać. Nie możesz przetwarzać, więc wskazuje na zewnątrz. Wskazuje na to, na co chcą, abyś go wskazał. Przetwarzają formularz, a następnie robią rzeczy, których się od nich oczekuje, na przykład wysyłanie powiadomień e-mail. Lub wyślij coś na Slack. Lub wyślij go do Zapiera, a Zapier wyśle ​​go gdzie indziej. Wszystkie mają nieco inne zestawy funkcji, ceny i inne rzeczy, ale wszystkie próbują rozwiązać ten problem za Ciebie, na przykład: „Nie chcesz przetwarzać własnych formularzy? Nie ma problemu. Przetworzymy to dla ciebie.”

Drew: Tak, to bardzo przydatne źródło. Naprawdę polecam wszystkim to sprawdzić. To serverless.css-tricks.com. Więc nauczyłem się wszystkiego o bezserwerowym. O czym się ostatnio dowiedziałeś, Chris?

Chris: No cóż, nadal jestem bardzo na tym świecie i uczę się o rzeczach bezserwerowych. Wpadłem na pomysł, żeby… Grałem w tę internetową grę RPG wieki temu. Niedawno odkryłem, że wciąż żyje. Jest to oparta na tekście średniowieczna gra fantasy. Grałem w to, gdy AOL był czymś, ponieważ AOL chciał mieć te gry, w które trzeba było być zalogowanym, aby w nie grać, ponieważ chcieli, abyś spędzał wiele godzin na AOL, aby mogli wysyłać ci te ogromne rachunki, , jestem pewien, dlaczego w pewnym momencie tak dobrze im poszło.

Drew: Więc rozliczanie co do sekundy. Tak.

Chris: Tak. Więc gry były dla nich wielkie. Jeśli mogliby nakłonić cię do grania w gry z innymi ludźmi. Więc ta gra… nie zadebiutowała tam, ale przeniosła się do AOL, ponieważ jestem pewien, że dostali na nią soczystą umowę, ale tak było… to znaczy, po prostu nie może być bardziej nerdi. Jesteś krasnoludzkim magiem i otrzymujesz runiczny kostur ze swojej skórzanej pochwy. I wpisujesz do niego polecenia jak terminal. Wtedy gra ci odpowie. Grałem w tę grę bardzo długo. Bardzo mi się to podobało. Wszedłem w społeczność i ducha tego. To było trochę… to było tak, jakbym była sama przy komputerze, ale mimo to patrzę wstecz na ten czas w moim życiu i mówię: „To był wspaniały czas w moim życiu”. Naprawdę… po prostu lubiłem ludzi, grę i tak dalej. Ale potem dorosłem i przestałem w to grać, ponieważ życie ci się przytrafia.

Chris: Dopiero niedawno się dowiedziałem, bo ktoś znowu zaczął robić podcast na ten temat… Nie wiem, jak się na to natknąłem, ale właśnie się udało. Pomyślałem: „Ta gra jest żywa i ma się dobrze w dzisiejszym świecie, żartujesz sobie? Ta rzecz oparta na tekście. Byłem bardziej niż szczęśliwy z reaktywacji, odzyskania moich starych postaci i zagrania tego. Ale tylko po to, by dowiedzieć się, że klienci, których pobrali do tej gry, wcale się nie rozwinęli. Są okropne. Prawie zakładają, że używasz systemu Windows. Są tylko te okropnie tandetne, słabo renderowane… i jest oparte na tekście, myślisz, że ma przynajmniej ładną typografię. Nie. Więc mówię: „Mogę się zaangażować. Mógłbym napisać klienta do tej gry. Umieść w nim piękną typografię.” Po prostu zmodernizuj tę rzecz i myślę, że gracze w grze to docenią, ale wydawało mi się to przytłaczające. "Jak mogę to zrobić?" Ale znajduję kilka projektów open source. Jednym z nich jest… możesz grać w grę przez rzeczywiste okno terminala i używa bibliotek open source do tworzenia GUI z okna terminala.

Drew: Naprawdę?

Chris: Nie wiem. Więc to było całkiem fajne. Pomyślałem: „Jeśli to napisali, musi być tam kod, jak połączyć się z grą i uruchomić to wszystko i tak dalej. Więc przynajmniej mam kod startowy. Próbowałem podążać za aplikacją: „Może zrobię to we Flutterze lub czymś”, więc aplikacja produktu końcowego będzie działać na telefonach komórkowych i „Naprawdę mógłbym to zmodernizować”. Ale potem zostałem przytłoczony. Pomyślałem: „Ach, to jest za duże… nie mogę. Jestem zajęty." Ale znalazłem inną osobę, która miała ten sam pomysł i była o wiele dalej z nim, więc mogłem po prostu wnieść swój wkład na poziomie projektowania. Praca nad tym była naprawdę fajna, ale też dużo się nauczyłem, ponieważ rzadko zdarza mi się wskoczyć do projektu, który jest cudzym dzieckiem, a ja tylko trochę się do tego przyczyniam, a to ma zupełnie inne znaczenie. wyborów technologicznych niż kiedykolwiek bym wybrał.

Chris: To aplikacja Electron. Wybrali to, co również jest fajną drogą, ponieważ są to moje umiejętności internetowe… więc nie uczę się niczego zbyt dziwnego i jest to wieloplatformowe, co jest świetne. Więc dużo się nauczyłem o Electronie. Myślę, że to zabawne.

Drew: To fascynujące. To zawsze niesamowite, jak małe projekty poboczne i rzeczy, które robimy dla zabawy, stają się miejscem, w którym czasami uczymy się najwięcej. I naucz się umiejętności, które następnie mogą zostać wykorzystane w naszej codziennej pracy.

Chris: Tylko w ten sposób się czegoś uczę. Zostałem wciągnięty w coś, co… Pomyślałem: „Oni nie są…” Jest renderowany za pomocą biblioteki JavaScript o nazwie Mithril, która jest… Nie wiem, czy kiedykolwiek o tym słyszałeś, ale to dziwne. To nie jest… to prawie jak pisanie Reacta bez JSX. Trzeba „stworzyć element” i zrobić to wszystko… ale to ma być o wiele lepszym benchmarkiem niż to… I to właściwie ma znaczenie, bo w tej grze tekstowej tekst po prostu leci. Istnieje wiele manipulacji danymi, które są jak… można by pomyśleć, że ta gra tekstowa byłaby tak łatwa do uruchomienia w oknie przeglądarki, ale w rzeczywistości tak nie jest. Dzieje się tak wiele manipulacji danymi, że naprawdę musisz być naprawdę… musimy być sumienni w szybkości renderowania. Wiesz, że?

Drew: To fascynujące-

Chris: Całkiem fajnie.

Drew: Tak. Jeśli, drogi słuchaczu, chciałbyś usłyszeć więcej od Chrisa, możesz go znaleźć na Twitterze, gdzie jest @chriscoyier. Oczywiście CSS-Tricks można znaleźć na stronie css-tricks.com i CodePen na codepen.io. Ale przede wszystkim polecam subskrybowanie podcastu ShopTalk Show, jeśli jeszcze tego nie zrobiłeś, na shoptalkshow.com. Dzięki za przybycie do nas dzisiaj, Chris. Czy masz jakieś pożegnalne słowa?

Chris: Smashingpodcast.com. Mam nadzieję, że to prawdziwy adres URL.