アンソニーカンポロとポッドキャストエピソード25を壊す：RedwoodJSとは何ですか？

公開: 2022-03-10

簡単な要約↬RedwoodJSについて話しています。フルスタックのJamstackフレームワークとはどういう意味ですか？ドリュー・マクレランがコミュニティチャンピオンのアンソニー・カンポロと話をして調べます。

RedwoodJSについて話しています。フルスタックのJamstackフレームワークとはどういう意味ですか？コミュニティチャンピオンのAnthonyCampoloに話を聞いて調べました。

メモを表示

RedwoodJS
Twitterのアンソニー
アンソニーの記事シリーズRedwoodJSの初見

毎週の更新

「プログラムによる灯台の実行の概要」
ケイティボウマンによって書かれました
「GreenSockを使用したReactコンポーネントのアニメーション化」
BlessingKrofeghaによって書かれました
「注意を引くための設計」
ビクターヨッコによって書かれました
「GatsbyWebサイトでの高度なGraphQLの使用法」
AleemIsiakaによって書かれました
「Next.jsでのスタイリング方法の比較」
AdebiyiAdedotunによって書かれました

トランスクリプト

アンソニー・カンポロの写真 Drew McLellan：彼はLambda Schoolの学生であり、フルスタックWeb開発を研究しているだけでなく、RedwoodJSの寄稿者でもあります。コミュニティチャンピオンのようなもので、彼は最近、フレームワークが導入するさまざまな概念の多くとともに、Redwoodの起源と動機を説明するのに役立つA First Look atRedwoodJSと呼ばれる12部構成の記事シリーズを書いています。それで、彼がRedwoodJSの専門家であることは知っていますが、彼が犬を見たことがないことを知っていましたか？私の壊滅的な友人、アンソニー・カンポロを歓迎してください。

ドリュー：こんにちは、アンソニー。元気ですか？

アンソニー・カンポロ：こんにちは。私は壊している、私を持ってくれて本当にありがとう。

ドリュー：今日はお話ししたかったのですが、RedwoodJSについての紹介からおそらく明らかです。 RedwoodJSのことを聞いたことがない人にとって、大まかに言えば、それは何ですか？

Anthony：人々がどこから来ているかに応じて、いくつかの方法で説明できると思いますが、標準的な定義は、Jamstackのフルスタックサーバーレスフレームワークです。そのため、フルスタックWeb開発と、サーバーレスAWS LambdaタイプのものおよびJamstackを組み合わせています。これは、最近では大きな問題です。

Drew：では、Jamstack開発エコシステムに関する多くのアイデアをまとめようとするフルスタックフレームワークですか？そうですか？

アンソニー：ええ、それはJamstackアプリケーションの可能性の限界を押し広げているので、それをフルスタック、Jamstackと呼ぶことで、フロントエンドだけでなく、プッシュされて取得するのと同じ種類のデプロイメントパラダイムを実現する方法についてです。コード全体がデプロイされました。どうすればそれを取得できますが、バックエンドでもすべてを接続できますか？

ドリュー：さて、深く掘り下げる前に、それがかなりベテランのチームからのものであると聞くのは非常に興味深いと思いますね。レッドウッドの背後にいる人々、彼らは春の鶏ではありません。彼らは古いとは言えませんが、Web開発の観点からは、彼らはブロックの周りにいますね。

アンソニー：彼らはベテランです。はい、私は実際にフレームワークの歴史とそれにつながったアイデアについて書くのにかなりの時間を費やしました、そしてトム・プレストン・ウェルナーは作成者です、そして彼はジキルの作成者としても知られています、本当に影響力のある静的サイトジェネレータです。彼はまた、構成ファイル言語であるTOMLも実行しました。彼はもともとGitHubのCEOでした。それで、彼のJekyllページとGitHubページでの作業と、そのようなことは、私たちが現在Jamstackと考えているものに本当につながったと思います。多くの人がこう言うでしょう。「ああ、Jamstackの新しい。彼らはこれを永遠に続けてきました。」これが、これらの古いアイデア、静的サイト世代の拡張である方法について話してきましたが、GraphQLとサーバーレス、およびグルーコードとAPIを使用してアプリを機能させる方法のアイデアです。

