一休レストランで Next.js App Router から Remix に乗り換えた話 / Migration from Next.js App Router to Remix
![一休レストランで Next.js App Router から Remix に乗り換えた話 / Migration from Next.js App Router to Remix](https://cdn-ak-scissors.b.st-hatena.com/image/square/bcb8d1a4576b9731b45096ad3cfb6dc90c40fd51/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fd6d2fc40e0504e858a7af6effca8e542%2Fslide_0.jpg%3F28638246)
先日、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 は常に1つだけ」という件について。 実は自分もこれをちゃんと認識しておらず、先日会社の先輩に教わって初めて知ったので、試したことなどを書き残しておく。 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を利用して
ちょっとした 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.
Next.js のv13.1.0で追加されたskipTrailingSlashRedirectを使うことで、 trailing slash に関する挙動を自由に設定できる。 この記事では、skipTrailingSlashRedirectによって具体的にどのようなことが可能になったのかを見ていく。 動作確認はv13.1.1で行った。 環境構築 まずは Next.js の環境構築から。 $ yarn create next-app sample --ts こうするとsampleというディレクトリが作られるので、そこに移動して作業を進めていく。 まず、next.config.jsのbasePathに"/app"を指定する。 /** @type {import('next').NextConfig} */ const nextConfig = { reactStrictMode: true, b
App Router でトラディショナルな動的 SSR 既存〜今後のコンポーネントの互換性を踏まえて React を前提とし、フレームワークの分散を抑制するため Next.js を選び、多少の冒険ではあったが App Router での開発にトライしています。 今後は現在 Ruby on Rails のモノリシックコードベースで展開されている複数プロダクトを分割し、それぞれを Next.js で水平展開し直していくイメージです。 で、まずは App Router のフルパワー(サバクラに渡る重厚なキャッシュ機構)を要しない、ログインする操作こそあれだページの9割9分が Server Components としてレンダリング可能な領域をリプレース中。 つまり // app/layout.js export const fetchCache = 'default-no-store'; expo
Progress towards 100% of tests passing for Turbopack in Next.js
Next.jsを初心者向けツールとして捉えている自分が、実践 Next.js を読んでみて2024-03-28 この記事は 実践 Next.js の書評です。 見本誌を頂いた上での記事です。(PR記事?) tl;dr App Router のメリットを理解しつつも、学習コストに割り合わないと思っている人にオススメ!ドキュメントを読めるようになるし、学習コストが下がる。 はじめに 自分はどちらかというと今の Next.js に対しては否定的な感情の割合の方が高く、仕事で困らない程度の最低限の知識しか持っていない。 しかし、なんだかんだ勉強の必要性に駆られていて、そのキャッチアップとして同書の発売を楽しみにしていた。 そんな折に @takepepe さんから見本誌をいただいたことで、この週末に読んだので書評を書きたい。 俺は今のNext.jsが好きではない 書評を書く前にポエム書かせてくれ!
Hello, I've been working on completing and maintaining the products at the company I'm currently with, using the page router. I find great joy in creating products through the page router and, additionally, I'm excited about the possibility of server-side rendering (SSR). Utilizing features like getServersideProps allows for sufficient implementation of server-side actions. However, as I migrate t
はじめに この記事について こんにちは、 @zomysan(Twitter) です。この記事では、Next.js で開発をしているWebアプリケーションのフロントエンドを対象に、開発途中のページをどう扱うかということについて書きます。 新しい機能やリニューアルのための開発を始めてあたらしいページを追加したものの、まだ途中なのでユーザーに見せられる状態ではない、ということはよくあると思います。ユーザーには見せたくないけど、開発環境やステージング環境では確認したい。でも本番環境には出したくない。そういうときどうしたら良いのでしょうか? この記事の対象 この記事は以下のような人を対象としています。 Next.js で Web アプリケーションを実装している 開発中のページを本番環境に露出したくない まとめ 今回、私は以下のように実現してみました。 開発中のページについて、拡張子を .page.d
"LayerX、スタディサプリ、SHEと考える GraphQLが向いている現場とは?運用実践LT" で登壇した資料です。 引用した資料 [Rails アプリに RESTful API のレールを敷いて生産性が大きく上がった話 | Wantedly Engineer Blog](https://www.wantedly.com/companies/wantedly/post_articles/85098) [React Server Components と GraphQL のアナロジー | by Yosuke Kurami | Dec, 2023 | Medium](https://quramy.medium.com/89b3f5f41a01) [実質無料で GraphQL Gateway を手に入れる / low-cost GraphQL Gateway - Speaker Deck](
まずは長いものに巻かれたいときもある Offers を運営している株式会社 overflow の あほむ でございます。 先日 コードベースのディレクトリ構成にフォーカスした記事 を公開した関連記事として、Next.js App Router をどのように取り扱っているかについてご紹介します。 【AD?】今回の記事の内容を含んだり含まなかったりすると思いますが、来週 2024/01/17(水) 19:20 〜 オンライン開催の PWA Night vol.59 で発表予定なので興味のある方はぜひ。(終了済み) 下記は本記事の内容を含むイベント発表資料です。ご参考までに。 今回の前提 前回記事 の引用ですが今回も同様です。 最終目標は単体事業でありつつ実質マルチプロダクトな画面群のリプレース クライアントサイドでヘビーなビジネスロジックを持つ必要がない アプリケーション特性としては SaaS
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く