Smashing Podcast Episode 25 z Anthonym Campolo: Co to jest RedwoodJS?

Mówimy o RedwoodJS. Co dokładnie oznacza bycie pełnowymiarowym frameworkiem Jamstack? Rozmawiałem z mistrzem społeczności Anthonym Campolo, aby się dowiedzieć.

Pokaż notatki

• RedwoodJS
• Antoni na Twitterze
• Seria artykułów Anthony'ego Pierwsze spojrzenie na RedwoodJS

Cotygodniowa aktualizacja

• „Wprowadzenie do programowego prowadzenia latarni morskiej”
  napisany przez Katy Bowman
• „Animowanie komponentów React za pomocą GreenSock”
  napisany przez Blessing Krofegha
• „Projektowanie z myślą o uwadze”
  napisany przez Victora Yocco
• „Zaawansowane wykorzystanie GraphQL w witrynach Gatsby”
  napisany przez Aleema Isiaka
• „Porównanie metod stylizacji w Next.js”
  napisany przez Adebiyi Adedotun

Transkrypcja

Drew McLellan: Jest uczniem Lambda School, studiuje tworzenie stron internetowych z pełnym stosem, a także jest współtwórcą RedwoodJS. Coś jako mistrz społeczności, niedawno napisał 12-częściową serię artykułów zatytułowaną Pierwsze spojrzenie na RedwoodJS, która pomaga wyjaśnić pochodzenie i motywacje Redwood, wraz z wieloma różnymi koncepcjami, które wprowadza framework. Więc wiemy, że jest ekspertem w RedwoodJS, ale czy wiesz, że nigdy nie widział psa? Moi drodzy przyjaciele, witajcie Anthony'ego Campolo.

Drew: Cześć, Anthony. Jak się masz?

Anthony Campolo: Witam. Miażdżę, bardzo dziękuję za to, że mnie masz.

Drew: Chciałem z tobą dzisiaj porozmawiać i prawdopodobnie wynika to ze wstępu, o RedwoodJS. Dla tych, którzy nie słyszeli wcześniej o RedwoodJS na wysokim poziomie, co to jest?

Anthony: Myślę, że można to opisać na kilka sposobów w zależności od tego, skąd pochodzą ludzie, ale kanoniczna definicja jest taka, że ​​jest to bezserwerowy framework z pełnym stosem dla Jamstack. Łączy więc tworzenie stron internetowych z pełnym stosem z bezserwerowymi rzeczami typu AWS Lambda i Jamstack, co w dzisiejszych czasach jest wielką rzeczą.

Drew: Czyli jest to framework typu full stack, który próbuje połączyć wiele pomysłów wokół ekosystemu programistycznego Jamstack? Czy to prawda?

Anthony: Tak, to przesuwa granice tego, czym może być aplikacja Jamstack, więc nazywając ją full stack, Jamstack, chodzi o to, jak wyjść poza tylko frontend do tego samego rodzaju paradygmatu wdrażania, który polega na popychaniu, uzyskiwaniu cały wdrożony kod. Jak to osiągnąć, ale także z naszym zapleczem i czy to wszystko jest połączone?

Drew: Teraz, zanim zagłębimy się w to zbyt głęboko, myślę, że to całkiem interesujące usłyszeć, że pochodzi z całkiem doświadczonego zespołu, prawda? Ludzie stojący za Redwoodem nie są wiosennymi kurczakami. Nie mówię, że są starzy, ale byli w pobliżu, czyż nie, jeśli chodzi o tworzenie stron internetowych?

Anthony: Są przyprawione. Tak, poświęciłem sporo czasu na pisanie o historii frameworka i pomysłach, które do niego doprowadziły, a Tom Preston-Werner jest twórcą, a więc jest również znany jako twórca Jekyll, który jest naprawdę wpływowym generatorem stron statycznych. Zrobił również TOML, język plików konfiguracyjnych. A pierwotnie był dyrektorem generalnym GitHub. Tak więc jego praca ze stronami Jekyll i GitHub i tego typu rzeczy, jak sądzę, naprawdę doprowadziły do ​​tego, co teraz uważamy za Jamstack. Wiele osób powiedziałoby: „Och, nowy Jamstack. Robią to od zawsze”. W ten sposób mówiliśmy o tym, że jest to rozszerzenie tych starszych pomysłów, statyczne generacje witryn, ale z GraphQL i bezserwerowym oraz te pomysły, jak używać kodu kleju i interfejsów API, aby Twoja aplikacja działała.

Drew: Więc to zdecydowanie od ludzi, którzy są mocno osadzeni w tej społeczności? Mam na myśli, że dyrektor generalny GitHub, naprawdę nie jesteś bardziej osadzony w społeczności open source. Redwood jest więc frameworkiem z pełnym stosem i myślę, że oznacza to, że masz kod Redwooda działający zarówno z przodu, jak i z tyłu. Czy to prawda?

Anthony: Tak, pierwszą rzeczą, którą lubię wyjaśniać ludziom, kiedy pokazuję im projekt Redwood, jest to, że jest to monorepo. Tak więc masz swój frontend i swój backend w tym samym repozytorium, a następnie każdy z nich żyje w swoich własnych folderach. Masz folder sieciowy, który jest Twoim interfejsem i jest dość podobny do tego, co można uzyskać z aplikacji Create React. Następnie masz folder API, który jest twoim zapleczem i to jest miejsce, w którym wszystkie twoje funkcje są zasadniczo umieszczane w jednym dużym module obsługi GraphQL, który jest wdrażany do AWS Lambda przez Netlify.

Drew: OK, więc zaczynając od frontu, jak wspomniałeś, jest on oparty na React. Czy to React plus trochę kodu Redwooda, czy to zwykły React? Jaka jest tam równowaga?