ドリュー：それで、これは間違いなくそのコミュニティに非常に埋め込まれている人々からのものですか？つまり、GitHubのCEOは、それ以上にオープンソースコミュニティに組み込まれることはありません。つまり、Redwoodはフルスタックフレームワークであり、フロントエンドとバックエンドでRedwoodコードを実行していることを意味していると思います。そうですか？

アンソニー：ええ、これは私がレッドウッドプロジェクトを見せているときに人々に最初に説明したいことです。それはモノレポだということです。つまり、フロントエンドとバックエンドが同じリポジトリにあり、それぞれが独自のフォルダーに存在します。フロントエンドであるWebフォルダーがあり、CreateReactアプリから取得するものとかなり似ています。次に、バックエンドであるAPIフォルダーがあります。これは、すべての関数が基本的に1つの大きなGraphQLハンドラーに押し込まれ、Netlifyを介してAWSLambdaにデプロイされます。

ドリュー：さて、あなたが言うように、フロントから始めて、それはReactに基づいています。そのReactとRedwoodコードの束ですか、それとも単なるReactですか？そこのバランスはどうですか？

アンソニー：それはたくさんのことです。多くの状態管理ライブラリを導入しておらず、実際にはルーターも導入していないという意味で、これは間違いなくReactです。彼らは自分たちが書いた独自のルーターを持っており、GraphQLのものをたくさん使用しています。つまり、人々がReactやGraphQLや友人について話すとき、それはここで起こっていることの一部です。それは、ReactがGraphQLと通信するための多くのデフォルトの統合を提供するということです。 Reactの使い方については多くの慣習がありますが、データのフェッチは依然として非常に面倒です。

Drew：つまり、Reactは、Reactとうまく連携して、この特定のスタイルのタスクを実行するための機能するエコシステムを提供する他のツールで構成されています。それは公正な説明ですか？

アンソニー：ええ、いや、ええ、それはそれを置くための素晴らしい方法です。トムの言い方では、これらの最高のソリューションがすべて存在し、使用できる非常に洗練されたツールとテクノロジーがありますが、非常に大きな初期費用がかかり、それらを学ぶ必要があるため、実際にそれらを活用することは非常に困難です。、それらを統合する方法を理解する必要があります。そのため、彼らはタグラインを「私たちはあなたのためにあなたのwebpack設定を行います」と置きました。

Drew：クライアント側のJavaScriptアプリを使用して最新の開発フレームワークを開始し、Webパックを構成し、さまざまなものをすべて構成し、ビルドプロセスを開始しようとすると、多くの人からよく聞かれる問題点だと思います。ビルドステップ。すべてをつなぎ合わせて機能させることは、かなりの地雷原になる可能性がありますね。そして、「Hello、World！」に到達するまでには長い道のりがあります。それで、レッドウッドは私たちにすべての事前構成を与えていますか？

Anthony：そうですね、設定より規約です。トムは、Ruby on Railsと他のコアコントリビューターの1人であるRobを使用してGitHubを構築したように、ずっとRails開発者でした。彼らは、Railsに関して哲学的に一致する多くのアイデアを持っていますが、構成のアイデア、フルスタックフレームワークのアイデアにそれらの慣習を取り入れ、現在のすべての最新テクノロジーでそれを実装したいと考えています。

ドリュー：それで、あなたはレッドウッドがあなたにルーターを与えると言いました、私たちが池のこちら側で言うように、それはデフォルトのコンポーネントやReactのそのようなもののようなものが付属していますか、それともあなたはちょうどその時ですかそれをすべて自分で実装するには？

アンソニー：ええ、ルーターは非常に洗練されています。 Reactルーターから得られるもののほとんどを実行します。次に、独自のルーターもあるため、これらの実装方法に関しては、さまざまなアイデアがありますが、まだ完全には理解されていません。シングルページアプリのルーティングを機能させたい。サスペンスのせいで、非同期のものがどこに入るのかについて、この種の質問がたくさんありますか？ Redwoodには、このセルのアイデアがあります。これが、実際にデータをフェッチするためのものです。

