今、オレの心を震わせるツールやサービスたち…ッ!!!～2024冬～
RUNTEQ Advent Calendar 20245日目の担当はこのオレさァ…。
今、オレァ震えてるぜェ…！
なんてったってよォ、今この世にはよォ、イカしたツールやサービスの野郎どもがよォ、世界各地で毎日パレードしてっからよォ…！
毎晩毎晩一千一夜、オレのソウルがダンスっちまってしょうがねェんだよォ…！
最近のオレの心を踊らせるイカしたヤツらを紹介するぜェ…。
Lamby
こいつァAWSのLambdaちゃんにRuby on Railsのデプロイを、イカした感じにサポートしてくれるやつさ。
Quick Startを見る感じ、Lambyちゃんを使えばあっちゅう間にRailsをLambdaにデプロイできそうだろォ？
そもそもなんでLambdaにデプロイしてェかって話だよな？
Lambdaにデプロイできたら何が嬉しいんだてめェは、ってな。
そらもちろん、安いからに決まってんだろォが。
なんてったてLambdaは毎月100万件リクエスト無料だかんな。
みなし残業100万回ってところだ。
意味分かんねェよな？
オレが知る限りだとランタイムがNode.js以外の場合は、無料かつ長く運用できる実行環境ってのが中々無ェんだよな。
オレん中だと、
- Fly.io
- Render
- Koyeb
が無料デプロイ三銃士なんだけどよォ、いずれも無料枠に収めようとするとリージョンやデプロイできるアプリの数に制限があんだよな。
それを踏まえるとデプロイ先としてLambdaの野郎が光り輝いて見えて目がくらむだろォ？
オレには見えるぜ。
Lambyが、この芽も出ねェ腐った大地を極彩色のダンスフロアーに変える、お月さんよりでっけェミラーボールにな…。
Vercel on Rails
前のLambyと続く話じゃあるが、VercelにRailsをデプロイできるみたいだぜ。
Vercelと言えばNode.jsランタイム環境の百万石藩だと思ってたんだがよォ、この野郎RubyはおろかGo、Pythonたちもサポートしてるじゃねェか。
調べたらVercelにRailsやDjangoをデプロイしてるアニキたちがいたぜ。
大抵のフロントエンドのフレームワークに比べて、RailsやDjangoとかのフルスタックなフレームワークは動かすのに諸々とリソースが要りそうだかんな。
だからNext.jsをVercelにデプロイする感覚だと、フルスタックフレームワークたちじゃ想定より早めに無料限界に到達しちまうかもしれねェ。
ただよォ、「AWS破産」とか「クラウド破産」ってェ言葉があるように、AWSなりGoogle Cloudに手ェ出すときはちっと足がすくんじまうよな。
オレだって昔、AWSの野郎と対峙して少しだけ漏らしちまった過去がある。
だったら勇気をもってAWSやGoogle Cloudから逃げちまっていいと思うぜ。
きっとVercelが母ちゃんのように抱きしめてくれるだろうさ…。
Cloudflare
最近の野郎どもはどいつもこいつもCloudflareを前にして、舌とヨダレを垂らして尻尾を振ってるように見えるぜ。
そしてもちろん、オレもこいつに首ったけさ！
なんてったって今のCloudflareってやつァ、
- DB
- ストレージ
- KV
- サーバーレス関数
- ホスティング
- ドメイン管理
- ログ
とか何でもあるんだぜ。
Cloudflareのダッシュボードを見てくれよ。
ハッキリ言って、何に使うか分かんねェもんばっかだぜ！
多機能さでAWSとかGoogle Cloudとタイマンして勝てんのか？って話で言えば、Cloudflareにとって厳しい戦いになっちまうだろうぜ。
だけどよォ、誰もがCloudflareを前にしてワン公になっちまうのにはワケがあるのさ。
そいつァ安さだ！
Cloudflareのアニキは多機能かつ激安だから、みんな犬っころになっちまってると思うんだ。
具体的にどんだけ安いのかは正直言ってオレァ知らんが、大勢がヘルメットとマスクして軍手を装備した手で看板を掲げながら「安い！安い！」って合唱してっから、オレもしれっとその群衆に紛れて分かった面して「安い！安い！」って叫んでんのさ。
特にCloudflare R2っていうストレージがやべェらしいぜ。
例えばXで「cloudflare R2 コスト」とか「cloudflare R2 無料」とかで検索すると、みんなが叫ぶ理由が分かんじゃねェかな。
エンジニアリングツール界のドン・キホーテみてェだな。
ただ、現時点でDBはトランザクションできねェらしいから、品揃え的な観点で言えば多機能ではあるが、商品の一つ一つは他所と比べると多機能じゃねェみてェなところはあるっぽいぜ。
Firebase Data Connect
FirebaseでPostgreSQLが使えるみてェだぜ。
Firebaseにゃ既にRealtime DatabaseとFirestoreっちゅうNoSQLのDBがあるが、これに加えてRDBも使えるようになるわけだ。
つまりかつて起きてた「Firebaseさえあればなんでも作れるやんけ！」「NoSQLじゃ話ならんわ！」みてェな戦争は終わるわけだな…。
あとは「NoSQLでよければFirebase、RDBが欲しければSupabase」みてェな使い分けの必要も無くなるかもしれねェ。
開発できるヤツ、かつ技術的な構成はどうでもよくてグロースに注力してェ、みたいな野郎にとっちゃァ1つのサービスやツールやフレームワークなりでシンプルに開発をまかなえられんのは魅力的に見えるよなァ？
Firebase Data Connectは今はパブリックプレビューって段階で、実質無料で使えるみてェだ。
とはいえ一般公開のステータスになると、Cloud SQLの費用に震えちまうかもしれねェ…。
Supabaseとか
機能全部お届けセット系サービスでFirebase以外の筆頭って言えば、Supabaseのアニキだよなァ？
XにいらっしゃるSupabaseの中の人の負担になっちゃァいけねェから大きな声では言えねェが、XでSupabaseに関する感想やリクエストや疑問をポストすると、その人が応えてくれるときがあるぜ。
某新進気鋭フレームワークにコードの例を添えたIssueを投稿したものの何の反応も得られなかったオレからしたら、Supabaseアニキのような対応をしてもらっちまったら「アニキぃ！一生ついていきやすぅぅ！」ってなっちまうよ。
ここまで書いといてなんだがオレァまだSupabaseを使ったこと無ェし、XでSupabaseに関するポストはしたこと無ェんだがな。
使う予定はあるから、今オレの眼はSupabaseを捉えて離さなねェのさ。
Supabase的なヤツは他にも色々あるみてェだぜ。
前述のFirebase Data Connectの項に書いたことと重複すんだがよォ、技術的な構成に対する執着が薄ければ、こういったFirebase的な開発に必要な機能をマルっと提供してくれるツールを使うのがいいと思うぜ。
かくいうオレは最近そういう思想に近づいていってから、こういったFirebase的なサービスに対する関心が高まってんのさ。
ついでに言うと、こういったサービスたちってのは概ね無料枠があるからな。
金額の多寡は関係なしに、固定費が掛かっちまうのはイヤだろォ？
世間で忌まわしく怖れられていて夏場にたまに目にする黒光したGなんかより、毎月毎年必ず目の前に現れる数字でできた赤いKの方がよっぽど怖ェぜ。
Gatsby.js
こいつに関しちゃ、期待や興奮や嬉しさで震えてんじゃねェ。
悲しみで震えてんだ…。
オレはかつて、Gatsbyの野郎のことを気にかけていたんだ。
だがそれも過去形さ。
なんてたってGatsbyは、あの世へ実質的に逝っちまったからな…。
GatsbyはNetlifyに買収された後、Gatsbyを作ったヤツらは解雇されて、2023年12月からGatsbyの更新は長らく止まっちまった。
そして2024年11月に約1年ぶりのアップデートがあったが、このコメントの特に最後が指摘する通り、Gatsbyがもう帰って来ねェことをみんなに実感させることになっちまったのさ。
かつてGatsbyはNext.jsと峠を舞台に、時ににらみ合い、時に肩を組み合い、血を血で洗うデッドヒートを繰り返していた。
NextはGatsbyを見てSSGに手を拡げ、GatsbyはNextを見てSSRやGatsby Cloudまで足を伸ばした。
そんな日々もある時、まるで今まで何事も無かったように終わっちまうんだ。
今のGatsbyは厳密に言えば終わっちゃいねェ。
公式は引き続きがんばるぜ的なことを言っている。
だが「そうか、じゃあちょっと期待しちまうなァ」と言っちまうような状態には見えねェ。
昔よく行ってた店が閉店を発表したような雰囲気が、または賑わっていた跡を想像させる街の香りが、Gatsbyの世界に漂っている気がするぜ…。
あんま関係ねェ話だが、2024年の3月ぐらいだったかに発表されたAstro Studioが、同年9月にサ終を発表した。
GatsbyやAstroみたいに、一時代に一界隈で名を上げたり現在も一部分で輝いているヤツらも、気づけばコースアウトしていたりキズを負ってるのさ。
かたや「オワコン」と風物詩のように評されると同時に定期的にアップデートされているものはごまんとあるし、「オワコン」と言われてマジで終わったものもあるだろうぜ。
いつまでも、あると思うな、親と金、とライブラリとフレームワークとツールとサービスってことだ。
Pagefind
Pagefindは全文検索ライブラリだぜ。
Pagefindで実装された検索フォームを備えたサイトやブログで使ってみたら分かるが、結構速ェし、検索したいキーワードを入力してる最中に、キーワードに一致する結果を表示してくれる。
こいつァサイトをビルドする際に検索対象となる辞書データを生成するみてェだから、静的なサイトにピッタリな代物さ。
ただ、オレがPagefindに心を震わせてるのはそこじゃねェ。
オレは動的なサイトでもこれができねェかって期待して震えてんのさ。
具体的なやり方は分かんねェがイメージはかつてのNext.jsのISR的に、Pagefindで必要なビルドプロセスを定期的に実行して、定期的に辞書データを生成できねェかと夢想してんだ。
そんでこれができれば、DBの選定とか検索対象のカラムの追加とかが柔軟にできるんじゃねェかとニヤニヤするわけさ。
例えばユーザーが投稿したデータを検索結果に即時に表示することはできねェが、投稿したてのデータが検索結果に出てこねェ巷のサービスってそこそこある気がするし、前述のメリットがあるなら検索結果の即時反映は妥協できるだろォ？
って考えてたんだが、サイトやアプリとは別で辞書データ用のビルドを実行して、生成された辞書データを検索時に参照する、みたいな仕組みを作れる知識なり経験なり技術があるんだったら、Pagefindを使う必要は無ェかもな。
それかビルドを別にすることなく、辞書データ更新のタイミングで全体をビルドしちまってもいいかもしれねェ。
オレァ昔Next.jsのISRを使って、プライベートフォルダに置いたjsonを定期的に読み書きする処理を実装したことがあってなァ。
CMSで管理している特定のコンテンツの更新日時が、jsonに記録した前回更新日時より新しければ、jsonの前回更新日時を更新するとともに、特定の処理をするって感じだった。
その要領でユーザーによってデータの追加や更新がされたら辞書データを更新する、みたいな処理ができねェかと思ってな。
Kuroco
国産Headless CMSの二強と言えば、microCMSかNewtだよなァ？
オレァどっちも使ってるが、どっちも最高だぜェ。
microCMSはAPIでCRUDできるんでDBとかストレージとして使えるしなァ、Newtは無料プランで画像以外のファイルを管理できんのとフォームをカンタンに設置できる機能を提供してるぜェ。
だがしかしよォ、国産Headless CMS大戦にもう一人の野郎が参戦してきやがったぜェ…？
そいつァ「Kuroco」だ！
ちなみにだがKurocoのご先祖様となるCMSは2006年にリリースされて現在も稼働中だぜ。
Kuroco家は代々CMS大戦に参戦していた、由緒あるCMS一家なのさ。
KurocoがmicroCMSやNewtと違ェのは多機能さだぜ。
Kurocoのダッシュボードで確認できる項目を見てくれよ。
AIとかKurocoFontとかキャンペーンとかECとか、他のCMSには無い項目があって何ができんだか気になんだろォ？
オレァKurco使ったことねェんで、コイツらが何ができんだか嚙み砕いて説明できねェぜ！
あと大きな違いの一つに料金体系が先の二つと全然違ェ。
microCMSとNewtはプランごとの定額課金制だが、Kurocoは従量課金制だ。
microCMSとNewtと同じ使い方して、Kurocoの方が高くなるのか安くなるのかは分かんねェがな。
オレァHeadless CMSを使う予定があるんで、そんときにKurocoを使って人柱となって結果をみんなにシェアしてやんよ。
いずれな。
ブラウザ
ブラウザってのはオレたちの想像の範疇を超えるぐれェ、色んなことができるぜ！
そんでもってこれからも、できることは増えてくだろうぜ。
例えばプレステのゲームが遊べたりよォ、フォトショやDAWやボカロエディタやARやVRが使えたりよォ、動画編集やプログラミングができたりよォ、なんかよく分かんねェけどインタラクション付きストーリーテリングを表現できたりよォ、なんでもアリだぜ！
ブラウザで諸々を賄えるようになると、個々のソフトのインストールとかアップデートをする必要が無くなっていいよな！
特にWasmっちゅうよく分かんねェ技術によって、今までできなかったことができるようになってきそうだぜ。
フォトショがブラウザで使えるようになったのも、Wasmのダンナが一役買ってるみてェだ。
オレァffmpeg.wasmを使って、作りてェアプリがあって注目してんだ。
ブラウザでffmpegが使えると、APIのタイムアウトとか一時保存領域のサイズの制限とかを取っ払えそうなんでなァ…。
HTMLやCSSの粒度の話だと、オレァfield-sizing: contentやinput type="checkbox"のswitch属性対応が全ブラウザで使えるようになるのを楽しみにしてるぜ。
Discussion