Anthony: To wiele rzeczy. Na pewno jest to po prostu React w tym sensie, że nie wprowadzasz wielu bibliotek zarządzania stanem, nie wprowadzasz nawet routera. Mają swój własny router, który napisali i używają wielu rzeczy z GraphQL. Tak więc, kiedy ludzie mówią o React i GraphQL i przyjaciołach, to trochę tego, co się tutaj dzieje, jest to, że daje wiele domyślnych integracji, aby React rozmawiał z twoim GraphQL. Ponieważ mamy teraz wiele konwencji dotyczących korzystania z Reacta, ale pobieranie danych nadal jest ogromnym kłopotem.

Drew: A więc jest to React skonfigurowany z kilkoma innymi narzędziami, które dobrze współpracują z Reactem, aby dać ci funkcjonujący ekosystem do wykonywania tego konkretnego stylu zadań. Czy to uczciwy opis?

Anthony: Tak, nie, tak, to świetny sposób, żeby to ująć. Tom ujął to tak, że istnieją wszystkie te najlepsze rozwiązania, które istnieją, oraz naprawdę wyrafinowane narzędzia i technologie, których możemy użyć, ale naprawdę trudno jest je wykorzystać, ponieważ masz tak ogromny koszt początkowy i musisz się ich nauczyć , musząc wymyślić, jak je zintegrować. W związku z tym umieścili slogan jako „Zrobimy dla Ciebie konfigurację pakietu internetowego”.

Drew: Myślę, że jest to powszechny problem, który słyszysz od wielu ludzi, gdy próbują rozpocząć pracę w nowoczesnym środowisku programistycznym z aplikacjami JavaScript po stronie klienta i konfiguracją pakietu internetowego, konfigurowaniem różnych rzeczy, procesów kompilacji, budować kroki. To może być całkiem pole minowe, prawda, żeby wszystko połączyć i działać? I jeszcze długa droga, zanim dojdziesz do „Witaj świecie!”. Więc Redwood daje nam to wszystko wstępnie skonfigurowane?

Anthony: Tak, to w dużej mierze pomysł na konwencję nad konfiguracją, ponieważ masz… Tom był, tak jak zbudował GitHub z Ruby on Rails i Robem, jednym z głównych współtwórców, był programistą Rails od zawsze. Mają wiele pomysłów, z którymi filozoficznie się zgadzają, jeśli chodzi o Railsy, ​​ale chcą przejąć te konwencje nad idee konfiguracyjne, idee frameworka z pełnym stosem i wdrożyć to z całą nowoczesną technologią, którą mamy teraz.

Drew: Wspomniałeś, że Redwood daje ci router lub router, jak mówimy po tej stronie stawu, czy zawiera takie elementy jak domyślne komponenty i inne tego typu rzeczy w React, czy właśnie wtedy wdrożyć to wszystko samodzielnie?

Anthony: Tak, router jest bardzo wyrafinowany. Wykonuje większość rzeczy, które można uzyskać tylko z routera React, ma po prostu różne pomysły dotyczące tego, jak powinny być zaimplementowane, ponieważ Next mają również swój własny router i nadal nie do końca wiadomo, jak my chcesz, aby nasz jednostronicowy routing aplikacji działał. Z powodu Suspense masz wiele tego rodzaju pytań o to, gdzie wejdą rzeczy asynchroniczne? W przypadku Redwooda mamy pomysł na komórkę i to jest to, co naprawdę pobiera dla Ciebie dane.

Drew: Więc może moglibyśmy się trochę zagłębić w to? Czym jest komórka z punktu widzenia Redwooda?

Anthony: Tak, więc komórka jest domyślnym sposobem pisania zapytania GraphQL, a następnie sprawia, że ​​strona zasadniczo mówi, czy otrzymujesz dane z powrotem, czy otrzymujesz z powrotem błąd, czy jesteś w stanie ładowania, albo czy… Jest jeszcze jeden stan, zapomniałem. Ale tak, więc daje ci różne stany, w których możesz się znaleźć, w zależności od tego, czy otrzymujesz swoje dane, czy nie. Jest ustawiony z Apollo pod kołdrą. Tak więc, jeśli używasz Redwood, używasz Apollo jako swojego klienta GraphQL, ale nigdy nie musisz o tym myśleć. Nigdy nie musisz pisać żadnego Apollo ani nawet o tym myśleć, wszystko jest zapieczone. Pozwala po prostu pisać zapytania GraphQL, co było naprawdę marzeniem o tym, dlaczego ludzie chcieli GraphQL, jest to, że był to naprawdę prosty język zapytań, który twórcy front-end można by użyć. Ale potem trzeba było wymyślić, jak skonfigurować serwer GraphQL, trzeba było wymyślić te wszystkie inne rzeczy i jak to wszystko okablować. Tak więc wykonuje całą integrację GraphQL za Ciebie, więc możesz po prostu napisać GraphQL, nie musisz myśleć o tym, jak zaimplementować GraphQL.

Drew: Myślę więc, że jednym z klasycznych zadań frameworka jest wzięcie całego kodu płyty kotłowej, który mógłbyś napisać sam i zaimplementowanie go dla ciebie, i uporządkowanie drogi za kulisami, aby nigdy nie patrzeć na tę płytę kotłową nigdy więcej i możesz po prostu napisać kod, który jest unikalny dla Twojej sytuacji. Domyślam się, że o to właśnie chodzi z komórką, prawda? Nie ma w tym nic rewolucyjnego, to jest coś, co można ustawić w składniku React, aby mieć te wszystkie różne stany, można podłączyć Apollo i zrobić to wszystko samemu, ale w rzeczywistości jest to dość dużo pracy i jest to powszechny wzorzec. Tak więc Redwood uporządkował ładny, wielokrotnego użytku wzór, którego możesz po prostu zacząć używać bez konieczności zastanawiania się. Czy to dobry opis?

Anthony: Tak, wymyślili nazwę, ale zdecydowanie przyznają, że była to praktyka, którą często widywali i że widzieli, jak wiele osób po prostu ją koduje, i zdecydowali, że chcą deklaratywnego sposobu pobierania danych. Dlatego właśnie masz tę konfigurację, ponieważ pozwala ona po prostu mieć różne stany i nie musisz robić logiki jeśli/to, aby dowiedzieć się, musisz to zrobić, jeśli tak się stanie. Tak więc chodzi o posiadanie jednego sposobu zadeklarowania wszystkich różnych stanów, w których mogą znajdować się Twoje dane podczas ich ładowania.