ドリュー：それで、多分私たちはそれについて少し入ることができますか？レッドウッドの観点からセルとは何ですか？

Anthony：そうですね、セルはGraphQLクエリを作成するデフォルトの方法であり、基本的に、データを取得しているかどうか、エラーを取得しているかどうか、読み込み状態にあるかどうかをページに通知します。または…もう1つの状態があるかどうか、私は忘れます。しかし、ええ、それはあなたがあなたのデータを取得しているかどうかに基づいて基本的にあなたがいることができるさまざまな状態をあなたに与えます。 Apolloを隠してセットアップします。したがって、Redwoodを使用している場合は、GraphQLクライアントとしてApolloを使用していますが、それについて考える必要はありません。 Apolloを作成したり、考えたりする必要はありません。すべてが組み込まれています。GraphQLクエリを作成できます。これは、人々がGraphQLを望んでいた理由の夢でした。これは、フロントエンド開発者がこの非常にシンプルなクエリ言語であったことです。使用できます。しかし、次に、GraphQLサーバーをセットアップする方法を理解する必要があり、他のすべてのものを理解する必要があり、どのようにしてすべてを接続するのかを理解する必要がありました。つまり、すべてのGraphQL統合を実行するので、GraphQLを作成するだけで済み、GraphQLをどのように実装するかを考える必要はありません。

ドリュー：つまり、フレームワークの古典的な仕事の1つは、自分で記述できるすべてのボイラープレートコードを取得して実装し、舞台裏を整理して、ボイラープレートを見る必要がないようにすることだと思います。繰り返しになりますが、状況に固有のコードを書くことができます。それが細胞で起こっていることだと思いますか？ここには革命的なものは何もありません。Reactコンポーネントを設定してこれらすべての異なる状態を設定し、Apolloに接続して、これをすべて自分で行うことができますが、これは実際には非常に多くの作業であり、一般的なパターンです。そのため、Redwoodは、考えなくても使い始めることができる、再利用可能な素敵なパターンに整理されました。それは良い説明ですか？

アンソニー：ええ、彼らは名前を思いついたのですが、これは頻繁に見られる慣習であり、多くの人が自分でコーディングしているのを見たことを間違いなく認めており、データフェッチを行うための宣言型の方法が必要だと判断しました。だから、これがあなたがこのセットアップを持っている理由です、それはあなたがあなたの異なる状態を持っているだけであり、あなたが理解するためにif / thenロジックをする必要がないので、これが起こったらこれをする必要があります。つまり、データをロードするときにデータが存在する可能性のあるさまざまな状態をすべて宣言する方法が1つしかないということです。

ドリュー：それはReactの特徴の1つですよね、Reactはプロジェクトのアーキテクチャを提供しようとしないので、どのように構造化するかを決めることができます。もちろん、これには長所と短所があります。しかし、Redwoodがその構造の一部をあなたに課しているように思われるので、あなたはそれについて考える必要がなく、それはあなたのために配管を入れて、Reactがあなたに与えるという点で中断したところを拾うことができますそのような構造。

アンソニー：ええ、この問題のこの解決策で複数の異なる試みが見られたのは本当に興味深いことだと思います。なぜなら、永遠にそれを言ってきた人々がいたからです。 JavaScriptまたはRailsfor React？」 MichaelChanとAdamWathanの間には、React is Not aRailsのライバルと呼ばれる素晴らしいフルスタックラジオインタビューがあります。これは、さまざまなフレームワークの1つです。

アンソニー：他のものはかなりの量の話題を得ているBlitzJSです、そしてそれからバイソンは一種の新しい新進気鋭のものです。それらはすべて同じようなスタックを持っていますが、それらは異なる部分を使用しています。 Apolloの代わりにReactクエリを使用するか、Tailwindの代わりにChakraを使用します。これらすべてのピースをスタックにまとめている人々、これらすべてのスタックは一種であり、彼らはそれと戦っています、それはすべて非常に友好的な競争です。実際、それは私が本当に感謝していることの1つです。私たち全員が、実際にはフレームワーク間でもコラボレーションしているということです。そこには敵意はありません。

