こんにちは、マイクです！今日は2024年12月14日、土曜日ですね。今週も「zenncast」をお楽しみいただきありがとうございます！今日はZennでトレンドの記事をいくつかご紹介します。
さて、前回紹介した記事ですが、今回はその内容をおさらいすることはありませんので、早速今日の内容に入っていきましょう。
まず、今日紹介する記事の本数は5本です。それでは、さっそく一つ目の記事から紹介していきますね。
1つ目の記事は「TypeScriptのコードをRustで書き直した話」です。こちらの記事では、株式会社モニクルがTypeScriptで書かれたコードをRustに書き直した経緯とその結果について詳しく述べられています。モニクルはNode.jsを使用していて、特にバッチ処理においてメモリ消費が問題になったそうです。なんと、月に数回行うバッチ処理で、1回の処理で400MB以上のメモリを消費していたとのこと。Node.jsのガーベジコレクションがメモリを解放しないため、さらなるメモリ確保が難しい状況に陥ってしまったんですね。
そこで、メモリ管理が得意なRustを選ぶことにしたわけです。Rustで書き直した結果、メモリ消費は1処理あたり400MBから全体で40MB程度に削減され、処理時間も90秒から10秒以内に短縮されたそうです。また、コンテナイメージのサイズも100MBから10MB未満に圧縮されたとのことで、非常に効率的に改善されたみたいです。ただし、Rustに移行する際には課題もあったようで、Google Cloudの公式SDKが未整備だったため、APIに直接アクセスする必要があり、Rustのビルド時間が長くなる問題もあったそうです。それでも最終的には目標を達成し、型安全性の向上も実感できたとのこと。モニクルは、より効率的で安定したサービスを提供できるようになったそうです。
。...。...。...。
2つ目の記事は「Next.js PPR と比較して理解する Astro Server Islands」です。こちらでは、2024年12月3日にリリースされたAstro 5.0の目玉機能、Server Islandsについて解説しています。特にNext.jsのPartial Prerendering（PPR）と比較しながら、Server Islandsの特徴や仕組みを掘り下げているんですね。
結論として、Server IslandsはAstro版のPPRであり、動的コンテンツの取得方法が異なることで、パフォーマンスにおいてやや劣るがポータビリティに優れているとされています。Next.jsのPPRは、リクエスト時にサーバーで静的な部分を事前レンダリングし、動的なコンテンツを同時にストリーミングするアプローチですが、Server Islandsでは静的コンテンツがビルド時に生成され、リクエスト時に動的なコンテンツを別途取得します。このため、初期表示が早くなるものの、リクエスト数が増加するという特徴があります。
Astroでは、ページ単位でのレンダリング方式の選択肢があり、PrerenderingとOn-demand Rendering（SSR）が基本です。Server Islandsは、これらの機能を組み合わせ、静的な初期表示と動的なコンテンツの柔軟性を兼ね備えています。最終的にPPRとServer Islandsは、パフォーマンスとポータビリティのトレードオフにおける異なる選択肢であり、それぞれの利点があります。これからのエンジニアリングにおいて、選択肢が増えるのは嬉しいですね。
。...。...。...。
3つ目の記事は「【2024年12月】Next.jsで新規アプリの構成と開発でのLLM活用」です。この記事では、Next.jsを用いた新規アプリの開発において、開発効率とコストを重視した構成と、LLM（大規模言語モデル）の活用方法について詳しく述べられています。
開発エディタにはCursorが推奨されていて、LLMへの質問時に過去のコードを参照できる点が評価されているそうです。また、プライバシーモードの設定もセキュリティ向上につながるとのこと。開発時の検索にはPerplexityを利用し、自然な文章で質問をすることで、より正確な情報を得やすくしているみたいです。
ページのモック作成にはVercelのv0を使い、プロトタイプを迅速に作成する手法も紹介されています。ライブラリ構成はNext.jsとVercelを中心に、SWRやtRPC、React Hook Formなどを使用していて、スタイルにはTailwind CSSとshadcn/uiが活用されています。ディレクトリ構成は機能を小さく保ち、コードの可読性を重視した設計となっています。
APIのカスタムルートハンドラーについても触れ、ESLintの設定例が示されています。外部サービスの活用を推奨し、特にAirtableやNewt、Figmaのプラグインを利用した開発の効率化を提案している点も面白いですね。Cloudflareの利用についても言及されていて、アクセス増加に伴うコスト管理やスケーラビリティの手法が説明されています。継続的なリファクタリングがNext.jsの開発において重要であると結論づけています。
。...。...。...。
4つ目の記事は「Reactのトランジションの仕組みを理解する」です。こちらでは、Reactのトランジション機能の仕組みとその実装について解説しています。特にReact 18におけるstartTransitionフックを中心に、UIをブロックせずに状態を更新する方法を探求しています。
トランジションを利用しない場合、重い計算処理が完了するまでUIがブロックされ、ユーザー体験が損なわれることがあります。しかし、トランジションを使うことで状態更新がスムーズに行われ、ユーザーが操作を続けられるようになります。記事では、トランジションの有無によるレンダリング処理の違いを、Chrome Dev ToolsのPerformanceタブを用いて分析しています。
特に、トランジションとしてマークされた場合、Reactはタスクを細かく分割して処理を行い、UIのブロッキングを防ぐ仕組みが確認されています。また、isInputPending APIについても言及されていて、これはユーザーの操作があったかどうかをブラウザから確認するためのAPIとして期待されていましたが、不安定さから採用が見送られたとのこと。現在の実装では、状態更新をトランジションとしてマークすることでタスクを細かく分割し、UIの反応性を向上させる手法が用いられています。
。...。...。...。
最後に、5つ目の記事は「Dynamic IOの成り立ちと"use cache"の深層」です。Next.jsにおける新しいディレクティブ`"use cache"`は、Dynamic IOの機能の一部として導入されました。Dynamic IOは2024年のNext Confで発表され、動的I/O処理の振る舞いを革新する実験的なモードです。
特に、Dynamic IOでは`<Suspense>`境界内での実行や`"use cache"`によるキャッシュの宣言が求められます。この仕組みにより、開発者はキャッシュ可能な処理を明示的に選択でき、従来のキャッシュの混乱を解消できるようになります。
`"use cache"`はファイルや関数の先頭に記述することで、Next.jsにキャッシュ可能なことを示すことができます。これにより、キャッシュは引数や変数を自動でキーとして認識し、不要な値は除外されます。キャッシュはオンデマンドキャッシュとResumeDataCacheに分かれ、前者はLRUのインメモリキャッシュ、後者はPrerenderからのデータを再利用するためのものです。
筆者はDynamic IOがシンプルな設計によってキャッシュの問題を解決する可能性が高いと考え、今後の開発に期待を寄せています。このようにDynamic IOと`"use cache"`はNext.jsのキャッシュ機能に新たな光をもたらし、開発者にとって使いやすさを向上させる要素となるでしょう。
さて、今日ご紹介した記事を駆け足でおさらいしますと、TypeScriptからRustへの書き直し、AstroのServer Islands、Next.jsの新規アプリ開発、Reactのトランジション、Dynamic IOと"use cache"の深層についてお話ししましたね。次回はどんな内容でお会いできるのか、私も楽しみにしています！詳しい内容はショーノートに書いてありますので、ぜひチェックしてみてください。そして、番組の感想もお待ちしています！それでは、またお会いしましょう！