Drew: To jedna z cech charakterystycznych Reacta, prawda, że ​​React nie próbuje dać ci architektury do twojego projektu, pozwala ci zdecydować, jak zamierzasz ustrukturyzować rzeczy. To oczywiście ma plusy i minusy. Ale wygląda na to, że Redwood narzuca ci część tej struktury, abyś nie musiał o tym myśleć i aby mógł podłączyć dla ciebie kanalizację i w pewnym sensie kontynuować to, gdzie React przerwał, jeśli chodzi o dawanie ci. tego rodzaju struktury.

Anthony: Tak, i myślę, że to naprawdę interesujące, że widzieliśmy wiele różnych prób rozwiązania tego problemu, ponieważ mam na myśli ludzi, którzy od zawsze powtarzają: „Dlaczego nie ma Railsów dla JavaScript czy Railsy dla Reacta?” Jest świetny wywiad Full Stack Radio między Michaelem Chanem i Adamem Wathanem, zatytułowany React nie jest konkurentem Railsów. To jeden z różnych frameworków.

Anthony: Inni to BlitzJS, który ma niezłą ilość szumu, a Bison jest czymś w rodzaju nowego i nadchodzącego. Wszystkie mają podobny stos, ale używają różnych elementów. Będziesz mieć zapytanie React zamiast Apollo lub będziesz miał Chakrę zamiast Tailwind. Ludzie, którzy składają wszystkie te elementy w swoje stosy, wszystkie te stosy są jakby walczą, to wszystko jest bardzo przyjazna rywalizacja. Właściwie to jedna rzecz, którą naprawdę doceniam, to fakt, że właściwie wszyscy współpracujemy również między frameworkami. Nie ma tam animozji.

Drew: A więc wspomnieliśmy o Apollo i GraphQL, Redwood używa GraphQL dość mocno jako jednego z podstawowych elementów frameworka? Prawdopodobnie możemy poświęcić cały odcinek podcastu tylko dla GraphQL, ale dla tych, którzy nie są zaznajomieni, jaki kawałek robi tutaj GraphQL, jaki problem rozwiązuje w tym kontekście?

Anthony: Tak, to świetne pytanie. Kiedy mówię ludziom, co powinni wiedzieć, aby dobrze zacząć z Redwood, powiedziałbym, że powinieneś był użyć aplikacji Create React, tylko jeśli stworzyłeś aplikację Create React i wdrożyłeś ją w Netlify lub Vercel, to zapewni ci dobry początek. Następnie poznaj przynajmniej trochę GraphQL, ponieważ jest bardzo centralny. Tak więc GraphQL to sposób, w jaki Twój front end będzie komunikował się z Twoim backendem. Mówią, że jest to język zapytań dla API, chodzi o to, że ma być alternatywą dla metod API zgodnych z REST, i że zamiast robić to, co zgodne z REST, wysyłasz zapytania, które dokładnie określają hierarchiczną strukturę danych, z której chcesz otrzymać zwrot baza danych. Tak więc wymaga to trochę więcej czasu na uruchomienie, aby serwer GraphQL mógł komunikować się z tymi dwoma elementami. Następnie, gdy już to masz, programiści front-end mają możliwość uzyskania danych w znacznie bardziej elastyczny sposób. Nie potrzebujesz tych wszystkich różnych punktów końcowych API, których twoi pracownicy zaplecza muszą nadal tworzyć.

Drew: Tak więc, jeśli nastąpią zmiany w wymaganiach w interfejsie, prawdopodobnie możesz po prostu dostosować zapytanie GraphQL i nie potrzebujesz pomocy kogoś, kto pracuje na zapleczu, aby wprowadzić tę zmianę za Ciebie?

Anthony: Mam na myśli to, że prawdziwym marzeniem jest to, że możesz dorzucić do niego klienta mobilnego, aby ostatecznie stał się tak elastyczny, że możesz mieć wielu klientów, którzy komunikują się z jednym API. Twoje API GraphQL staje się Twoim źródłem prawdy, to tam cała Twoja logika jest scentralizowana. Następnie możesz zbudować wszystkie te różne warstwy widoku na górze.

Drew: Tak więc mamy tam GraphQL, który daje nam możliwość zadawania zapytań zaplecza. W Redwood, co jest zaplecza?

Anthony: Tak. Istnieje kilka różnych sposobów tworzenia swojego zaplecza. Jest sposób, w jaki wyjdziesz z pudełka z samouczkiem, który polega na korzystaniu z bazy danych Postgres wdrożonej na Heroku, super łatwe, super proste. Następnie Twoja aplikacja Redwood komunikuje się z nią z Prisma. Nie wiem, czy w ogóle znasz Prismę, ale to jak O/RM. Mówią konkretnie, że nie jest to O/RM, to konstruktor zapytań, który jest nieco niższym poziomem. Ale, aby wyjaśnić to ludziom, Prisma jest tym, co pozwala rozmawiać z bazą danych. Wykonuje migracje i konfiguruje tabele. Robi wszystkie rzeczy związane z SQL, więc nie musisz pisać SQL. Dla mnie brzmi to jak O/RM. Nie musisz jednak koniecznie używać Prismy, aby użyć Redwood.

Anthony: Właściwie zbudowałem aplikację typu „proof of concept”, w której zamiast tego użyliśmy FaunaDB. FaunaDB, mają swoje własne GraphQL API, więc możesz po prostu wysłać GraphQL API prosto do Fauna, a następnie w ten sposób wykonać mutacje w bazie danych. Tracisz wiele z funkcjonalności CLI Prismy, ale Prisma jest naprawdę wygodnym czynnikiem do łatwej pracy z relacyjną bazą danych. Ale tak naprawdę wszystko, co możesz wymyślić, możesz wymyślić, jak połączyć to z Redwoodem, dowiedziałem się tylko dlatego, że jest zbudowany wokół GraphQL i chodzi o to, aby móc rozmawiać z tymi wszystkimi różnymi elementami.