Drew：では、ApolloとGraphQLについて説明しましたが、Redwoodはフレームワークのコアピースの1つとしてGraphQLを非常に多用していますね。ポッドキャストのエピソード全体をGraphQLだけに捧げることはできますが、慣れていない人にとっては、GraphQLはここでどのような部分を行っているのでしょうか、このコンテキストでどのような問題を解決しているのでしょうか。

アンソニー：ええ、これは素晴らしい質問です。 Redwoodを使い始めるために知っておくべきことを人々に伝えるとき、Create Reactアプリを作成し、それをNetlifyまたはにデプロイした場合は、CreateReactアプリを使用する必要があります。ヴェルセル、それはあなたに良いスタートを切るでしょう。次に、GraphQLは非常に中心的であるため、少なくとも少しは知っておいてください。つまり、GraphQLは、フロントエンドがバックエンドと通信する方法です。彼らはそれがAPIのクエリ言語であり、RESTful APIメソッドの代替となることを意図しており、RESTfulなことを行う代わりに、受信したい階層データ構造を正確に指定するクエリを送信していると言います。データベース。そのため、GraphQLサーバーが2つの部分と通信できるようにするには、もう少し起動時間が必要です。次に、そこにデータを配置すると、フロントエンド開発者ははるかに柔軟な方法でデータを取得できるようになります。バックエンドの担当者が作成し続ける必要のある、これらのさまざまなAPIエンドポイントすべては必要ありません。

Drew：では、フロントエンドの要件に変更があった場合、おそらくGraphQLクエリを微調整するだけで、バックエンドで作業する誰かの助けを借りてその変更を行う必要はありませんか？

アンソニー：つまり、本当の夢は、モバイルクライアントをそれに投入できることです。最終的には柔軟性が高くなり、複数のクライアントがすべて1つのAPIと通信できるようになります。 GraphQL APIが信頼できる唯一の情報源になり、すべてのロジックが一元化されます。次に、これらすべての異なるビューレイヤーを上に構築できます。

Drew：つまり、GraphQLがあり、ある種のバックエンドをクエリする機能があります。レッドウッドでは、バックエンドは何ですか？

アンソニー：うん。バックエンドを作成するには、いくつかの異なる方法があります。チュートリアルでは、箱から出してすぐに使える方法があります。これは、HerokuにデプロイされたPostgresデータベースを非常に簡単に、非常にシンプルに使用することです。次に、RedwoodアプリがPrismaと通信します。 Prismaに精通しているかどうかはわかりませんが、O / RMのようなものです。彼らは特にそれがO / RMではなく、もう少し低いレベルのクエリビルダーであると言っています。しかし、それを人々に説明するために、Prismaはデータベースと通信できるようにするものです。移行を行い、テーブルを設定します。すべてのSQL処理を実行するため、SQLを作成する必要はありません。私には、それはO / RMのように聞こえます。 Redwoodを使用する場合でも、必ずしもPrismaを使用する必要はありません。

Anthony：私は実際に、代わりにFaunaDBを使用した概念実証アプリを作成しました。 FaunaDBには独自のGraphQLAPIがあるため、GraphQL APIをFaunaに直接送信して、データベースの変更をそのように行うことができます。 PrismaのCLIの多くの機能が失われますが、Prismaは、リレーショナルデータベースを非常に簡単に操作できる便利な要素です。しかし、実際には、考えられることは何でも、Redwoodと接続する方法を理解できます。これは、GraphQLを中心に構築されており、これらすべての異なる部分と通信できることが重要であるという理由だけで私が見つけたものです。

Drew：つまり、Prismaは基本的に、コードと、おそらくPrismaがサポートしていると思われる、使用しているデータストアとの間の一種の抽象化レイヤーです。それは…それとも、それよりもインテリジェントなことをしているのでしょうか。

Anthony：ええ、スキーマを作成して、schema.Prismaファイルを作成すると、モデルの投稿が含まれ、IDと整数が含まれ、タイトルの文字列、本文の文字列など、日付と時刻に自動インクリメントされます。。したがって、基本的には、タイプを使用してデータベースに入れたいものを作成し、データベースを操作する必要がないようにデータベースを処理します。

