Laravel Podcast - 2024年8月
Maru2024/08/29 Matt Stauffer x Taylor Otwell
Laravel Podcast Episode 15
※本PodcastはLaracon US 2024 Day2の間をぬって撮影された特別版
Intro
Matt)
さて、みんな、Laravelポッドキャストへようこそ。今回は、ライブ…ってわけじゃないけど、Laraconで一緒に収録してるよ。
昨日、Taylorが大きな発表をしたばかりで、今、裏で少し時間を取ってリスナーからの質問に答えてもらうことにしたんだ。これが終わったら、また彼を大きな会議の場に送り出す予定。
Taylor、時間を取ってくれてありがとう。
Taylor)
うん、ここにいられて僕も嬉しいよ。
Laracon US 2024の感触
Matt)
ありがとう、じゃあ早速始めようか。今回の質問のほとんど、いや、ほぼ全部がユーザーからの質問なんだ。
君が発表した内容についての質問があるけど、ほとんどはLaravel Cloudに関することだね。
みんなの注目がそこに集まってるみたいだ。
でもその前に聞きたいんだけど、今日は2日目の午後だね。
君は今回、少なくとも体力的にはこれまでで一番力を入れていたと思うんだけど、Laraconはこれまでのところどんな感触かな？
Taylor)
今のところ、すごくうまくいってると思うよ。
どの発表もとてもインパクトがあるものだね。
僕が顔を合わせた全員が素晴らしい時間を過ごしていると言っていたよ、それが一番重要だよね。
会場も素晴らしいよね。
イベントチームがステージやセットとか全ての準備を素晴らしく仕上げてくれたおかげだね。
僕はとても幸せだし、順調に進んでると思うよ。
Laravelの立ち位置
Matt)
そうだね、僕は普段「最新のものが一番良い」って言いたくないんだけど、今回のLaraconは色んな意味で過去最大で最高だと感じるんだ。
参加者の数とか、発表の重要性とか、色んな要素があるけど、コミュニティがある種の転換点(tipping point)に達したように思うんだ。
君やAaronも言ってたけど、Larvel Cloudとかそういう新しい発表が転換点っていうのもあるよね。
でも僕はその転換点はそれ以前から始まってたように感じるんだ。
今までの取り組みの継続で転換点に達している感じ。
会場で感じるエネルギーとかここにいる新しい人たちの数とか、Laravelの外の世界で影響力のある人たちが「お、Laravelか」って感じで注目してるのが伝わってくるんだ。
今年はそういうのがたくさん起こる年なんじゃないかってね。
君もそのエネルギーを感じてるんじゃないかな。
Taylor)
うん、僕もそのエネルギーを感じているし、それをもっと大きくしたいと思っているよ。
Matt)
そうだね。
Taylor)
インターネットで彼らについて感じていることだけど、良くも悪くも複雑さにちょっと疲れていて、「とにかくアプリケーションをリリースしたいんだ」っていう感じなんじゃないかな？
パンにバターを塗るみたいにさ。
そしてLaravelエコシステムにはアプリケーションをリリースするための素晴らしいツールやクールなライブラリとかがあるんだ。
だから、PHPの歴史の中でLaravelがちょうど良いタイミングで登場したのと今は同じような感じなんじゃないかな。
Laravel Cloudや僕たちが開発しているいろんなものが、みんなが「もうちょっと簡単にならないのか？」と感じているタイミングにピッタリなんじゃないかなって思うんだ。
もしかしたら、僕たちWeb開発者はちょっと物事を複雑にしすぎたのかもしれないね。
だから、今はWeb開発にとって興味深い時期だと思うよ。
Matt)
そうだね、面白いのはみんなが求めているのが、ホスティングのシンプルさであれ、開発のシンプルさであれ、結局は「シンプルさ」なんだよね。
そして、Laravelがちょうど良いタイミングで登場したっていうのは、その通りなんだけど、これは「一夜にして成功したように見えて、実は10年かかった」って感じだよね。
君は文字通りステージに10年立っていたわけだし、僕たちは10年間コミットし続けてきたんだよね。
今、注目されている新しくてかっこいいWebベースのフレームワークで、これほど長く続いているものは他にあまりないよね。
ずっと存在しているフレームワークもあるし、新しくてかっこいいものもあるけど、それを同時に備えているっていうのが今のLaravelが持つ特別な魅力だと思うんだよね。
Taylor)
うん、僕もそう思うよ。
Matt)
そうだね、君やLaravelチームが行っている事を見るのが本当に楽しいよ。
僕は昔から「どうやったらLaravelをエコシステムの外でももっと知ってもらえるか」って考えてきたんだ。
それが君にとっても、僕にとっても、僕のチーム全体にとっても役立つと思うからね。
Laravelがもっと広く知られるようになれば、もっと多くの企業が「Laravelを使いたい」となって、もっと多くのプログラマーが「Laravelを学びたい」と思うようになる。
だから正しい引用かわからないけど、「満ち潮はすべての船を持ち上げる」って言葉のように、
Laravelの知名度や評価が上がることで、僕たちみんなにとっていいことがいっぱいあるんだよね。
だから、みんなが同じ目的で、ここLaraconに集まってるのを見るのは本当に楽しいよ。
みんなで楽しい時間を過ごして、もっと多くの人に同じ経験をしてもらうためにね。
Taylor)
そうだね、今年はLaravelコミュニティの外の人たちも、例年より注目してくれてるのが見えて良いよね。
それに、PHPがなんだかんだでまだ存在感を保ってるって感じがするんだ。
そして君が言ってたように、僕たちはこれをもう10年間続けてきたんだよね。
その一貫性が大きいと思うんだ。
ウェブ開発の世界では、多くのプロジェクトが途中で消えていくことが多いんだよね。
メンテナーが燃え尽きちゃったり、複雑になりすぎたりして。
そして誰かがもっとシンプルな新しいものを作るんだけど、結局同じような問題に直面して、また同じことが繰り返されるんだよね。
Laravelの最大の強みの一つは、何年もかけてエコシステムを一貫して改善し続けてきたことだと思うんだ。
そしてフレームワーク自体を慎重に管理してきたことも大きいと思う。
GitHubでは必ずしも楽しいことばかりじゃないんだけど(笑)、でも、僕が今でも全てのプルリクエストを管理してるんだ。
それが実際にすごく役立ってると思うんだよね。
スタイルを統一する唯一のキュレーターがいるってことだからさ。
Matt)
うん、ビジョンとか一貫性も含めて統一できるもんね。
Taylor)
フレームワーク全体にわたってオープンソースでね。
だから、日々の地道な努力を続けることが大事なんだと思うよ。
Laravelは13年間ずっと素晴らしくあり続けたわけじゃないけど、地道に続けてきた事がLaravelの強みを少しずつ確実に作ってきたんだと思うんだ。
それが僕たちが今でもフルスタックウェブ開発の話題に残っている理由じゃないかな。
しかも話題に残るだけじゃなくて、ウェブアプリを生産的に作る手法のリーダーの一人として君臨しているのが素晴らしいことだと思うんだよね。
Matt)
そうだね。
このカンファレンスで多くの人と話していることなんだけど、プロジェクトのキュレーションやビジョンって、本当に基盤になる部分だと思うんだ。
僕はよくjQueryプラグインの話を引き合いに出すんだけど、かつてはウェブ全体がjQueryとそのプラグインに依存してた時代があったよね。
でも、プラグインの開発者のほとんどは、「誰かに何かを頼まれたからといって、それを追加する必要があるわけではない」とか、「17通りのやり方があるからといって、17個のパラメーターを追加する必要があるわけではない」という考え方を欠いていたんだよね。
つまりどんどん追加していったんだ。
だから、ビジョンとか、何を採用するか・何をカットするかを判断する能力、それらを持つことが重要だと思うんだ。
APIをシンプルに保ち、何かが複雑になりすぎたらリファクタリングする判断も必要だと思うんだ。
もしLaravelが他のすべての素晴らしい要素を持っていたとしても、その一貫したビジョンがなかったら、13年の間に大量の無駄なものが積み重なって、今の位置にはいなかったんじゃないかって思うんだよね。
Taylor)
うん、僕もそう思うよ。
そして、PHPの存在感について話すと、ここLaraconで聞いた話は本当に驚きだったよ。
ある大企業が巨大な.NETシステムをPHP、Laravelに移行しているって話を聞いたんだ。
普通、企業がシステムを移行するときって、逆の方向に行くと思うだろう？
最初はPHPみたいに軽いもので始めて、最終的にはもっと堅牢だと思われるものに移行する、みたいに。
でも、Laravelの存在があることで実際に他の言語からPHPに移行するシステムがあるっていうのはすごいことだと思うんだ。
それは、これまで僕たちが築いてきたエコシステムや一貫した改善の成果だと思うし、コミュニティの活気もその一因だと思うんだ。
Laraconに来るとわかるけど、あるいはソーシャルメディアで見ていても、みんながLaravelにどれだけワクワクしてるかが伝わってくるよね。
コミュニティの雰囲気もすごく良いし、それが開発者を引き寄せて、Laravelを使いたくさせるんだと思うよ。
Matt)
いいね！
そして、初めてここに来た人たちが「みんなすごいエネルギーだね」って言ってるのが最高だよね。
「そうだろ？」って答えるのが大好きなんだ笑
この話題については一日中話していられるけど、他にも話さなきゃいけないことがあると思うから、この辺にしとくね。
コードに関する話をちょっとだけしてからCloudの話に移ろうと思うよ。
defer cache flexible concurrentなどの非同期・並列処理機能
Matt)
まだ昨日のTaylorの発表を見ていない人はそっちを先に見てほしい。素晴らしい発表だったね。
コードの観点から一つ聞きたかったのは、「defer」「cache」「flexible」「concurrent」の話は、僕にとって同じパズルの一部みたいに感じたんだ。
昔から話されていることだけど、他のプログラミング言語には長時間動作するプロセスがあって、それには利点と欠点があるけど、PHPは一度リクエストが来たらそれで終わりだって言われてたよね。
そして、Laravel Octaneがあることで、もしその複雑さが必要なら使えるけど、基本的には「Octaneを使うか、単一のリクエストで終わるか」という選択肢しかなかった。
でも今回の新しい機能は、その間を埋めるようなものに感じるんだ。
君も同じように感じているかな？
もしかしたら「cache flexible」は少し違うかもしれないけど、これらがただ長時間動作するか、すぐに終わるかだけじゃなく、その中間のグレーゾーンを提供してくれるように思えるんだ。
Taylor)
そうだね、「Defer」について少し背景を説明すると、「Defer」は関数の実行をブラウザにレスポンスを送った後まで遅らせるための方法なんだ。
これ自体は以前から可能だったんだけど、その場合は「terminable middleware」を使ったり、「app terminating」を使ったりする必要があったんだ。
でもそれらはアプリケーション内の場所によって一貫性がなかった。
例えば、Webレイヤーではそれで良かったんだけど、キュージョブの中や、キュージョブから呼び出されるリポジトリや他のサービスの中のコードではうまく機能しなかったんだ。
だからコードのどこにいるかを頭の中で把握しておく必要があって、正直あまり良い方法じゃなかった。
でも今は、「Defer」をどこでも使えるようになったんだ。
キューでも、CLIでも、Webでも、どこでも動作するようになってる。
そしてWebでは、僕の発表で見せたように、もし例外が発生したらその「Defer」された関数は破棄されるんだ。
もちろん、破棄されないように指定することもできる。
同じように、CLIでは、もしArtisanコマンドが非ゼロの終了コードで終了したら、その関数は破棄されるようになっているんだよ。
Matt)
素晴らしいね。
Taylor)
だから、「Defer」は、APIの一貫性を保つためのものなんだ。
個人的には、「Defer」を「Concurrency」よりもよく使うことが多いんだよね。
これは多くのLaravel開発者にとって、より広いユースケースに対応していると思うんだ。
例えば、メールを送りたいときとか、別のサービスに簡単なAPIコールをしたいときなんかに、レスポンスを送った後に実行するのでも問題ないときがあるよね。
そんなときに「Defer」を使えばいいんだ。
わざわざキューワーカーを設定したり、それをクラスに抽出したりする必要がないと思うんだ。
それって、結構よくあるケースだと思うよ。
あと、「Concurrency」はドライバーベースになってるんだ。
これは僕の発表では触れなかったんだけどね。
Matt)
え、そうなの？
Taylor)
僕の発表では、「process」ドライバーを紹介したんだけど、これはPHPプロセスを並行して実行するためのものなんだ。
具体的には、Laravelのシリアライザブルクロージャ機能を使ってクロージャをシリアライズして、それを隠されたArtisanコマンドに送るんだ。
そのコマンドがクロージャを実行して、親プロセスにレスポンスを返すという仕組みになってるんだよ。
これが一つのドライバーで、もう一つ「fork」ドライバーもあるんだ。
これはPHPのフォーキング機能を使っていて、プロセスドライバーよりも速いんだ。
ただし、フォーキングはWebリクエストでは動作しないから、CLIでのみ使えるんだ。
だから、この話は少しOctaneにも関連してるんだけど、Swooleを使っているとOctaneで並列処理ができることを知っている人もいるかもしれないね。
でも、僕は今回の「Concurrencyファサード」が、多くのLaravelアプリに並列処理をもたらすと思うんだ。
実際のところ、多くの人はSwooleのようなものを使わずに、nginxのような標準的なWebサーバースタックでLaravelアプリをデプロイしているからね。
だから、これは「残りの私たちのための並列処理」といった感じだよ。
Matt)
すごいね、それはいいね。
Taylor)
そう、僕も本当にクールだと思うよ。
だから、「Defer」と「Concurrency」の両方にワクワクしてるんだ。
そして君が言ったように、最初の「Defer」が「cache flexible」メソッドをアンロックするような形になったんだよね。
これはいわゆるSWR（Stale-While-Revalidate）パターンの実装で、Tim McDonaldが強く推奨してくれたんだ。
すごくクールなキャッシュ機能だよ。
今の僕なら、「cache flexible」や「cache remover」のようなものを使いたくなるね。
ユーザーにとっても体験がずっと良くなるし、レスポンス時間も速くなるからね。
これを使っていろんなものが実装できるだろうね、楽しみだよね。
「Defer」の素晴らしいところは、これをオプションとして考えられるようになったことで、僕たちの頭の中で新しいアイデアが生まれることなんだよ。
Matt)
そうだね。他には何かアイデアある？
Taylor)
これから先、もっと多くのユースケースが出てくると思うんだよね。
そしてそれは自分のアプリだけじゃなく、パッケージ開発者にも役立つユースケースになると思う。
例えばLaravel Novaを作るときに、ダッシュボードに大量のデータを表示する場合、それを同時に取得できるケースがあるかもしれない。
多くの場合、特定の順序でデータを読み込む必要はないからね。
例えば、あるモデルが持つすべてのリレーションを表示する場合も、全てのクエリが順番に終わるのを待たずに、同時に取得することができるんだよ。
どこまでこれを活用できるかは分からないけど、すごく面白い可能性があると思うよ。
Matt)
そうだね、多くのパッケージでは、どんなインフラで使われるのかは想定できないけど、
そう言った状況でも「これをやって、その後でこの重い処理をdeferする」ようにすれば、基本的にはもっと速く動作するようになると思うんだ。
Taylor)
そうそう、まさにその通り。
何かをするためだけにキューワーカーを設定する必要がなくなるんだよ。
Matt)
ああ、それは素晴らしいね。
デフォルトでの「Defer」バージョンとQueue Workerバージョンがあるってわけだ。
とても良いね。
Laravelチームのデザインディレクター
Matt)
さて、デザインの話を少しだけしたいんだ。
君はこれまで外部のデザイン会社を使ったり、自分でデザインを手掛けたり、時にはSteveや他の仲間たちに依頼したりしてきたけど、今はデザインディレクターがいるよね。
そして彼は入社後すぐにロゴを変更して、デザイン作業を担当してるだけでなく、ブランディングの作業も進めてるみたいだね。
その時次第でいろんな人が担当していたのが、君の会社の特定のデザインディレクターが担当するように変わったわけだけど、何か違いを感じる？
Taylor)
すごく違うね。
これは、将来的に振り返って「7年前にやるべきだった」と思うような採用になると思うよ。
君が言ったように、ロゴみたいな小さなことでもそうなんだ。
例えば、ロゴが小さくなると線が細すぎるってずっと前から分かっていたんだけど、彼が小さなサイズ用に少し線幅が太いバリエーションのロゴを作ってくれたんだ。
でも、彼、David Hillはデザインだけじゃなくて、すごく優れたプロダクトの考案者でもあるんだ。
ユーザーがアプリをどう進んでいくかとか、どこで詰まるか、どこで混乱するかを考えているんだ。
彼は「見た目をきれいにするだけが仕事じゃない」と言っていて、もちろんそれも得意なんだけど、プロダクト全体を通してどうあるべきか・どの順番でユーザーに体験してもらうか・すべてがどのように機能するべきかを考えるのが本当に上手なんだ。
それがすごく助かってるんだよ。
例えば、彼は既にLaravel Cloudのデザインから、私のLaraconのスライド、Terminal guysとのコーヒーのパッケージデザインまで、いろんなことをやってくれてるんだ。
だから、彼のデザインセンスを既存のプロダクトにも取り入れたいと思ってるんだ。
例えば、Forgeのデザインも時間をかけて見直す予定だよ。
いつそれが実現するかは分からないけど、アジェンダに載っているから、そこも楽しみだね。
Laravel Cloud / Forge / Vaporの使い分け
Matt)
なるほどね、話題がLaravel Cloudに触れたから、少しその話をしようと思うんだ。
多くの人が、Cloudの発表がForgeやVaporにとって何を意味するのかを聞いてきてるんだ。
これって、ForgeやVaporが終わりを迎えるってことなのか、それともごく一部の人たちだけに向けたものなのかってね。
君はどう考えているのかな、それともまだ答えは出ていない？
さっき、Forgeに時間を注ぐつもりだと言ってたから、Forgeは当然なくなるわけじゃないんだよね。
それぞれ誰が使うべきか、それともまだ模索中なのか教えてくれる？
Taylor)
各自が自分で何が好きで、何を使いたいかを決める必要があると思うんだ。
でも、インターネットではこれが相互排他的なものとして扱われている気がするんだよね。
僕たちのコミュニティだけではなく、JavaScriptのコミュニティとかでもね。
例えば、NetlifyやVercelのような大規模なフルマネージドプラットフォームがある一方で、Pieter Levelsみたいな人たちがいて、「5ドルのVPSで十分」みたいな感じのね。
でも、Laravelはその両方の選択肢を提供できるユニークな立ち位置にいると思うんだ。
人はそれぞれ違うし、ある人たちは伝統的なサーバーを好むし、他の人たちは何らかの理由、例えば自分たちの会社のセキュリティ状況に合わせて自分のAWSアカウントを使いたいとか、そういう理由でそれを選ぶんだよね。
Matt)
所有権の問題とかね。
Taylor)
完全にマネージドされたプラットフォームを使うのが現実的でない場合もあるんだよね。
でも正直なところ、僕自身は多くの開発者がフルマネージドプラットフォームの体験を本当に楽しめると思うんだ。
僕自身もそういうのが好きで、何も考えずにただプッシュして進めたいんだよね。
だから一方を選ばなきゃいけないとは思わないんだ。
すでにForgeがあるし、Forgeのために計画している機能もまだたくさんあるからね。
正直言って、Forgeのために構築するものは来年まで続く長いロードマップがあるんだ。
でも、Laravel Cloudのようなフルマネージドプラットフォームを持つことは、Laravelにとって次の論理的なステップだと思うんだ。
Laravelエコシステムに新しく入ってくる、ある程度サーバー設定経験のある人にとっては、Forgeはすごく使いやすくて論理的に感じるかもしれない。
でも、多くのLaravelを始めたばかりの人たちにとっては、VS Code拡張機能もそうだけど、全体的な体験がとても簡単であるべきなんだ。
そして、GitHubリポジトリをリンクして「デプロイ」ボタンを押すだけで動作して、URLがもらえる、IPアドレスだけじゃなくて、というのは、はるかに良い体験だと思うんだ。
だから、君の質問に戻ると、「両方やっちゃえばいいじゃん？」って感じだね。
人々が自分の会社や自分にとって何がベストかを決めればいいし、僕たちはその両方のプロダクトをサポートするためにここにいるんだよ。
Matt)
そうだね、僕は毎年何百ものクライアントと仕事をしているんだけど、クライアントたちは本当にいろんな状況にいるんだよね。
クライアントが何も気にしないなら、Cloudを使うことになるだろうし、特にこだわりがない場合もCloudが選ばれるだろう。
でも、多くのクライアントにはやっぱり好みがあるんだ。
だから、このアプローチはすごく理にかなっていると思うよ。
それに、チュートリアルを作る側としても、Laravel Cloudがもたらすものにとてもワクワクしてるんだ。
とはいえ、Forgeを使うのをやめるわけじゃないけどね。
でもこの新しい展開にはすごく興奮してるよ。
Taylor)
そうだね、Cloudには、みんながまだ考えていないような面白いユースケースがあると思うんだ。
例えば、自分のAWSアカウントで本番アプリをForgeやVaporのようなもので運用しているかもしれないけど、Cloudにサインアップしてプレビューのデプロイやステージング環境だけを使うこともできるんだ。
これはすごくシンプルで、ステージング環境を素早く立ち上げられるし、ハイバネート(休止状態)も使えるからね。
だから、Cloudを大きなステージング用のプレイグラウンドとして使いながら、本番アプリは自分のAWSアカウントで運用する、というような少し異なるセットアップが可能なんだ。
だから、みんながどのようにこれらのプロダクトを組み合わせて使うかを見るのが楽しみだよ。
https://cloud.laravel.com で公開したアーリーアクセスプログラムの一環で、今年後半に興味深いユーザーたちをプラットフォームに招待して、何がうまくいってるか、何が好きか、何が嫌いかのフィードバックをもらいたいと思ってるんだ。
だから、すごく楽しみだよ。
Laravel Cloud - 料金
Matt)
それは本当に楽しみだな。
ちょうどいい流れだから聞くけど、料金についての質問があったんだ。
「computeが1時間あたり1セントで、Postgresが1時間あたり4セントだって聞いたんだけど、じゃあどのくらいの時間になるの？」ってね。
ずっと稼働している事を前提にすると28ドルとかになるのかな。
僕の考えでは、ハイバネート（休止状態）をみんな魔法みたいに感じているんじゃないかな。
だって、もし自分のシステムが24時間ずっと使われているような大規模なものなら、28ドルに対して不安を感じることはないと思うんだよね。
でも、もしそれがたまにしか使われないようなものなら、稼働率は10％以下なんだよね。
で、本当にハイバネート中って、サービスに対して一切料金が発生しないの？
Taylor)
computeに関して言うと、アプリがハイバネートしているときは料金が発生しないよ。
データベースに関しては、コンピュートの料金はかからないけど、ディスク上に1ギガバイトのデータがあるなら、月に75セントの料金がかかるんだ。
Matt)
月単位の話なの？
75って何のことか気になってたんだ。
Taylor)
1ギガバイトあたり月75セントっていうのが、現時点での考えだね。
computeの料金は1時間1セント「以下」から始まるから、24時間稼働してる場合はもう少し安くなると思うよ。
最小のcomputeインスタンスなら、月にだいたい5ドルくらいになるんだ。
だから、Digital Oceanの一番小さいインスタンスと同じくらいの価格だね。
でも、ステージング環境のアプリだったら、ほとんどの時間は稼働してないことが多いよね。
Matt)
確かにそうだね
Taylor)
そうなんだよ。
予期しないトレードオフもあるけど、僕たちはconputeの便利さや、データベースの統合がどれだけ便利か、そして各環境のデプロイがどれだけ簡単かっていう点で、Laravel Cloudをとても魅力的なものにできると思ってるんだ。
Matt)
僕もまったく同感だよ。
最初にこの話を聞いたときは、ちょっと不安になったんだ。
なんというか、「このサイドプロジェクトにはVPSを使って、このサイドプロジェクトにはForgeを使って、プロダクション用はLaravel Cloudに移す」みたいな感じになって、確かにクールだけど、行ったり来たりするんじゃないかって思ってたんだ。
でも僕の理想は、もしプロダクションでLarvel Cloudを使うなら、ステージングでもLaravel Cloudを使うってことなんだよね。
で、ハイバネート付きの料金について聞いたとき、これはもう決まりだなって思ったよ。
自分がこんなこと言うなんて信じられないけど、本当にそう感じたんだ。
Taylor)
そうだね、それが実はLaravel Cloudで僕にとって一番重要だった部分なんだよね。
面白いことに、そのアイデアは結構カジュアルに生まれたんだ。
数ヶ月前、僕は「みんながForgeではなくCloudを選ぶ理由はあるだろうか？」ってちょっと心配してたんだ。
それで僕たちのSlackスペースに「もしアプリが動いていないときにスリープ状態にできるならどうだろう？」ってメッセージを送ったんだ。
Herokuにも似たような機能があって、エコプランとかでアプリをスリープ状態にできるんだ。
彼らはそれを強制することもあるみたいだし。
僕がその機能を本当に欲しいと思ったのは、サイドプロジェクトにおいて、これが一番の優先事項だったからなんだ。
何も考えずにLaravel Cloudにデプロイできるようにしたかったんだよ。
「今は自分しかアクセスしてないし、特に外部からのアクセスもないけど、laravel.cloudのURLがあれば友達とかにシェアするのに便利だし」って感じでね。
コンピュートとデータベースの両方でスリープできるようにして、これをLaravel Cloudにデプロイするのは当たり前の選択になるようにしたかったんだ。
実は今はデータベースの方がコンピュートよりも早く起動するんだ。
アプリケーションがハイバネート中にリクエストが来ると、大体4、5秒くらいで起動するんだよね。
だからコールドスタートで、その最適化にはまだあまり時間をかけれていないんだ。
もっと改善の余地があるかもしれない。
でも、Laravelで何かを作るときは、Laravel Cloudにデプロイして、コンピュートのコストとかについて心配しなくていいようにしたかったんだ。
そんな感じだね。
Laravel Cloud - DB
Matt)
それはいいね。本当に楽しみだよ。
ところで、Suggest.ggのメンバーの一人が、「Postgresを選んだみたいだけど、MySQLじゃなくてPostgresにしたのは新しいデフォルトになるってこと？それともたまたまPostgresの実装が先に進んでるだけなの？」って言ってたんだけどどうかな？
Taylor)
実際のところ、たまたまPostgresの作業が先に進んでいただけなんだよね。
これは僕のプレゼンのメモにも書いてあったんだけど、話してるときっていろいろ頭の中を駆け巡ってるから、つい飛ばしちゃったんだ。
だから実際は、MySQLについても深く取り組んでるんだ。
でも、今のところMySQLのソリューションはPostgresみたいなサーバーレスじゃなくて、もっと固定サイズの伝統的なMySQL提供になる予定なんだ。
まだ詳細については固まってないから、どんな感じになるか、どれくらいのコストがかかるかとかはまだ分からないけど、とにかく取り組んでいて、MySQLとPostgresを両方ローンチ時に提供することを目指してるよ。
ただ、Postgresの方が作業がかなり進んでいただけなんだ。
それに、Postgresにはまだデモで見せていない機能もあるんだよね。
データブランチングとかレプリカができるんだ。
ステージ上で見せるにはまだ準備が整ってなかったんだけど、Postgresではたくさんの機能があって、取り組んでいるところだよ。
Matt)
それで例えば、新しいブランチがあるときに、Laravel Cloudではドロップダウンで簡単にブランチを紐づけてデプロイできるような感じだったと思うんだけど、
DBもそのブランチに応じた設定を適用できるってことでいいんだよね？
Taylor)
うん、まさにそうだよ。
しかも、選択肢がいくつか用意される予定なんだ。
例えばプレビュー用のデプロイを行うときに、ステージング用のDBをすべて紐づけるのか、それともデータなしでデプロイするのかを選べるようにすることを考えているんだ。
みんな、それぞれのやり方やシーダーを使った戦略があるからね。
だから、Laravel Cloudにはいくつかのオプションや設定があって、それを整理して提供する予定なんだ。
これが今までのやり方に比べて、かなり大きいアップグレードになるんじゃないかと思ってるよ。
Matt)
そうだね、100%同感だよ。
あと、多くの人からシステムのインフラに関して質問が来たんだ。
その中の一つが、「もし自分のデータベースがすでにAWSで稼働している場合、そのデータベースを持ち込んでファイアウォールの内側に置くことができるのか？」という質問だったんだ。
それで「これはAWS上で動いているのか？」っていう質問にもつながってきたんだよね。
君がどこまで話せるのか分からないけど、例えば誰かが既存のデータベースを持っているとしたら、それを接続できるのかな？それともすべてCloudの中で新しく立ち上げるべきなのかな？
Taylor)
僕たちの目標は、自分のデータベースを持ち込めるようにすることだよ。
それは他のサードパーティのデータベースプロバイダーを使っても可能だ。
例えば、MySQL用にPlanetScaleを使うといった感じのやつだね。
もちろん、Laravel Cloudでもそういったものを使えるようにする予定だよ。
Laravel Cloudは現在、AWSのインフラ上で動いているよ。
理由はただ単に多くのサービスが存在している場所だと感じているから。
他の人たちが使う理由と同様にね。
Matt)
うん、完全に同感だよ。
Taylor)
そう。だからLaravel CloudはAWS上で動いているんだ。
そして、僕たちの目標は、ユーザーが自分のデータベースを使えるようにすることだよ。
中には非常に高度なプライベート環境をデータベースに設定している人もいるから、それぞれの状況によることは少しあるとは思うけど、ユーザーが僕たちが提供するものに縛られることがないというのが
確かな目標だよ。
Laravel Cloud - Redis, S3
Matt)
なるほど、それは本当にすごいね。
手短に聞くけど、「Redisもファーストパーティーの機能として提供される予定はあるの？」って質問もいくつか来てたんだ。
Taylor)
うん、私たちが取り組む予定でとても優先度が高いけど、デモで見せなかったものがいくつかあるね。
Redisはキャッシング用としてその中の一つだね。
それにS3のようなファイルストレージに関しても何もデモで見せてなかったけど、これも大きな項目なんだ。
これらは実際、Laraconの後に取り組む短期ロードマップの中で最も大きなものの二つだね。
MySQL関連や、Postgresの機能をさらに充実させることも含めて、本当にたくさんのことを進めているんだよ。
こういうプロダクトを作るには膨大な作業が必要で、この6ヶ月でどこまで進んだかを考えるとすごいことだと思う。
でもまだやることはたくさんあるよ。
クラウドプラットフォームをゼロから作り直しているようなもので、アプリケーションのあらゆる部分について考えなきゃいけないんだ。
でもそういったことに取り組んでいるし、公開時にはそれらの機能を提供するのが目標だよ。
Laravel Cloud - カスタムドメイン
Matt)
いいね、それは気に入ったよ。
で、これが最後の質問になるかもしれないんだけど、何人かの人がCloudFlareのカスタムドメインについて聞いてたんだ。
例えばドメインを既に別の場所で管理している場合、すべてのドメインをCloudFlareに向ける必要があるのか、それとも特定のドメイン（例えばAレコードとか）だけをCloudFlareに向けることができるのかっていう質問なんだけど、その辺りの詳細について知ってる？
Taylor)
うん、全部のドメインをCloudFlareに持ってくる必要はないよ。
Laravel Cloudに向ける必要もない。
必要なレコードをこちらから提供するし、そのドメインを実際に所有していることを確認するために追加すべきレコードも提供する。
それから、僕たちのインフラに向けるために追加するレコードも教えるよ。
実は、Laravelは今独自のIPブロックも持っているんだ。
Matt)
それはすごいね。
Taylor)
うん、大変だったよ。
視聴者にその道をたどったことがある人がいるかどうか分からないけど、IPアドレスのブロックを購入するのは複雑で時間がかかるんだよ。
IPのレピュテーションや普段は考えなくていいようなあらゆることを気にしなきゃならないんだ。
僕たちはその過程を今年の初めにすべて経験して、Laravel CloudのDNSレコードをどこに向けるべきかを案内できるようになったんだ。
Outro
Matt)
それは本当に素晴らしいね。
もう充分カバーできたかなと思うけど、今日話したいことでまだ補足できていないこととか、メモに書いてあったのに話せなかったことってある？
Taylor)
MySQLの話は大きなポイントだったね。
これは僕のプレゼンでスキップしてしまったけど、かなり重要な点だった。
他には、Laravel Cloudのウェイティングリストに登録してほしいってことかな。
もし、Laravel Cloudのアーリーアクセスパートナーとしてぴったりなアプリがあると思ったら、僕にメールを送ってほしい。
新しいアイデアに取り組んでいる人や、既存のプロジェクトを持っている人、インディーハッカーから大企業に至るまで、幅広い顧客を求めているんだ。
ぜひ、あなたからの連絡を待っているし、一緒にこのプロダクトを作り上げていきたいと思っているよ。
Matt)
素晴らしい！
忙しい中、時間を取ってくれて本当にありがとう。
僕たちはこれにとてもワクワクしているよ。
ありがとう、Taylor。
Taylor)
こちらこそありがとう。
Matt)
それでは、また次回お会いしましょう。