Drew: Więc Prisma jest zasadniczo rodzajem warstwy abstrakcji między twoim kodem a jakimkolwiek magazynem danych, którego używasz, prawdopodobnie wspierany przez Prisma, czy to… czy robi bardziej inteligentne rzeczy niż to?

Anthony: Tak, więc piszesz schemat, więc tworzysz plik schema.Prisma i miałby on post modelu, a następnie miałby identyfikator i liczbę całkowitą oraz auto-inkrementację, jak tytuł żądło, ciąg ciała, utworzony w dniu, o godzinie . Więc tworzysz zasadniczo to, co chcesz znaleźć w swojej bazie danych z typami, a następnie robi to za ciebie, abyś nie musiał wchodzić w interakcje z bazą danych.

Drew: Używasz Prismy do określenia, jak sądzę, do jakiego rodzaju bazy danych lub do jakiego magazynu danych się mówi. Następnie układasz swoje różne modele mvc, aby używać tego żargonu. Tak więc, kiedy twoja aplikacja komunikuje się z magazynami danych, to w pewnym sensie używa instancji klienta Prisma, prawda? Czy o to właśnie chodzi?

Anthony: Tak. Tak, dokładnie to. Tak więc w folderze API twojego zaplecza masz folder lib z db.js i domyślnie ma skonfigurowanego klienta Prisma. To wszystko, co dostajesz po wyjęciu z pudełka i jak powiedziałeś, Prisma może pracować z różnymi bazami danych. Może przełączać się między SQLite dla rozwoju, a Postgresem dla produkcji, tego typu rzeczy. W tej chwili są to głównie te relacyjne, ale mapa drogowa zawiera takie rzeczy, jak Mongo i Fauna.

Drew: Więc jest to całkiem przydatne, jeśli możesz skonfigurować i używać SQLite w lokalnym środowisku programistycznym, gdy zaczynasz działać, a następnie przejść do produkcji z czymś takim jak MySQL.

Anthony: Dokładnie tak jest skonfigurowany samouczek, to jest przepływ pracy, który ci pokazuje.

Drew: To całkiem interesujące, prawda, zobaczyć bardzo nowoczesne podejście do frameworka, a następnie skorzystać z niektórych z tych bardziej tradycyjnych baz danych, takich jak MySQL. Bardzo dobrze znam MySQL. Uwielbiam go za jego stabilność i uwielbiam relacyjny sposób przechowywania danych. Myślę, że to działa tak dobrze w wielu sprawach. Jeśli chodzi o nowsze typy przechowywania danych, często widzisz wyrzucone dziecko, które było wodą w wannie, więc interesujące jest, aby zobaczyć, jak Redwood domyślnie obsługuje te dobre, stare relacyjne bazy danych.

Anthony: Tak, nie, to dobra uwaga, ponieważ mówię, że ze wszystkich nowych rzeczy, które Redwood łączy razem, jest kilka rzeczy, które faktycznie mówią, że stary, wypróbowany i prawdziwy sposób jest w rzeczywistości najlepszy. Tak więc są naprawdę duże w relacyjnych bazach danych. Wynika to z doświadczenia Toma z używaniem Railsów i posiadaniem relacyjnego zaplecza. Active Record to warstwa O/RM, którą Prisma miała przybliżyć.

Drew: Myślę, że rozmawiamy tutaj z Redwoodem o architekturze bezserwerowej i rozmawialiśmy z Chrisem Coyierem, myślę, że dwa lub trzy odcinki temu, wszystko o bezserwerowym użyciu API, funkcji chmury i innych rzeczy. Tak więc, cofnij się o krok, jeśli miałbyś myśleć w kategoriach frameworka opartego na serwerze, jak wspomnieliśmy o Ruby on Rails lub coś takiego jak Laravel w świecie PHP. Nawet z interfejsem React, twoje żądanie API będzie uruchamiać kod, który jest kodem Rails lub kodem Laravel, a następnie kodem użytkownika i konfiguracją. Czy tak samo jest z Redwoodem? Czy istnieje rzeczywisty kod serwera Redwood, który działa, czy jest to po prostu więcej narzędzi, struktury i kleju, które umożliwiają wdrożenie własnego?

Anthony: Tak, więc na zapleczu jest plik, który jest sposobem na przejęcie twojego SDL, więc masz swój język definicji schematu, a następnie masz tak zwane twoje usługi, które są jak twoje metody komunikowania się z twoim z tyłu. Następnie wszystko to zostaje połączone w procedurę obsługi GraphQL, która jest wdrażana w pojedynczej funkcji Lambda. Jest więc zoptymalizowany specjalnie dla Lambdy. Właściwie niedawno ktoś zrobił to z frameworkiem bezserwerowym i mamy kilka osób pracujących nad Azure i Google Cloud. To nie jest funkcja Google Cloud, to ta zbudowana na dodatek. Ale tak, więc jest teraz w zasadzie zoptymalizowany pod kątem wdrażania zaplecza jako funkcji GraphQL w AWS Lambda. Nie rozumiem tego, czego cała magia dzieje się w kodzie, ale to jest wyjaśnienie na wysokim poziomie.

Drew: Są narzędzia do wdrażania, które zbierają cały napisany przez Ciebie kod, zgniatają go w coś w rodzaju magicznej kuli kodu, która może być wykonana w chmurze i umieszczana w AWS, czy ty nadal musisz sam zarządzać tym procesem?

Anthony: Tak, więc wszystko odbywa się przez Netlify, jeśli śledzisz samouczek. Naprawdę nie musisz sam grzebać w żadnych funkcjach bezserwerowych. Rzeczy, które łączą twój backend razem, aby wepchnąć go do AWS Lambda, to wszystko jest obsługiwane, nie musisz dotykać żadnego z tego kodu. To wszystko jest generowane po wyjęciu z pudełka jako twoje konwencje w twoich konfiguracjach, więc tak naprawdę nie musisz zbyt wiele myśleć o tym, jak sprawić, by było to bezserwerowe. Domyślnie jest bezserwerowy. Naprawdę trudno jest owinąć głowę. Chwilę zajęło mi owinięcie się wokół niego głową.