Drew：つまり、Prismaを使用して、話しているデータベースの種類やデータストアの種類を定義します。次に、そこで、その用語を使用するためにさまざまなMVCモデルをレイアウトします。では、アプリケーションがデータストアと通信しているときは、Prismaクライアントのインスタンスを使用しているようなものですよね。それは何が起こっているのですか？

アンソニー：はい。ええ、まさにそれです。したがって、バックエンドのAPIフォルダーには、db.jsを含むlibフォルダーがあり、デフォルトでは、Prismaクライアントがセットアップされています。つまり、箱から出してすぐに使えるものはこれだけです。あなたが言ったように、Prismaはさまざまなデータベースを操作できます。開発用のSQLiteと本番用のPostgresを切り替えることができます。現在はほとんどがリレーショナルなものですが、ロードマップにはモンゴや動物相などが含まれています。

Drew：それで、ローカル開発環境でSQLiteをセットアップして使用し、MySQLのようなものを使用して本番環境に移行できる場合、これは非常に便利です。

アンソニー：それがまさにチュートリアルの設定方法であり、それがあなたに示されるワークフローです。

Drew：フレームワークへの非常に現代的なアプローチを見てから、MySQLのようなこれらのより伝統的なデータベースのいくつかにフォールバックするのは非常に興味深いですね。私はMySQLに精通しています。私はその安定性が大好きで、データを格納するリレーショナルな方法が大好きです。私はそれが非常に多くのことのためにとてもうまくいくと思います。新しいタイプのデータストアに関しては、お風呂の水である赤ちゃんが捨てられるのをよく目にします。そのため、Redwoodがデフォルトでこれらの古き良きリレーショナルデータベースをサポートしているのを見るのは非常に興味深いことです。

アンソニー：ええ、いや、それはとても良い点です。なぜなら、レッドウッドが組み合わせるすべての新しいものについて、実際に古い、試行錯誤された、真の方法が実際に最良であると言うことがいくつかあるからです。ですから、それらはリレーショナルデータベースでは本当に大きいのです。これは、Railsを使用してリレーショナルバックエンドを使用したトムの経験から来ています。 Active Recordは、Prismaが概算することを意図したO / RMレイヤーでした。

Drew：おそらく、ここではRedwoodとサーバーレスアーキテクチャについて話していて、Chris Coyierと話をしました。2、3話前に、APIやクラウド機能などを使用したサーバーレスについて話しました。したがって、一歩後退して、サーバーベースのフレームワークの観点から考えると、Ruby on RailsやPHPの世界でのLaravelのようなものについて言及しました。 Reactフロントエンドを使用する場合でも、APIリクエストは、RailsコードまたはLaravelコードに加えて、ユーザーコードと構成であるコードを実行します。それはレッドウッドでも同じですか？実行される実際のRedwoodサーバーコードはありますか、それとも独自の実装を可能にするツールと構造と接着剤だけですか？

Anthony：ええ、バックエンドには、SDLを取得する方法であるファイルがあります。つまり、スキーマ定義言語があり、サービスと呼ばれるものがあります。これは、バックエンド。次に、これらすべてが1つのLambda関数にデプロイされるGraphQLハンドラーにまとめられます。そのため、特にLambda用に最適化されています。実は最近、サーバーレスフレームワークを使って誰かにやってもらいました。そして、AzureとGoogleCloudで何かに取り組んでいる人もいます。これはGoogleCloudの機能ではなく、その上に構築された機能です。しかし、そうです。現在、基本的には、AWSLambdaでGraphQL関数としてバックエンドをデプロイするために最適化されています。これは私が理解していないコードで起こっているすべての魔法ですが、それは高レベルの説明です。

ドリュー：それで、あなたが書いたすべてのコードを取り込んで、クラウドで実行できるある種の魔法のコードのボールにまとめて、AWSに配置するデプロイメントツールがあります。それでもそのプロセスを自分で管理する必要がありますか？

