"use cache"は、Next.jsのDynamic IOで利用することができる新たなディレクティブです。本稿は筆者の備忘録を兼ねて、Dynamic IOの成り立ちや"use cache"の内部実装について解説するものです。 Dynamic IOの成り立ち Dynamic IOは2024年10月のNext Confで発表された、Next.jsにおける新しいコンセプトを実証するための実験的モードです。Dynamic IOはその名の通り、主に動的I/O処理に対する振る舞いを大きく変更するものです。 具体的には、以下の処理に対する振る舞いが変更されます。 データフェッチ: fetch()やDBアクセスなど Dynamic APIs: headers()やcookies()など Next.jsがラップするモジュール: Date、Math、Node.jsのcryptoモジュールなど 任意の非同期
こんにちは。 Findy Toolsの開発をしている林です。 私たちのプロジェクトではフロントエンドのフレームワークにNext.js App Routerを使っており、AWSのECSへデプロイして運用しています。 そして、一部のレンダリングの処理が重いページのキャッシュを実装する際に、直面した課題と解決策を紹介します。 Next.jsのキャッシュ機構について 今回実現したいこと 課題と解決策 課題1: Next.jsの機能では要件に合わない 解決策1: CloudFrontのみでキャッシュ 課題2: エラーページがキャッシュされる 解決策2: Lambda@Edgeを用いたCache-Controlヘッダー制御 まとめ Next.jsのキャッシュ機構について まず、Next.jsのキャッシュ機構について簡単に説明します。 Next.jsではサーバサイドで使えるキャッシュ機構が次の3種類あり
Next.js の "use cache" ディレクティブによるキャッシュ制御 2024.11.02 Next.js の App Router はデフォルトでキャッシュされる設計でリリースされました。一方でデフォルトでキャッシュされることに対して不満を持つ開発者も多かったように思います。このようなフィードバックを受けて、Next.js 15 ではいくつかのキャッシュ戦略が変更されました。さらに現在 canary チャンネルで提供されている dynamicIO フラグを有効にすることで、"use cache" ディレクティブを用いてキャッシュを制御できるようになります。 Next.js の App Router では最もパフォーマンスの高いオプションで提供されるために、デフォルトでキャッシュが有効になっており、必要に応じてオプトアウトする設計でリリースされました。例えば global fet
Cloudflareが@opennextjs/cloudflareを発表 2024年9月末に開催された「Builder Day 2024」でNext.jsアプリをCloudflare Workersにデプロイする新たな方法が公開された。 この方法は、@opennextjs/cloudflareを使ってビルドする。既存の@cloudflare/next-on-pages方式を置き換える可能性があり、現在は実験的な段階だ。 以下に新旧の開発手順のドキュメントがある。 新(opennextjs): Next.js | Cloudflare Workers docs 旧(next-on-pages): Get started | Full-stack (SSR) | Next.js apps OpenNextの概要 OpenNextは、Next.jsアプリをVercel以外のインフラにデプロイでき
こんにちは！プロダクトエンジニアのshiraです。 2024年6月にリリースした採用管理機能の開発をしています。 support.smarthr.jp 採用管理機能ではNext.jsのApp Routerを採用しています。SmartHRではこれまでApp Routerを使ったプロダクトがない状態だったので、技術選定時は採用するか迷いました。 この記事ではApp Routerを採用するまでの経緯と採用してみてどうだったかについて紹介させていただきます。 Pages RouterとApp Routerについて まずはじめにPages RouterとApp Routerについて軽く説明します。ご存知の方は読み飛ばしてください。 2024年9月現在、Next.jsのルーティングシステムは2つ用意されています。それがPages RouterとApp Routerです。 Pages RouterはNe
17年周年のWebアプリケーションにTanStack Queryを導入する / Implementing TanStack Query in a 17th Anniversary Web Application
目次 はじめに Colocation を意識した設計方針 Parallel Routes と Intercepting Routes を用いた設計パターン サーバー側に処理を寄せたことによる恩恵と課題 Next.js が抱える課題 おわりに 参考文献 はじめに ジャンプTOON のWeb版（以降、ジャンプTOON Web）の開発を担当している浅原昌大（@assa1605）です。 5 月にサービスを開始した「ジャンプTOON」は、オリジナル縦読みマンガ作品や人気作品のタテカラー版を連載する、ジャンプグループ発の新サービスです。 ジャンプTOON のフロントエンドには、Next.js を採用し開発をしています。 本記事では、Next.js の最新機能や設計パターン、Next.js を採用した恩恵と現在の課題について紹介します。 Colocation を意識した設計方針 Parallel Rou
先日、Next.jsの新たなレンダリングモデルであるPartial Pre-Rendering(以降PPR)について記事を投稿しました。 この記事を書いてる時は意識してなかったのですが、感想でアイランドアーキテクチャに言及されるケースが散見されました。社内で上記記事の話題になった時も同様に、アイランドアーキテクチャとの違いについて問われました。 結論から言うと、PPRとアイランドアーキテクチャは全く異なるものです。本稿ではPPRとアイランドアーキテクチャの違いについて解説します。 PPR まずはPPRとアイランドアーキテクチャの概要を改めて整理しましょう。 PPRはページをstatic renderingとしつつ、部分的にdynamic renderingにすることが可能なレンダリングモデルです。具体的には、画面をbuild時(もしくはrevalidate後)に静的生成しつつ、リクエスト毎
Next.js AppRouterで利用できるReactのServer Actions機能。クライアントからサーバ上の処理を関数で呼び出せるので非常に便利ですが、 "use server"; のことをあまり知らず、誤った使い方をすると意図せず公開したくない関数が外部に公開されてしまうケースがあるので注意です（ほとんどこんなケースはないと思いますが、なくはないので注意喚起です）。 Server Actionsの例 Server Actions用の関数として宣言するためには "use server"; が必要です。それ以外は至って普通の非同期関数で大丈夫です。 "use server"; export async function someAction() { return { message: "Server Action", }; } 次に定義したServer Actionsの関数を呼び出
こんにちは。sumirenです。 イントロダクション 先日、Twitterで以下のポストが話題になっていました。 一部曖昧なところもありますが、推測と動作検証結果も交えて要約すると、以下のことを言っています。 VercelがホスティングしているWebサイトは、エッジでのサーバーサイド処理を行うことをやめた Next.jsに関して、VercelでPPR(Partial Prerendering)を利用した場合、サーバーサイド処理はNodeランタイムで行われる この記事では、このポストに絡めて、PPRとエッジに関する筆者なりの所感や解説を述べていきます。この記事の大部分はポエムですが、一部、技術的な事実についても述べるつもりです。そうした部分について誤りがあればご教示ください。 Vercelがエッジでのサーバーサイド処理を行うことをやめた件について エッジの効能 そもそもエッジに期待していたこ
本稿はNext.js v15.0.0-rc.0時点の情報を元に執筆しており、PPRはさらにexperimentalな機能です。v15.0.0のリリース時や、PPRがstableな機能として提供される際には機能の一部が変更されてる可能性がありますので、ご注意下さい。 Partial Pre-Rendering(以降PPR)はNext.js v14.0で発表された、SSRやSSGにならぶ新たなレンダリングモデルです。 PPRは前述の通り開発中の機能で、v15のRC版にてexperimentalフラグを有効にすることで利用することができます。ppr: trueとすれば全部のページが対象となり、ppr: "incremental"とすればexport const experimental_ppr = trueを設定したRouteのみがPPRの対象となります。 // next.config.mjs
React Compiler React 19 Beta から React Compiler が導入され利用可能となりました。 ※単体での検証としては次の記事が参考になります。 Next.js での利用 React Compiler のドキュメント内には、各種バンドラやフレームワークで利用する方法も記載されています。 というわけで、Next.js で実際に試してみよう、というのがこの記事の主旨です。 事前準備 / セットアップ 基本的にドキュメントに従って進めます。注意点としては、執筆時点での Next.js の Stable バージョン 14.2 ではまだ React 19 が利用できないため、canary バージョンの利用が必要です。 適当なディレクトリを作成し、その中で create-next-app を実行します。 実験用のためオプションは適当に選択しますが、せっかくなので Tur
2024 年 5 月現在だと Next.js のドキュメントには明示的な記載がないが、「同時に実行可能な Server Action は常に１つだけ」という件について。 実は自分もこれをちゃんと認識しておらず、先日会社の先輩に教わって初めて知ったので、試したことなどを書き残しておく。 Next.js の場合、App Router (Router Reducer) によって、Server Action の実行が直列化 (キューイング) されるようになっている。 このキューイングの挙動を考慮すると、以下のような呼び出し方は危ういコードとなる。 "use client"; import { useState } from "react"; import { increment } from "./actions"; export default function Page() { const [
Next.jsでSSRF（=Server Side Request Forgery）の脆弱性が発覚したことが社内で話題になったので、まとめておこうと思います。対象の脆弱性は以下です。 脆弱性の概要 SSRF脆弱性は本来到達できないサーバーに対して、公開されてるサーバーを経由してアクセスすることができてしまう脆弱性です。 今回のNext.jsの脆弱性はhttpヘッダーのHostを書き換えることで、self hostingなNext.jsサーバーから任意のhttpリクエストを送信できてしまうというものです。これは、外部には公開してない内部APIに対するリクエストも可能になるため、SSRF攻撃になりえます。 今回の脆弱性の対象は、以下の条件を満たしている必要があります。 Next.jsをself hostingで運用している Next.jsアプリケーションがServer Actionsを利用して
このブラウザ バージョンのサポートは終了しました。サポートされているブラウザにアップグレードしてください。
東京Node学園 42時限目の App Router Panel Talkです。
ちょっとした React Server Component 小ネタ。 Next.js (webpack, Turbopack) で確認しているが、おそらく RSC に対応しているツールであったらどれも変わらないはず。 アプリケーションの package.json の imports セクションに以下のように記載しておく。util の部分は好きな文字列で構わないが # から始めておくこと。 { "imports": { "#util": { "react-server": "./src/util.react-server.ts", "default": "./src/util.default.ts" } } }React Server 環境とそれ以外の環境用、それぞれの実装を用意する。 とりあえず結果が異なることを確認したければ以下のような感じ。 /* ./src/util.default.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く