Drew: Tak, ponieważ to ważny punkt, nie jest tak, że mamy teraz kilka różnych obszarów, które śledzimy tutaj. Mamy chyba trzy różne obszary. Mamy nasz front-endową aplikację React, która działa w przeglądarce, a następnie mamy API oparte na GraphQL, działające jako funkcja w chmurze, które odpowiada na nasze zapytania, ale potem wchodzi w interakcję z magazynem danych który wykorzystuje Prisma. A ten magazyn danych jest tym, co i gdzie w tym, ponieważ nie możesz uruchomić serwera MySQL na Netlify, prawda?

Anthony: Tak, tutaj pojawia się Heroku. Tak więc w ostatniej części samouczka wdrażasz swój frontend w Netlify, a następnie wdrażasz swój backend w Heroku Postgres i po prostu pobierasz zmienne konfiguracyjne z Heroku, podłączasz go do Netlify. Nakłonienie frontendu Netlify do komunikacji z backendem Postgres to naprawdę prosta rzecz. Chcieli iść z tym, co będzie najłatwiejsze do rozkręcenia dla każdego, ale nadal będzie mieć dobrą stabilną, przetestowaną w boju technologię. W końcu to, co wyjdziesz z pudełka po prostu postępując zgodnie z instrukcjami, jest naprawdę niesamowite.

Drew: Entuzjaści Jamstack będą zaznajomieni z usługami takimi jak FaunaDB, o których wspomniałeś, które zapewniają magazyn danych jako API, AWS ma DynamoDB, Google ma Cloud SQL i tak dalej. Wspomniałeś, że Redwood szuka integracji, a może Prisma jest tutaj komponentem, który szuka integracji z tego rodzaju usługami w dalszej kolejności?

Anthony: Tak, to dobre pytanie. To jest coś, o czym właściwie rozmawiam z Ryanem Chenkie z Prismy, aby w pewnym sensie pomóc. Czy to jest rodzaj historii bazy danych dla Redwooda dla rzeczy, które niekoniecznie działają z Prisma? Czy nie byłoby lepiej wymyślić sposób, aby Redwood pracował z nim bezpośrednio, tak jak ja z Fauną, czy też bardziej sensowne byłoby wdrożenie sterownika dla Prismy? Tak więc można do tego podejść na różne sposoby. Oczywiście istnieje teraz milion różnych baz danych, z których każdy chce korzystać, więc motywacja jest dla Ciebie, aby umieścić na niej swój magazyn danych. Jest tam dużo datków społeczności.

Drew: A zatem, ponieważ Prisma rozumie twój model i wie, jak je odpytywać, czy jest w stanie wygenerować jakieś migracje lub tego typu rzeczy, które pomogą ci skonfigurować bazę danych?

Anthony: Dokładnie to, co tracisz, kiedy musisz wyjąć Prismę i zdobyć swoje dane, to utrata wszystkich funkcji migracji. Ma naprawdę zaawansowany interfejs CLI, który robi dla ciebie mnóstwo rzeczy, więc możesz przejść przez cały samouczek Redwood i wprowadzić polecenia Prisma i nie musisz mieć pojęcia, co robi, po prostu działa. To naprawdę świetne narzędzie do robienia wszystkich tego rodzaju rzeczy związanych z bazami danych, które chcesz mieć pewność, że masz rację i chcesz mieć pewność, że zostało to zrobione poprawnie.

Drew: Wygląda na to, że posiadanie naprawdę dobrego oprzyrządowania wokół frameworków to dość nowoczesny trend, prawda? Aby nie tylko powiedzieć: „Oto wszystkie rzeczy, które może zrobić ten framework, ale być może kilka narzędzi CLI, które zrobią dla ciebie całą masę”. Czy Redwood ma narzędzia do takich rzeczy, jak generatory CLI i inne, które pomogą Ci szybko zacząć działać?

Anthony: Jest to prawdopodobnie największa kluczowa cecha, jaką otrzymujesz od Redwooda, jest to, że dostajesz cały zestaw bardzo wyrafinowanych generatorów. Dla każdego, kto kiedykolwiek widział oryginalne demo Ruby on Rails, które DHH dało, tworzy bloga w jakieś 15 minut i robi to wszystko w Rails, a ludzie mówią: „Wow, to jest niesamowite”. To jest efekt Redwooda. Chcą, abyś był w stanie rozkręcić wszystko naprawdę szybko, dzięki czemu możesz generować strony, możesz generować układy, możesz generować komórki, o których mówiłem, i możesz wykonać polecenie rusztowania, które utworzy całą twoją Interfejs CRUD. Mam całą sekcję, część czwartą serii blogów, po prostu wyjaśniam cały kod, który daje ci rusztowanie. Daje ci tyle kodu. Jest generator wyłączony, jest nawet generator Tailwind, który konfiguruje za Ciebie tailwind.

Drew: To niesamowite. Pamiętam, jak widziałem demonstrację Railsów DHH. Chodzi mi o to, że to było prawdopodobnie co, 15 lat temu, kiedy po raz pierwszy zrobił to rusztowanie i pokazał ci, a otrzymasz dość szczątkowy, ale funkcjonalny panel sterowania zasadniczo po to, aby umożliwić ci tworzenie nowych elementów, edytowanie ich, usuwanie ich itp. . Może to być nieocenione w projekcie, zwłaszcza w dynamicznym środowisku, w którym, okej, może w przyszłości zaimplementujesz lepsze narzędzia do edycji treści, ale oznacza to, że możesz szybko coś rozkręcić. testować dane, a nawet przekazać je zespołowi ds. treści, który mógłby rozpocząć pracę podczas pracy nad interfejsem użytkownika, więc jest to naprawdę przydatne.