アンソニー：そうですね。チュートリアルに従えば、すべてNetlifyで完了します。サーバーレス機能を自分でいじる必要はありません。バックエンドを相互に接続してAWSLambdaに押し込むものはすべて処理され、そのコードに触れる必要はありません。これはすべて、構成に関する規則としてそのまま生成されるため、サーバーレスにする方法についてあまり考える必要はありません。デフォルトではサーバーレスです。頭を包むのは本当に難しいことです。頭を包むのに少し時間がかかりました。

ドリュー：ええ、それは重要なポイントなので、私たちがここで追跡しているいくつかの異なる領域が実際にあるからではありません。私たちは3つの異なる分野を持っていると思います。ブラウザで実行されるフロントエンドのReactアプリがあり、次にクラウド関数として実行されるGraphQLベースのAPIがあり、クエリに応答しますが、それはデータストアと相互作用しますPrismaを使用しています。そして、そのデータストアは、NetlifyでMySQLサーバーを実行できないため、この中のどこにあるのでしょうか。

Anthony：はい、Herokuの出番です。したがって、チュートリアルの最後の部分では、フロントエンドをNetlifyにデプロイしてから、バックエンドをHeroku Postgresにデプロイし、Herokuから構成変数を取得してプラグインします。 Netlifyに。 NetlifyフロントエンドをPostgresバックエンドと通信させることは本当に本当に簡単なことです。彼らは、誰もがスピンアップするのが最も簡単になるであろうものを使いたいと思っていましたが、それでも安定した、戦闘でテストされた技術を持っています。最後に、指示に従うだけで箱から出していくものは本当に素晴らしいです。

Drew： Jamstackの愛好家は、APIとしてデータストアを提供するFaunaDB、AWSにはDynamoDB、GoogleにはCloudSQLなどのサービスに精通しているでしょう。それで、Redwoodが統合を検討しているとおっしゃいましたが、Prismaは、今後これらの種類のサービスとの統合を検討しているコンポーネントだと思いますか？

アンソニー：ええ、これは良い質問です。これは、私が実際にPrismaのRyan Chenkieと話していることですが、Prismaで必ずしも機能しないものについては、Redwoodのデータベースストーリーの種類は何ですか？私がFaunaで行ったように、Redwoodを直接操作する方法を見つけたほうがよいでしょうか、それともPrismaのドライバーを実装する方が理にかなっているでしょうか。したがって、それにアプローチするさまざまな方法があります。誰もが使いたがっているデータベースは明らかに100万あります。そのため、データストアをデータベースに導入する意欲は非常に高くなっています。そこにはたくさんのコミュニティの貢献があります。

Drew：では、Prismaはモデルを理解し、それらをクエリする方法を知っているので、データベースのセットアップに役立つ何らかの移行などを生成できますか？

Anthony： Prismaを取り出してデータを取得する必要があるときに失うのは、まさにそれです。つまり、すべての移行機能が失われるということです。非常に高度なCLIを備えているため、Redwoodチュートリアル全体を実行して、Prismaコマンドを入力できます。何をしているのかわからなくても、機能します。これは、正しく実行されていることを確認し、正しく実行されていることを確認したい、あらゆる種類のデータベースタイプの処理を実行するための非常に優れたツールです。

Drew：フレームワークの周りに本当に良いツールがあるのは、かなり現代的な傾向のようですね。「このフレームワークで実行できることはすべてここにありますが、おそらく、このフレームワークのすべてを実行するCLIツールがいくつかあります。」と言うだけではありません。 Redwoodには、CLIジェネレーターなど、すばやく起動して実行するためのツールがありますか？

アンソニー：これはおそらくレッドウッドから得られる最大の重要な機能です。非常に洗練されたジェネレーターのセット全体を手に入れることができます。 DHHが提供したオリジナルのRubyon Railsデモを見たことがある人なら誰でも、彼は15分ほどでブログを作成し、それをすべてRailsで行います。人々は、「おお、これはすごい」と言っています。それがレッドウッドの効果です。彼らは、ページを生成したり、レイアウトを生成したり、私が話していたセルを生成したり、全体を作成するスキャフォールドコマンドを実行したりできるように、すべてをすばやくスピンアップできるようにしたいと考えています。 CRUDインターフェース。ブログシリーズのパート4のセクション全体があり、スキャフォールドが提供するすべてのコードについて説明しています。それはあなたにとても多くのコードを与えます。オフジェネレーターがあり、追い風を構成するテールウィンドジェネレーターもあります。

