Next.js の App Router を中心に解説した書籍を執筆しました。「実践 Next.js —— App Router で進化する Web アプリ開発」という本です（3/16 刊行）。本稿では書籍の概要と、App Router が何を解決するのかについて紹介します。 書籍の概要 書籍で解説しているサンプルコードは、public リポジトリで既に公開しています。前半、第 1 章〜第 4 章では App Router の基礎を抑えるための練習用リポジトリを使用します。後半、第 5 章〜第 10 章では、写真を投稿する SNS「Photo Share」という架空アプリの実践的リポジトリを使用します。 第 1 章：Next.js の基礎 第 2 章：Server Component とレンダリング 第 3 章：App Router の規約 第 4 章：Route Handler 第 5
<script nonce="xxxxx" id="initial-data" type="text/plain" data-json="${preloadedState}" ></script> このpreloadedStateはエスケープ処理が必要なので注意してください。 クライアント側の読み込み方 const initialData = JSON.parse( document.getElementById("initial-data")!.getAttribute("data-json")!, ); const { store } = configureStore(initialData); https://github.com/hiroppy/ssr-sample/blob/master/src/client/index.tsx#L21-L22 useEffect SSR では、
Next.js + React Server Component のリファレンス実装が出たので、手元で動かしながら理解したメモ。 vercel/next-server-components: Experimental demo of React Server Components with Next.js. Deployed serverlessly on Vercel. これを書いてるモチベーションとして、Twitter を見る限り React Server Component のことを 「ただのサーバーサイドへの先祖返り」とか「SSR 結果を dangerouslySetInnerHtml してるだけでは？」みたいな反応があったので、そのへんの誤解を解きたい。 Introducing Zero-Bundle-Size React Server Components – React Bl
こんにちは。4月にヘンリーに入社したSWE / アーキテクト / SETのsumirenです。 弊社ではレセコン一体型クラウド電子カルテの Henry を開発・提供しています。 今回、HenryのフロントエンドをReact + ViteからNext.jsに書き換えました。 この記事では、最初にNext.jsへの切り替えによってもたらされたユーザー体験の向上について説明します。次に、このユーザー体験の向上がどうして生じたのか、その背後にある技術的な要素をエンジニア向けに詳細に解説します。最後に、フロントエンドアーキテクチャに対する我々の長期的なビジョンについて述べます。 対象読者 Next.js導入によるユーザー体験向上 デモ 定量的なパフォーマンス比較 ユーザー体験がどう向上したか FCP高速化の技術的な仕組み Next.jsとViteの基本的なアーキテクチャの違い 補足：工夫しているポイ
はじめに こんにちは！エンジニアの柿森です。新規プロジェクトを担当しております。 ANDPADではマイクロサービス開発を推進しており、新規プロジェクトは個別に技術選定を行い、既存システムとAPI経由で連携します。 また、マイクロサービス基盤はk8sで構築されており、死活監視やログ収集もよしなにやってくれる環境が整っております。 新規プロジェクトを立ち上げで、k8s上に乗せることを前提に技術選定を行いました。 技術選定を行うにあたって検討したポイントと、採用した技術について話していきたいと思います。(あくまで筆者個人の考えです。) 採用した技術スタックの概要 フロントエンドはBlitz-jsを参考にNext.jsを採用。 バックエンドはGo + gRPCを採用。 技術選定の方針 大きな方針としては一般的な考えを踏襲しています。 ドキュメントがしっかりしており、GitHubのStarがそれなり
tl;drNext.jsはv9.3.0以降Initial Loadingの扱いが変わったクライアント側ではApolloを利用することができるが、Authorization Headerを設定するなら一工夫必要SSR時にはfetchによるシンプルなAPIリクエストをすると良い昨今のWebフロントエンド昨今のWeb開発において、React、TypeScriptとかのベース知識は当然として、やはりNext.js(あるいはNuxt.js)のような、SPA/SSR両方のニーズを汲み取りながら、dynamic routingを提供してくれたり、ビルド環境を高速に整備してくれるフレームワークが重宝されるようになってきていると感じます。 また、Reduxもアリですが、スキーマ駆動開発が推進できるGraphQL、特に尋常じゃなくステート管理が用意になるHooksとApolloクライアントの組み合わせは、フロ
【2023/11/14追記】 SPA, SSRの説明を訂正、および不必要な箇所の削除を行っています。 また、この記事はNext.js等の、具体的にフレームワークで使用されている各概念を説明するものではないので、ご留意ください。 概要 SPA, SSR, SSGという技術用語を、業務の中でも、ネットの記事の中でもよく耳にするのですが、こういう感じかな？といううっすらとした理解のままだったので、今回整理しました。 内容に誤りがあった場合はご指摘いただけますと幸いです。 (MPA) -> SPA -> SSR -> SSG という順に説明をしていきます。 SPA SPAの要旨を述べると、最初に、HTML, CSS, JSなどの必要なassetsをWebサーバーから取得し、その内のJSをもとに具体的なUIを描画し、またページ遷移の際のUIの変化も、JSをもとに再描画を行うアーキテクチャとなります。
Next.jsでSSRを限界まで簡単に実現する
１．getInitialPropsの終焉 1.1. Next.jsではgetInitialPropsのSSRが終わったことにされている Next.jsの9.3以降、getStaticPropsやgetServerSidePropsが登場し、現在ではgetInitialPropsを使ったSSRが終焉を迎えたかのような風潮となっています。しかしgetStaticPropsとgetServerSidePropsは、実際の所で大きな欠点を抱えています。 getStaticPropsはSSG前提で使うなら全く問題ありません。しかし、ある程度の更新頻度をもつシステムやリアルタイムな編集機能と相性が悪いです。ISRで使う場合も有効期限後の一回目で古いデータが表示される仕様があるので、タイミングが悪いと、せっかっく訪れた人に古いデータを渡してしまうことがあります。使いどころによっては強力ですが、用途は限定
はじめに 今後のReactではどの範囲をSuspenseで囲むか という設計が重要になってくる、という話をSuspenseの説明とともにしていきます！ ※React18がリリースされて１年近く経つので今更感あるかもしれませんが、お付き合いください。 Suspense とは React18で正式な機能として実装された機能 ※React16.6で実験的機能として追加されていた Suspense でできること データ取得中ローディング状態の宣言的な記述 コンポーネント単位でのSSR コンポーネント単位でのJSロード コンポーネント単位でのHydration Suspense は単にローディングを宣言的に記述できるだけの機能ではない Suspenseはローディングを宣言的に記述できるもの、といった内容を目にすることが多い印象です。 しかし、Suspenseは単にローディングを宣言的に記述できるだけ
Developers Summit 2020 KANSAIの登壇資料です。
Next.jsの対抗馬となりそうなReactのフレームワークでRemixのv1.0がリリースされました。 個人的にRemixでいちばん魅力を感じているのはCloudflare WorkersでSSRができるという点です（現状ではNext.jsをCloudflare Workers上でSSRするのは難しい）。これがなぜ嬉しいのかと言うと、パフォーマンスを出しつつ、低コストで運用でき、大量のアクセスに対しても低コストでスケールできそうだからです。 そもそもSSRをする必要ある？ ほとんどのWebサービスはSSRなしでSPAとしてビルドし、Cloudflare PagesやGitHub Pagesに静的ファイルをのせて動かせば十分だと思います。 例えば僕が先日作った個人開発のサービスもReact on Cloudflare Pagesの完全なSPAですが、SSRが必要な要素はまったくありません。
Next.jsでは、レンダリング手法をCSR・SSR・SSG・ISRの中から選ぶことができます。 本記事では、それぞれの特徴に触れつつ、実装方法を紹介します。 CSR （Client Side Rendering） クライアントからのリクエストに対して、サーバーは空のHTMLとJavaScriptを返します。 このJavaScriptがブラウザ上で実行されることにより、実際に表示するHTMlをレンダリングします。 メリット サーバーとの通信が初期遷移時のみに抑えられる ページ遷移が高速 デメリット 初回読み込み時に全てのデータを一括して取得するので、ページが表示されるまでの時間が長い（アプリケーションの規模が大きくなればなるほど、時間が長くなる） JavaScriptはブラウザで実行されているので、ページ表示までの時間（JavaScriptの実行時間）が使用しているマシンスペックに依存して
next.js の SSG は糞 - Diary
next.js の SSG は糞 ぼくは next.js 結構好きでこのブログとかも next.js で作ってるんですが、最近の next.js の方向性にはちょっと危うさを感じています。 next.js は最近は静的サイトジェネレータ+αみたいな感じになっていて、サーバーサイドジェネレーションなる機能のサポートが入っています。 でもこれどう考えてもゴミでしょ。いや記事が 500 件とかならいいけど、 50 万件あったらデプロイのたびにどんだけ時間かかる？という話で。それからサイトが生きているかぎり結局のところ記事はどんどん増えていく以上トップページは動的生成にならざるを得ないわけで。あまりはっきりと言われているわけではありませんが、 next.js を開発している人たちは WordPress のテーマを PHP で書きたくない人というペルソナをもとに開発していて、その人たちは CDN を
Nuxtアプリを無料で公開するときに試した5つの環境まとめ(Firebase/GAE/Netlify/Heroku) - Qiita
最近Nuxtでいろいろ作っているけど、無料で使える環境をいろいろ試してる。 いろいろメリデメあるけど、SPAならNetlify/SSRならHerokuがよさそう。 いままで試したものをまとめてみた。 ほしかったもの 主に開発してるのがCGM系のWebサービスなので、 動的なOGP画像などが設定できる(OGP芸) カスタムドメインが使える 日次のランキング集計などの定期実行ができる が、無料でできて、なるべく実装が楽で、そこまで遅くないのがうれしい。 試した5つのパターン 試したのは以下の5パターン。試してみた順で記載。 Nuxt(SSR) + Cloud Function 起動がかなり遅かった。。実装も大変なのでNG Nuxt(SPA) + Firebase Hosting 構築はかなり楽。ただ、OGP芸が大変でFunctionsが必要 Nuxt(SPA) + Netlify プレレンダリ
sumirenです。 2023年5月5日、ついにNext.js App Routerがstableになりましたね！ おめでとうございます！！ありがとうございます！！！ 今から本番で使うのが楽しみで待ちきれません。 13.4のリリースではstableの宣言とともに、目玉機能としてServer Actionsが来ています。Data Fetch（というか、もはやData Handling的なもの）の機能の一部として、とても興味深いです。 さて、Server Actions自体の解説は他の方に任せるとして、リリースノートには以下のような一文があります。 Server Actions in Next.js have been designed for deep integration with the rest of the data lifecycle, including the Next.js
Next.jsを初心者向けツールとして捉えている自分が、実践 Next.js を読んでみて2024-03-28 この記事は 実践 Next.js の書評です。 見本誌を頂いた上での記事です。（PR記事？） tl;dr App Router のメリットを理解しつつも、学習コストに割り合わないと思っている人にオススメ！ドキュメントを読めるようになるし、学習コストが下がる。 はじめに 自分はどちらかというと今の Next.js に対しては否定的な感情の割合の方が高く、仕事で困らない程度の最低限の知識しか持っていない。 しかし、なんだかんだ勉強の必要性に駆られていて、そのキャッチアップとして同書の発売を楽しみにしていた。 そんな折に @takepepe さんから見本誌をいただいたことで、この週末に読んだので書評を書きたい。 俺は今のNext.jsが好きではない 書評を書く前にポエム書かせてくれ！
v-kansai Vue.js/Nuxt Meetup #11 (京都Devかふぇ共催)でVue.jsのパフォーマンスに関する発表を行いました。 https://vuekansai.connpass.com/event/144194/ # 参考にした記事 - 超速! Webページ速度改善ガイド(WEB+DB PRESS plus) - https://www.amazon.co.jp/dp/477419400X - Web Fundamentals | Google Developers - https://developers.google.com/web/fundamentals - Vue.js App Performance Optimization – A Tutorial Series - https://madewithvuejs.com/blog/vue-js-app-pe
これはなにか cloudflare スタックを使ったマイクロフロントエンドの提案。 特に service-binding を活用することで異なるサービス(ここでは cloudflare worker)から配信されるフロントエンドを統一的にSSRしつつ、開発単位を分離している。 RTT最適化のために qwik で書かれているが、SSR を意識しなければ他のライブラリを採用しても良い。 $ tree . -I node_modules . ├── README.md ├── body │ ├── package.json │ ├── public │ │ └── favicon.ico │ ├── src │ │ ├── Body.css │ │ ├── entry.ssr.tsx │ │ └── root.tsx │ ├── tsconfig.json │ ├── vite.config.t
最近、Next.jsが複雑になりすぎて、単なるウェブ画面を作る用途にはNext.jsは重すぎるので別のものが良いとか、Vercel統合のための機能が多いんでしょ、みたいな感想を見かけることが増えた気がします。特に管理画面とか社内システムとかですね。B2Cでも設定画面系とかは当てはまるかもしれません。 ホンダ時代に、タイプRを買っても実際にサーキットとかに走らせに行く人は1/10ぐらい、という話を聞いた気がしますが、必ずしも、そのすべてのパフォーマンスを引き出さないのはダメとかなくて、単にかっこいいからとか、一部のメリットでも自分にあえば良いのです。 Next.jsも、たくさん機能がありますが、ミニマムな使い方もできます。 ほぼNext.jsの機能をオフにした使い方たぶんNext.jsを最低限で使うライン・メリットはここかな、と思います。 基本的に全部CSR(Client Side Rend
Remix の SPA モード
Remix の SPA モード 2024.01.14 Remix は React のフルスタックフレームワークで、Web 標準に基づいた API で構築されていることが特徴です。Node.js のようなサーバーサイドの JavaScript 環境で動作することを前提としています。しかし、現実の世界ではサーバーを用意せずに、静的なファイルをホスティングするだけの環境で Web アプリケーションを構築することが有効な場合も多くあります。このような需要を満たすために、Remix v2.5.0 から実験的に SPA モードが導入されました。 Remix は React のフルスタックフレームワークで、Web 標準に基づいて構築されていることが特徴です。例えばデータのミューテーションはクライアントからサーバーの API をコールするのではなく、HTML のフォームを使って行うといます。また Resp
SPA に移行しづらいシステムたちレンダリングの移り変わりCSR を有効活用しづらい事業領域App Directory によって Next.js は他と対等な選択肢になりうるServer Component がデフォルトの世界React のエコシステムの恩恵を受けられるようになるどういうアーキテクチャになるか1. モノリスから Frontend サーバを分離する2. 元々あった Frontend サーバーをリプレイスする3. SPA + BFF を１つの Next.js サーバーにするまとめこんにちは、@p1assです。 最近、Next.js 13 から beta で導入されている App Directory を趣味で触っているのですが、今まで SPA を採用しづらかった事業領域でも React のエコシステムを使えるようになりそうな予感がして、ワクワクしています。 このブログでは、今まで
はじめに この記事は、筆者がOOPartsというプロダクトにおいて、Reactのアプリを 「Create React App」 から 「Next.js」 に置き換えた事例を記す内容となっています。 これまで 「0からのNext.jsアプリケーションの作成」 文脈における記事は多くありましたが、「Create React App」から「Next.js」という、 同じReact環境における移行記事 はそこまで多くなかったと認識しています。 ある程度育ちきっているプロダクトであれば、フレームワークごと移行することは中々困難になると思っていますし、それを成し遂げることはとてもチャレンジングなことです。その結果、事例としての大規模移行事例は中々存在しませんし、稀有なことだと思っています。 本記事におけるOOPartsのNext.js移行に関する知見は、今後大きな移行する人たちの参考になれば良いと思っ
本記事は2022年11月に開催した「Tech-Verse 2022」で発表したセッションを要約したものです。アーカイブ動画を文末に掲載しています。質疑応答の様子も収録されていますのでぜひご覧ください。 ヤフーショッピングのフロントエンドを支える共通配信技術について、「共通UI配信サービス誕生までの経緯」と「共通UI配信サービスを支える技術」の2部構成で紹介します。 共通UI配信サービス誕生までの経緯 ヤフーショッピングには、トップ、検索、商品詳細、カート、レビュー、問い合わせ、製品、キャンペーン、ランキング、注文履歴などさまざまな画面があり、それに合わせてさまざまな開発チームが存在しています。 各チームでアプリケーションは独立していて、それぞれリンクで接続されています。共通UIのHTMLもアプリケーションが異なれば、それぞれに記述されます。同じアプリケーション内で共通UIを実装するのは簡単
Ginza.js #7の発表資料です
SSRみたいなフロント用語の使い方改めませんか運動
sumirenです。 背景 フロントエンド界隈はベンダやコミュニティ主導で新しいアーキテクチャや技術的手法がどんどん出ていて素晴らしいです。 一方、そうして量産されてきた用語が、界隈の変化に置いていかれている側面もあるように思います。例えば、SSRという用語を取り上げると、コンポーネントからHTMLへの変換を指すこともあれば、サーバー側でデータを取得することを指すこともあります。 実際、業界のパイオニアであるVercel/Next.jsも、そうした現状に対する懸念を持っているように思われます。実際、Next.js App Routerでは、以下のような変化が見られます。 getXXXPropsが廃止され、fetchに対する引数で表現されるようになった SSRやISRという「レンダリング」という言葉を、フェッチの文脈で使わなくなっている しかし、そっとドキュメントを書き換えた程度では、人々に
ゲーム攻略メディア「神ゲー攻略」の記事配信システムを、五年の歴史がある SSG から二年の歴史がある lit-html による SSR にリプレイスした話 - CARTA TECH BLOG
VOYAGE Lighthouse Studio の海老原 (@co3k) です。 ゲーム攻略メディア「神ゲー攻略」の記事は、これまで SSG (Static Site Generator; 静的サイトジェネレータ) を用いて構築、配信されていました。 このたび、従来の SSG を活用した記事配信の仕組みから、 SSR (Server Side Rendering) による仕組みにリプレイスしていくことにしました。 本記事では、そうした新しい記事配信システムの詳細と、移行にまつわる工夫や苦労話などについてご紹介します。 [PR] 本エントリをお読みいただく前に そもそもリプレイス前の構成ってどんな感じだったの？ というか「神ゲー攻略」って何？ みたいなのが気になって記事が読み進められないかも〜とご心配の方に耳寄りな情報です。 実は「神ゲー攻略」の事業やシステム構成については『Enginee
AWS LambdaとNuxt.jsでServer Side Renderingする（2020年版） - Sweet Escape
サーバーレスでサーバーサイドレンダリング（SSR）の後編です。前編はこちら。 www.keisuke69.net なお、同内容をこちらのイベントでも話す予定ですので興味あるかたはぜひこちらも。 serverless-newworld.connpass.com はじめに サンプルアプリ serverless.yaml 最後に はじめに 前回、SSRとはって話を簡単にしました。今回はSSRをAWSのサーバーレス、つまりAWS Lambdaでやってみたいと思います。 今回はVue.jsのフレームワークであるNuxt.jsで作ったサンプルアプリのSSRをLambdaで試してみます。 前回のブログでNuxt.jsでの例という説明をしましたが、今回はそこを実際にやっていく感じです。 なお、Nuxt.jsをLambdaで動かす場合の話って実はググってもあまり出てきません。いくつかの記事が出てくるだけです
私がエッジを使う理由
Workers Teck Tolks in Osaka #1
Next.js 9
After 70 canary releases we are pleased to introduce Next.js 9, featuring: Built-in Zero-Config TypeScript Support: Build your application with increased confidence, thanks to automatic TypeScript support and integrated type-checking. File system-Based Dynamic Routing: Express complex application routing requirements through the file system without the need for a custom server. Automatic Static Op
Fresh は Deno 製の Web フレームワークです。事前のビルドを必要せず、エッジでレンダリングを提供するという特徴があります。また Islands Architecture を採用しており、デフォルトではクライアントに JavaScript が配信されることがありません。 この記事では Fresh を使用して記事投稿サービスのチュートリアルを紹介します。 完成したサイトは以下のようになります。 ソースコードは以下のレポジトリから確認できます。 インストール Fresh を始めるには Deno の v1.22.3 バージョン以降が必要です。Deno をまだインストールしたことがないのならば、installation を参考に Deno をインストールしましょう。 # Shell (Mac, Linux) $ curl -fsSL https://deno.land/install.
「SSRと規約だけ」の勘違いを解く、 Nuxt.js をプロジェクトで採用すべき理由 - ROXX開発者ブログ
back check 事業部に業務委託でコミットしているフロントエンドエンジニアの potato4d です。 ROXX では、 v1.0 が出る前から、プロダクト、コーポレートサイト、ランディングページ、メディアなど、多くのシーンにて、 Nuxt.js が採用されています。 Nuxt.js は多くの人に愛される一方で、最近は Vue 3.0 の話もあり、多少評価が落ち着いてきた印象があります。 この記事では、十分に普及した今だからこそ、 Nuxt.js の本当の優位性と、どういったときに使うべきか。あるいは使うべきでないかを再度言語化できればと思います。 「SSRとルールだけ」という勘違い まずは Nuxt.js の採用についてです。多くの場合、「Vue か Nuxt か」という問いには、いかが判断基準として使われます。 SSR 今必要かどうか Nuxt.js の組み込みのルールをチームに
この記事は Cloudflare Workers and micro-frontends: made for one another のブログを理解するためのに Qwik の基本的な概念について理解することを目的とした記事です。 上記ブログに関しては、@laiso さんがわかりやすく解説してくれています。 本記事が、これらの記事やブログを読んで Qwik に付いて深堀りしたくなった方のお役に立てれば幸いです。 また、後日私の方でも、上記記事の解説や補足を何かしらの方法でまとめたいと思っています。 2022/10/26 追記 上の宣言通り、スクラップにまとめました。 What is Qwik ? Qwikは builder.io によって作られた、フロントエンドライブラリです。 SSRをデフォルトとし、Cloudflare Workers などでのエッジレンダリングにも対応しています。 js
はじめに (1/2) Webアプリの動作するパターンをまとめました。歴史を振り返ることで JAMStack といったモダンなスタックがどういった点で有用なのか理解していきましょう。 発表者：@kimizuy 日々スプラのXPをどう上げるかに頭を悩ませています。ブログもあります。 はじめに (2/2) これは2020年9月16日開催のりあクト！ TypeScriptで始めるつらくないReact開発 第3版Ⅰ. 言語・環境編 読書会のLT用資料として作成しました。 ※ 続きの会も企画する予定です。どちらかというと初学者〜中級者向けです。興味のある方はお気軽にご参加ください。 SST （1/3） 概要 Server Side Templating の略 基本的にはサーバサイドのフレームワークとテンプレートエンジンの組み合わせ 完成した HTML をクライアントに返すため正確にはサーバサイドレンダ
プラットフォームってつくることより計測することが重要なんじゃないかという話 / Platform Engineering Meetup #8
かなり昔に Elasticsearch ベースの検索システム（Heineken）を作っていた。 Elasticsearch で部内 Wiki 検索高速化 - Speaker Deck 特に更新せず数年動かしていたのだけど、サーバーの置き換えに伴って Kubernetes に置きたいよねという話になり、ついでに Elasticsearch も新しくしたいよね、となった結果、現状のフロントエンドだと最新の Elasticsearch では動かないということがわかった。 nonylene.hatenablog.jp フロントエンドの改修が必要なわけだが、ここでフロントエンドの構成を見ると… FlowType create-react-app PureComponent Bootstrap 3 古すぎる！絶対アップデート難しいし触りたくない技術しかない。 フロントまわりの構成を変えたいとずっと思っ
Next.jsアプリをLambda@Edgeで超簡単にSSRできるserverless-next.jsのご紹介 - Qiita
Next.js をSSR対応でホスティングしたいなら Vercel(旧Now) を使うのが定石だと思います。 Next.jsとVercelはどちらも Vercel社 (旧ZEIT社) が開発しているため一緒に使った際のDXは大変良いものです。 しかし、AWS内で完結できるならそうした方が嬉しい事が多いのでいい方法はないかと調べた所、 serverless-next.jsというServerless Componentのプラグインがよさそうだったのでご紹介したいと思います。 以下のドキュメントの要点をまとめつつ、掘り下げたものです。 https://github.com/danielcondemarin/serverless-next.js/ https://serverless.com/blog/serverless-nextjs/ serveless-next.js 機能と特徴 SSRをL
本記事は、2022年9月に開催された「TechFeed Experts Night#4 〜 フロントエンドアーキテクチャを語る」のセッション書き起こし記事「SPA化するMPAとMPA化するSPA（@yosuke_furukawa） ― TechFeed Experts Night#4 フロントエンドアーキテクチャを語る」を転載したものです。オリジナルはTechFeedをご覧ください。 古川と申します。@yosuke_furukawaでTwitterなどをやっております。 SPAは”見えるようになるまでが遅い” 私が今回お話するのは「MPA化するSPA」です。もともとSPAは、画面遷移（トランジション）をアプリケーションに合わせて最適化することを目的として発展した技術だと思っています。変更が発生したところだけレンダリングすることで高速化するテクニックだったのが、それをすべてのページで行う
76. モダンウェブフロントエンド(2022)に至る歴史 - React Server Component、SSR Streaming w/ morishin127 | fukabori.fm
MP3ファイルをダウンロード 内容紹介 2022年のモダンウェブフロントエンドまでに至る歴史、SPA、CSR、SSR、SSR Streaming、React Server Component などについて語っていただいたエピソードです。 出演者 話したネタ モダンウェブフロントエンド勉強会を開催しました そもそもWebページのダウンロードって、どう始まった？ JavaScriptがマウスカーソルをキラキラさせていた時代 Ajaxの登場や、jQuery フロントエンドMVC、Backbone.js、Knockout.js Reactは何が革命的だったのか？ 手続き型の実装は何が辛かったのか？ SPA(Single Page Application) MPA(Multi Page Application) CSR(Client Side Rendering) サーバーサイドがJSONを返す時代
この記事は？ ReactのSSRの理解を深めるために自前で実装してみました。 せっかくなのでその記録を記事にまとめました。 ※ App Router以前のPage Routerの内容です。 ReactRouterを使って複数ページのSSRをしている新しい日本語記事がなかったというのも記事化の理由の一つです。 この記事のソースコードはこちらです。 技術スタック フロントエンド React.js (v17) React-Router (v6) TypeScript Webpack バックエンド Express 作ったもの 初回リクエスト時 サーバーサイドレンダリング(SSR)してたHTMLをクライアントに返却。 サーバーから受け取ったHTMLにクライアントサイドでイベントリスナーを設定(hydrate) ページ遷移時 新しいページで必要な情報をクライアント側からWEB APIを叩いて取得。 ク
こんにちはdelyでサーバーサイドエンジニアをしているyamanoiです この記事は「dely #2 Advent Calendar 2020」の12日目の記事です。 adventar.org adventar.org 昨日は@yochidrosさんの「KMMでiOS・Android を共通化しよう」でした。 みなさんwebサイトを作成する時にSPAを利用していますか？ SPAはユーザーに対してメリットが大きいですが、SEO観点やOGPタグのレンダリング等で SSRが避けられない場面に出くわすことがあると思います。 SSRが不要であればビルドして生成された成果物をs3等でホスティングするだけなのでデプロイや、運用が楽なのですが、 SSRをするとなるとNode jsの実行環境必要になります。 ある程度大きなプロジェクトであればECSやGKE, GAEに載せてガッチリと運用すべきだと思いますが
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
実践Next.js - App Router への理解を深めるために -
SPA + SSR + PWA の作り方とセキュリティについて - hiroppy's site
React Server Component の Isomorphism について解説する
フロントエンドをViteからNext.jsに書き換えた話 〜パフォーマンス編〜 - 株式会社ヘンリー エンジニアブログ
プロダクトにNext.jsとGoを採用した理由と背景 - ANDPAD Tech Blog
Real World GraphQL on Next.js SSR
SPA, SSR, SSGって結局なんなんだっけ？
今後の React ではどの範囲を Suspense で囲むかという設計が重要になってくる
フロントエンドのトレンド〜サーバーレスSPA、Jamstack〜
Cloudflare WorkersでSSRができると何が嬉しいか
【Next.js14】CSR・SSR・SSG・ISRの違いと実装方法 - Qiita
Next.js Cacheのアツさをシェアしたい(App Router)
Next.jsを初心者向けツールとして捉えている自分が、実践 Next.js を読んでみて
Vue.js Performance Tips / #v_kansai 11
cloudflare の better micro frontend を読む
管理画面等でNext.jsをBetter Reactとして使う | フューチャー技術ブログ
バックエンドエンジニアがNext.jsのApp Directoryに夢を見る - ぷらすのブログ
Create React AppからNext.jsへの移行事例紹介
ヤフーショッピングのフロントエンドを支える共通配信技術
SSRを避けるためにやっていること / ssr-alternative
Deno の Web フレームワーク Fresh チュートリアル
Qwikの基本概念である Resumable を理解する
Webアプリパターンの歴史 - SST、AJAX、CSR、SSR、SSG、そしてISR - Qiita
SSG is a compiler
検索システムのフロントを SSR・Remix で作り直した - Unyablog.
SPA化するMPAとMPA化するSPA ～TechFeed Experts Night#4 講演より | gihyo.jp
React.jsのSSRをTypeScriptで自前で実装してみた
Cloud Runで手軽にサーバーレス・SSR(サーバーサイドレンダリング) - dely Tech Blog