Drew: Jeśli chciałbyś to po prostu wdrożyć i mieć to w środowisku produkcyjnym, prawdopodobnie możesz po prostu wdrożyć to razem z kodem interfejsu użytkownika, ale potrzebujesz sposobu, aby zabezpieczyć ten aspekt, te korzenie w aplikacji.

Anthony: Tak, jest kilka różnych opcji uwierzytelniania. Możesz użyć tożsamości Netlify. Jest to ustawienie domyślne, jeśli przejdziesz do samouczka, a następnie możesz również użyć Auth0, a następnie jednego, którego nie znam, o nazwie Magic.Link, i prawdopodobnie zostanie dodanych kilka dodatkowych w przyszłości. Ale tak, więc jest tam już kilka wbudowanych rozwiązań i to jest ostatnia rzecz, którą robisz, więc to ostatnia część mojej całej 12-częściowej serii blogów to Auth. Nie sądzę, żebym kiedykolwiek odkrył Auth, zanim użyłem Redwooda. To trudne i zdecydowanie wykonali z tym dobrą robotę.

Drew: Czy to integruje się na poziomie trasy, czy na poziomie trasy, przepraszam, jak zabezpieczasz rzeczy?

Anthony: Tak, więc częścią tego, jak mają swój własny router, mają też… Możesz tworzyć trasy prywatne, więc mają komponent trasy prywatnej. Następnie, twój rzeczywisty formularz logowania, to jest to, co otrzymujesz z tożsamości Netlify, więc nie musisz tworzyć formularza i za jego pomocą zarządzać stanem, to jest miejsce, w którym pojawia się wiele problemów. Odbierając naprawdę kluczowe części, możesz po prostu wdrożyć dostęp oparty na rolach. Mamy dodatek kontroli dostępu opartej na rolach, który został zrobiony w ciągu ostatnich kilku tygodni, David T. Tak więc dzieje się dużo pracy, aby stworzyć inne sposoby na zrobienie tego, ale to, co teraz dostali, to już… to działa, to' Sprawię, że będziesz funkcjonalny.

Drew: Ludzie zawsze mówią o kryptografii haszującej algorytm bezpieczeństwa, że ​​nigdy nie powinno się pisać własnego, ponieważ nigdy nie będzie tak dobre, jak rzeczy, które tam są. Coraz częściej myślę, że dotyczy to również uwierzytelniania na wyższym poziomie; że uwierzytelnianie jest obecnie tak złożonym obszarem, że ludzie chcą nie tylko logować się do Twojej witryny za pomocą unikalnych danych uwierzytelniających, ale mogą chcieć uwierzytelniać się za pomocą Google, mogą chcieć uwierzytelniać się za pomocą urządzenia Apple lub mogą chcieć uwierzytelniać dwuetapowo lub mogą chcieć zintegrować go z usługą jednokrotnego logowania, z której korzystają w przedsiębiorstwie. Wszystkie te rzeczy przyprawiają mnie o ból głowy, jeśli spróbujesz to zaimplementować samodzielnie, i tak wiele okazji do popełnienia błędu i ujawnienia luk w zabezpieczeniach w Twojej aplikacji, że korzystanie z usługi uwierzytelniającej wydaje mi się w tym momencie prawie bezmyślne. Tak więc możliwość wrzucenia czegoś za pomocą zasadniczo kilku linijek kodu i bycie gotowym do pracy brzmi jak naprawdę produktywny sposób pracy i zabezpieczania rzeczy.

Drew: Wygląda na to, że wdrażanie zarówno aspektów front-endowych, jak i serwerowych, czyli funkcji bezserwerowych, naturalnie pasuje do wdrożenia w Netlify. Czy jesteś z tym związany z Redwoodem? Chodzi mi o to, że wspomnieliśmy, że Tom Preston-Werner jest jednym z głównych zwolenników tego frameworka, jest także członkiem zarządu Netlify. Czy uważasz, że istnieje możliwość zbyt ścisłego sprzężenia, jeśli wybierzesz Redwood jako podstawę projektu?

Anthony: Tak, to jest coś, czego Tom jest zdecydowanie świadomy. Zainwestował w wiele firm, które się krążą. Zainwestował w Prismę i Faunę. Chce po prostu tworzyć narzędzia, których chce używać. Nie chodzi o to, że chcemy cię w to zatrzasnąć, ale o to, co zbudował Netlify, uważa za najlepszą opcję, więc właśnie dlatego zbudowali wokół tego. Ale nie chcą, aby był on ograniczony do jednego celu wdrażania i dlatego pracujemy nad takimi rzeczami, jak framework bezserwerowy, a niektórzy mówili o Begin. Chcemy być pragmatyczni, chcemy, żeby działało niezależnie od czyjegoś przypadku użycia. Tak więc, otrzymujemy 90% drogi, a następnie wystarczy podłączyć kilka ostatnich rzeczy, aby działał z dowolnymi wybranymi serwerami.

Drew: Wydaje mi się, że nawet Netlify używa AWS Lambda do funkcji serwera, więc tak naprawdę jest to część wdrażania, którą zajmuje się tam Redwood, a właściwie możesz sam wdrożyć ją w Lambdzie. Publikowanie frontendu to tylko pliki, prawda? Reszta jest oparta na CDN? Tak więc jest tam całkiem duża elastyczność bez zbytniego przywiązania.

Anthony: Tak, jest właściwie termin, o którym Tom mówi jako o rdzeniu filozoficznym stojącym za Redwoodem, który mówi, że chcemy dostać się do uniwersalnej maszyny do wdrażania. To taki pomysł, że możesz po prostu wdrażać rzeczy i nie musisz w ogóle o tym myśleć. Mówił o tym pomyśle przez lata, lata i lata, io tym nawet kiedyś chodził Jekyll. Kiedy teraz to słyszysz, myślisz: „Och, masz na myśli Netlify?” Tym właśnie jest Netlify dla większości ludzi, którzy pracują na froncie. Już nawet nie myślą o rozmieszczeniu, to nawet nie jest myśl.