ドリュー：それはすごい。 DHHのRailsのデモを見たのを覚えています。つまり、おそらく、15年前に彼が最初にその足場を作って見せてくれたとき、基本的に新しいアイテムの作成、編集、削除などを可能にする、かなり初歩的で機能的なコントロールパネルが表示されます。。これはプロジェクトで非常に貴重な場合があります。特に、コンテンツを編集するためのより優れたツールを将来実装する予定のある種の動的な環境で作業する場合は非常に重要ですが、何かをすばやくスピンアップできることを意味します。データをテストするか、フロントエンドで作業しているときに作業を開始できるコンテンツチームにデータを渡すこともできるので、非常に便利です。

Drew：それをデプロイして本番環境に配置したい場合は、おそらくフロントエンドコードと一緒にデプロイできますが、その側面、つまりアプリケーションのルーツを保護するための何らかの方法が必要になります。

アンソニー：ええ、認証にはいくつかの異なるオプションがあります。 NetlifyIDを使用できます。チュートリアルに入ると、これがデフォルトです。次にAuth0を使用することもできます。その後、Magic.Linkと呼ばれる、私がよく知らないものを使用できます。将来、さらにいくつか追加される予定です。しかし、ええ、すでにいくつかの組み込みソリューションがあります。それが最後のことです。これが、私の12部構成のブログシリーズ全体の最後の部分であるAuthです。 Redwoodを使用する前にAuthを理解したことはなかったと思います。それは難しいです、そして彼らは間違いなくそれで良い仕事をしました。

ドリュー：それはルートレベルで統合されますか、それともルートレベルで統合されますか、申し訳ありませんが、どのように物事を保護しますか？

アンソニー：ええ、彼らが独自のルーターを持っている方法の一部として、彼らも持っています…あなたはプライベートルートを行うことができるので、彼らはプライベートルートコンポーネントを持っています。次に、実際のログインフォーム（Netlify IDから取得するもの）を使用して、実際にフォームを作成して状態管理を行う必要がないため、多くの問題が発生します。本当に重要な部分を取り除くと、役割ベースのアクセスを実装できます。過去数週間にDavidTによって行われた役割ベースのアクセス制御アドオンがあります。したがって、他の方法を作成するために多くの作業が行われていますが、彼らが今得ているのはすでに…それは機能します。機能的になります。

Drew：人々は常に、セキュリティアルゴリズムのハッシュ暗号化について言います。それは、そこにあるものほど良くなることは決してないので、自分で書くべきではないということです。ますます、それはより高いレベルの認証にも当てはまると思います。その認証は最近非常に複雑な領域であるため、ユーザーは一意の資格情報を使用してサイトにログインするだけでなく、Googleを使用して認証したり、Appleデバイスを使用して認証したり、2要素認証を使用したりする可能性があります。、または企業から使用しているシングルサインオンサービスと統合したい場合があります。自分で実装しようとすると、これらすべてが非常に頭痛の種になり、アプリケーションに問題が発生してセキュリティホールが発生する可能性が非常に高くなるため、現時点では、認証サービスを使用するのは簡単なことのように思えます。したがって、基本的に数行のコードで何かをドロップして稼働させることができるということは、作業を行い、物事を安全に保つための本当に生産的な方法のように思えます。

ドリュー：フロントエンドとサーバーの両方の側面、つまりサーバーレス機能の展開は、Netlifyへの展開に自然に適しているようです。あなたはレッドウッドとそれに結びついていますか？つまり、トム・プレストン・ウェルナーはこのフレームワークの主要な支持者の1人であり、Netlifyの役員でもあります。プロジェクトのベースとしてレッドウッドを選択した場合、そこではカップリングが緊密になりすぎる可能性があると思いますか？