Drew: Oto moja aplikacja w repozytorium Git, ten katalog jest front-endem, ten katalog jest back-endem, oto moja baza danych, a to mniej więcej tyle konfiguracji, ile być może potrzebujesz do tego, aby jakakolwiek usługa mogła ją przyjąć i zbudować i hostuj go.

Anthony: Tak, i jeszcze jedną rzecz, na którą powinienem zwrócić uwagę, niedawno zainstalowaliśmy domyślną konfigurację wdrażania Vercel Redwood, więc podczas wdrażania na aplikacji po stronie serwera możesz powiedzieć: „Och, mam aplikację Gatsby” i dokładnie wie, jak zbudować aplikację Gatsby, a jak NextApp. Mamy to teraz dla Vercela. Tak więc, są naprawdę, naprawdę dobre opcje inne niż Netlify, jeśli jesteś bardziej w tym.

Drew: Więc gdybym chciał zacząć tworzyć aplikację i wprowadzić ją do produkcji w tym tygodniu, czy Redwood jest na to gotowy? Czy to dojrzałe?

Anthony: Tak, mamy około pół tuzina aplikacji, które są obecnie w produkcji. Pierwszy z nich nazywał się Predict COVID, który ukazał się w marcu i jest jak aplikacja do wizualizacji danych w czasie rzeczywistym. Następnie mamy repeater.dev zrobiony przez Roba, to jest jak praca crona, podobna do rzeczy dla Jamstack. Potem jest Tape.sh, myślę, że Duoflag to kolejny. Tak więc jest przynajmniej garstka. Jeśli przejdziesz do niesamowitego repozytorium Redwood, możesz zobaczyć listę wszystkich z nich. Jeśli wejdziesz na fora społeczności, możesz również znaleźć ich zapiski, ponieważ ludzie wprowadzili je do produkcji i powiedzieli, jak poszło. Jak dotąd wszyscy odnieśli sukces i nikt nie powiedział: „Nigdy więcej tego nie użyję”.

Drew: Ale to bardzo nowe. Myślę, że nie da się przed tym uciec, ale jeśli chodzi o dojrzałość, Redwood jest całkiem nowy, zyskuje wielu zwolenników.

Anthony: Cóż, to zabawne, jest i nie jest. Zostało to ogłoszone w marcu. W tym momencie Tom i Peter pracowali nad tym przez około rok. So, they'd already put a ton of upfront work into this, so it wasn't like I'm going to announce this project with a Read Me and then start building it. By the time they announced it, it wasn't… It's not a 1.0 now, but it's pretty dang close in terms of what people would expect out of a 1.0. But, Tom is very against what we call type driven development so he always errs on the say it's not ready. So, we say it's not ready for production even though it's in production.

Drew: I think one thing that people sometimes get burned on using frameworks is that they'll build a project around the framework and then that framework will very quickly go to another major version that had backwards incompatibilities, and they're then left with a big project to update everything onto the new version of the framework. Is that something that's likely to happen with Redwood? I mean, none of us has got a crystal ball, but just with the technologies that are involved and the way it's structured, do you think that's a big danger or a little danger?

Anthony: Yeah, it's a super valid concern and definitely something the team has thought about. The CLI has an upgrade command, so you can basically every time there's a version bump, you just do a command and it bumps you up the version. I've been dealing with this a little bit just because of the series I wrote, I started it when it was on version 11 or 0.11, it's like 0.17 or something now. So, I've been slowly iterating on it as it's gone but nothing breaks. It's all, you get slowly things, or like “Oh, this is kind of a nice little touch you've got here,” but it's pretty much set in stone architecturally. Redwood as it's structured, the front or the back end is not going to change at all. It was very well thought out in terms of what they want architecturally. That's why they built it, so they could get something that's structured like this thing.

Drew: I guess with modern web development, there is a certain point where you're just never going to get away from being reliant on dependencies updating themselves and changing. I mean, even using React, React goes through as many different changes as anything else.

Anthony: That's exactly why Tom inventing semantic versioning.

Drew: I guess from the other side of that coin, if Redwood did happen to go away, which is always something we consider when picking a framework, if development stopped somehow, I guess the impact on a particular app might not be too great because it is just so heavily built on existing other projects around. Is that-

Anthony: Well, some would say that a Redwood tree can survive a lot, it survives for a very long time. That may have been why it's called that, is that you can just make a site and deploy it and it's not going to break, it's just going to work. So yeah, maintainability, sustainability, all that kind of stuff, that's huge. Being built by people who tried to scale Rails apps, I imagine they've thought a lot about that. But in terms of the going away part, that's always going to be a danger with any open source project, so I think what you have to look for is how enthusiastic is the community to continue it without the team if that ever happens. I don't think you even need to worry about that because Tom's a billionaire and he has a venture funding thing that is funding some of the development. It is an open source project that is well funded actually. It has four full time members, Tom, Rob, David, and Peter. You just go to the forums, you can see the activity that's going on, so I wouldn't worry about that too much-

Drew: Oczywiście.

Anthony: Beyond normal open source worries that come along with that stuff.

Drew: What is the community like? You mentioned the community, are there lots of people using it and contributing to the code base or is it mainly the core team who are doing the development?

Anthony: Yeah, it's very much structured to be a community thing. They want to get as much buy in from the community as possible, and this comes from the lineage like you said. There's few people with more open source cred than Tom, so he's done a really great job of bringing people into the fold. I think just my story in general is a big win for the community because I came in, I'm a boot camp student, I'm learning all this stuff as I go. I'm not pushing code to the repo, I'm making doc fixes and writing blog articles and stuff, but they still invited me to the core contributors meeting because they saw what I was doing and they thought it was adding value. Yeah, there's really a lot of things about how they approach community building that I have a lot of respect for, and that is why I've been so invested in it and putting so much of myself into it.

Drew: Some frameworks have got this sort of natural bent for certain types of projects. For example. The Python framework, Django came out of online news publishing, and so it's a really good fit if you want to rapidly publish content like you would in a news organization. Does Redwood lean in any particular direction when it comes to the type of projects? Is it suited for content publishing or building web applications or-

Anthony: It's made to be fairly agnostic to that. It wants to be a tool that you use for a lot of stuff. First, before it was called Redwood, it was called Hammer, the idea being that you do a lot of stuff with a hammer. But, there definitely is a kind of sweet spot, which I think is the multi client type applications. So, if you know that you're starting with a web front end but you're pretty sure you're going to end up with a mobile client as well, then it's a really good fit for that because it starts you off in a way that you're going to be able to extend into having multiple clients with GraphQL, which we kind of talked about a little bit. So, I'd say that'd probably be the first thing that I would say is its sweet spot. But, it's meant to work for as many things as possible.

Drew: Does Redwood have a published roadmap of where it's going? What can we expect to be coming in the near future?

Anthony: Glad you asked. We just put out a roadmap to 1.0 less than a month ago, it was probably like two or three weeks ago. It kind of itemizes things that we're working on, things we think we're kind of close on, things we think we still have a long ways to go on. That kind of helps the community see where can I help contribute. That's one of the things we're really great about is showing here are the things that still need to be worked on. They're aiming for 1.0 by the end of the year. We'll see where we get with that, but that's the trajectory we're currently on.

Drew: One of the beauties of a Jamstack and a serverless approach I always think is that it's this idea of lots of pieces loosely joined that has served us so well in computer science up until this point. It should be really easy to scale up a Jamstack and serverless project because you can add multiple front ends or you could put more resources behind running your functions, and you can scale up a big engineering team by having people work on different small pieces. Is there a danger that adopting a framework around all of that, that you might be taking a distributed architecture and creating a tighter binding than you might otherwise have? Could Redwood become the monolith that acts as a bottleneck in your engineering efforts?

Anthony: Yeah, this is something I think about a lot because as I learned web development, I was taking… I'm in a boot camp that supposedly is full stack development, but you learn each piece in isolation. We're essentially learning the PERN stack, but you learn React, and then we learned Express. We never talked about how it actually works together. So, I do think that there is definitely a danger of not being able to comprehend in your project because of how it's all wired up. So, what I really liked about Redwood is that it just made sense. It was a mental model of how to think about my entire app and all the pieces and how they fit together in a way that really made sense to me. But, what I was surprised to find doing the Fauna project is that it's much more modular than you would think based on… You talk about it, and like you said, it sounds like it's a monolith thing, but you can rip pieces out and replace them with other pieces and they can still work. So, it's made to be a fully integrated solution, but not a solution that is tightly coupled just because this is a good way to integrate all these technologies doesn't mean you need to tightly couple them to integrate them well.

Drew: Yeah, that sounds a very promising way of structuring things, and it's going to be really exciting to see what happens with Redwood as it gets to version 1.0. Is there anything else we should know about it that we haven't talked about?

Anthony: No. I mean, I would say if you're interested, just check out the tutorial on YouTube, the RedwoodJS tutorial. They have what they call tutorial driven development, which is kind of a play on Read Me driven development, which is another thing Tom coined, that you should start with a Read Me, and then create your code to make sense with what your Read Me was. This is the idea of you create a tutorial and then you write your framework to make the tutorial work. So, that's why it's a really easy way to get spun up with it because it was made to make sense of going through the process of learning it. They've really thought about how to actually get onboarded into a massive framework with all these different pieces and all this different new tech. They progressively reveal it to you as you go. The series that I wrote is very heavily influenced by it. I essentially built the same project, but I write my own stuff as I go, and reference the docs. So, if you're interested in just learning Redwood, start with the actual tutorial and then check out my series.

Drew: So, I've been learning all about Redwood, what have you been learning about?

Anthony: Yeah, so I've been learning about CMSs, and I was actually really curious to get your thoughts on this because I imagine you've been around the block, you know a lot of CMSs. Obviously, you know you've got your WordPress's, your Drupal, but what's really interesting with something like Redwood is since you have this GraphQL stuff baked in, it has the CMS, it's just such a natural fit. So, I'm trying to figure out, what are interesting headless CMSs to check out? Which ones have GraphQL integration? Which ones have different sweet spots? If I wanted to take a CMS to build an app with RedwoodJS, what would you recommend?

Drew: That is a good question, and I'm not sure I have an immediate answer. I have looked at lots of different CMSs, not particularly with a view to GraphQL. I've not worked with GraphQL myself yet, and so that was not-

Anthony: Oh man, you've got to join the club, dude.

Drew: Yeah, no, I'm definitely getting onboard. But yes, I have a requirement at work that may be coming up to know a bit more about GraphQL, so it's certainly one of the things that I need to be learning.

Anthony: I actually learned GraphQL through Redwood. I didn't really know GraphQL, and I'd say you should know a little bit before going into it, and I had a very, very tiny basic knowledge. You can actually learn what a schema definition language is, and that GraphQL kind of jargon. You'll learn a lot and you'll pick it up as you go with Redwood.

Drew: Yeah, I should definitely get onboard and maybe doing some Redwood is the way to do it. Perhaps I need to pick up a project and start going with Redwood and see where it takes me.

Anthony: Yeah, at the very least I would say just check it out, just because it's interesting. I find it to be just a really fascinating thought experiment of how do we do modern web application development differently and more coherently.

Drew: If you, dear listener, would like to hear more from Anthony, you can find him on Twitter at ajcwebdev. His comprehensive series of articles about getting started with Redwood are on the Redwood community site, which we'll link to from the show notes. Of course, you can find all about Redwood and get started at RedwoodJS.com. Thanks for joining us today, Anthony. Czy masz jakieś pożegnalne słowa?

Anthony: Jeśli jesteś zainteresowany którąś z tych rzeczy, skontaktuj się z nami. Moje DM są zawsze otwarte. Społeczność jest ogólnie bardzo otwarta. Chętnie wyjaśnię, przeprowadzę lub skonfiguruję wszystko, co musisz wiedzieć, aby rozpocząć.