アンソニー：ええ、これはトムが間違いなく意識していることです。彼は浮かんでいる多くの会社に投資してきました。彼はプリズマと動物相に投資しました。彼は自分が使いたいツールを作りたいだけです。 Netlifyが構築したものが最良の選択肢であると彼が考えているほど、私たちがあなたをこのことに閉じ込めたいということではありません。そのため、彼らはそれを中心に構築しました。しかし、彼らはそれが1つのデプロイターゲットに固定されることを望んでいません。そのため、サーバーレスフレームワークなどの作業が行われており、一部の人々はBeginについて話しました。私たちは実用的でありたいと思っています。誰かのユースケースが何であれ、それが機能することを望んでいます。ですから、私たちはあなたに90％の道を譲り、それからあなたはそれをあなたの選んだサーバーが何であれそれを動かすために最後のいくつかのものを配線する必要があります。

Drew： Netlifyでさえサーバー機能にAWS Lambdaを使用していると思います。そのため、Redwoodが処理するのは実際にはデプロイ部分であり、実際にはそれをLambdaにデプロイできます。フロントエンドの投稿は単なるファイルですよね、それはCDNベースの残りの部分です。ですから、あまり縛られることなく、そこにはかなりの柔軟性があります。

アンソニー：ええ、トムがレッドウッドの背後にある中核的な哲学的アイデアとして実際に話している用語があります。それは、ユニバーサル展開マシンに到達したいということです。それは一種のアイデアです。つまり、物事を展開するだけで、それについてまったく考える必要がないということです。彼は何年も何年もの間この考えについて話していました、そしてこれはジキルが当時でさえあったことです。今それを聞くと、「ああ、Netlifyのような意味ですか？」これは基本的に、フロントエンドで作業しているほとんどの人にとってNetlifyが何であるかです。彼らはもう展開することさえ考えていません、それは考えさえしていません。

Drew：これがGitリポジトリ内の私のアプリケーションです。このディレクトリはフロントエンドです。このディレクトリはバックエンドです。これが私のデータベースです。これは、それを取得してビルドするためのサービスに必要な構成とほぼ同じです。そしてそれをホストします。

Anthony：はい。また、ごく最近、Vercel Redwoodのデフォルトのデプロイが設定されたので、サーバー側のアプリにデプロイする場合は、「ああ、Gatsbyアプリがあります」と言うことができます。ギャツビーアプリとネクストアプリの構築方法を正確に知っています。私たちは今Vercelのためにそれを持っています。ですから、もっと興味があれば、Netlify以外の本当に良いオプションもあります。

Drew：では、今週からアプリを作成して本番環境に移行したいのであれば、Redwoodはその準備ができていますか？成熟していますか？

アンソニー：ええ、現在生産中のアプリは約6つあります。最初のものはPredictCOVIDと呼ばれ、3月にリリースされました。これは、リアルタイムのデータ視覚化アプリケーションのようなものです。次に、repeater.devがRobによって実行されます。これは、Jamstackのcronジョブのようなものです。次に、Tape.shがあります。Duoflagは別のものだと思います。したがって、少なくとも一握りがあります。あなたが素晴らしいレッドウッドレポに行くなら、あなたはそれらすべてのリストを見ることができます。コミュニティフォーラムに行くと、これらの記事も見つけることができます。なぜなら、人々はこれらを本番環境に入れて、それがどのように進んだかを言っているからです。これまでのところ、それらはすべて成功しており、「これを二度と使用することはない」と誰も言っていません。

ドリュー：しかし、それは非常に新しいものです。それを逃れることはできないと思いますが、成熟度の点では、レッドウッドはかなり新しいものであり、好評を得ています。

アンソニー：まあ、それは面白いです、それはそうです、そしてそうではありません。 3月に発表されました。その時点で、それはトムとピーターによって約1年間取り組んでいました。 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-

ドリュー：もちろん。

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. 例えば。 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. 別れの言葉はありますか？

アンソニー：このようなものに興味がある場合は、お気軽にご連絡ください。私のDMは常に開いています。コミュニティは一般的に非常にオープンです。説明したり、ウォークスルーしたり、開始するために知っておく必要のあることをすべて設定したりできます。