# Next.js のインフラ要件と選択肢 この記事は [Next.js アドベンドカレンダー 2020](https://qiita.com/advent-calendar/2020/nextjs)の 24 日目です。 Next.js をデプロイする上で、 vercel 以外のインフラを選択する際、どのような要件が必要かを以下に整理します。 SSG/SSR/ISR のどれを選択するべきかというのはアプリケーション性質に大きく依存しますが、インフラ要件も大きな要素であるため、慎重に選択するのが良いかと思います。 ## SSG の場合 ### 要件 Static Site の配信ができれば配信は十分です。 デプロイ時のビルド環境として CI を使う他、 GitHub の push を hook してビルドが走るサービスを使用するのも良いでしょう。 HTML という大きなファイルを配信するため、 CDN を経由するのがベターです。CDN の選定の場合はリージョンに注意する必要があります。 ### 具体的なプラットフォーム - Netlify - AWS Amplify Console - firebase hosting - GitHub Pages - Amazon S3 - etc... ## SSR の場合 ### 要件 Node.js を実行する必要があるため、コンピューティングリソースが必要です。 簡単に行うのであれば IaaS やコンテナを使うのが良いですが、 Cloud Functions 等の Faas を使用するのも良いでしょう。 ただし、 FaaS の場合はコールドスタートが速度に影響するケースもあるため、パフォーマンスを意識する場合は測定・検証が必要となります。 また、上記同様、 static サイトの配信には CDN を使用するのがベターでありますが、個別に選定するとデプロイが複雑になります。 可能であれば、 CDN と組み合わせての管理をできるプラットフォームを選定するのが良いでしょう。 なお、 Lambda@Edge で動かすためのフレームワークも存在しますが、こちらの採用は運用との相談となるかと思います。特にプロダクションユースではトレーサビリティや再現性の観点から慎重になる必要があるでしょう。 ### 具体的なプラットフォーム - AWS lambda + S3 + CloudFront - CloudFunctions + Firebase Hosting - AWS Amplify - Netlify Functions - etc... ## ISR の場合 ### 要件 本題です。 Vercel で動作させる場合は必ずしも理解しなくて良いのですが、現状別プラットフォームで ISR を正しく行うためには ISR の挙動を理解する必要があります。 IRS の本体は、 SSR された HTML をキャッシュし、ユーザのアクセス状況によって適切に生成・破棄を行う機能です。 単に IaaS やコンテナにデプロイしただけでは、クラウドの構築によりキャッシュはされるものの、パージが ISR の想定通りには動きません。 (コンピューティングリソース内部にキャッシュする場合はその限りではありませんが、 CDN を通さない分のパフォーマンス影響が発生します。) Vercel の場合はデプロイ時に edge でのワーカーが用意されているかのように見えますが、他のプラットフォームで実現する場合、同等の機能が必要があります。 たとえば AWS の場合、 現状の CloudFront(Amplify Console 含む) では相当する機能がないため、 lambda@edge で動作するコードを用意しなくてはなりません。 つまり、 IaaS / コンテナ + 静的ホスティング + CDN に加え、 edge でのコンピューティングリソースの準備が必要となります。 (これを Out of the Box で使えるのが Vercel の競合に対する優位性かと思います。) 参考までに、 Next.js 本体ではありませんが、 edge での動作を前提とすることによりキャッシュコントロールの自由度を高めた flareact というフレームワークが存在します。 https://github.com/flareact/flareact [Rendering React on the Edge with Flareact and Cloudflare Workers - The Cloudflare Blog](https://blog.cloudflare.com/rendering-react-on-the-edge-with-flareact-and-cloudflare-workers/) ### 具体的なプラットフォーム - AWS Apmlify + lambda@edge ## 総括 ISR 以外であれば様々なプラットフォームで動作するため、各社・プロジェクトの利用しているクラウドベンダに沿ったプラットフォームを選定することでも問題なく動作します。 しかし ISR を前提とするのであれば、 edge コンピューティングを前提とする必要があります。運用を見据えた場合、自前で用意するのか Vercel を利用するのかの検討の余地は十分にあります。
Last changed by  
 
ユーン
7090

Read more

ポートフォリオデザイン相談

確認遅くなりました！！！！Win11/chrome, Android13/chromeで確認済です。

5/30/2023
TypeORM と比べながら Prisma を触る

私は以前 TypeORM という node.js の ORM を推していましたが、 Decorator の仕様が未だ安定しないこと、 TypeScript の legacy な実装に依存している点が難点でした。 そんな中、 Next.js ベースのフルスタックフレームワークである blitz が Prisma2 を採用したこともあり注目を集めているため、 TypeORM と比較して紹介します。 TypeORM まず TypeORM について見ていきます。 公式ドキュメントの Getting Started は以下です。 https://typeorm.io/#/

12/23/2020
失敗スクラム学び

理解のないスクラムは無理 仕様が先になくてよいという誤解 スケジュールどおりに作れるという誤解 Biz と Dev の今の距離感により正しくスクラムが行われなかった Dev だけではなく Biz を巻き込んでスクラム教育をすべきだった スクラム教育がない段階でスクラムの採用を決定してはいけなかった(理解した上で採用是非を検討すべき) 成果物の受け入れ条件を明確に定義していなかったため、ポイントが形骸化した

12/23/2020
Stencil.js で CustomElements を実装する

Stencil.js とは Stencil.js は、マルチプラットフォーム向け UI システムである Ionic の開発チームが主導して開発が進められています。 https://stenciljs.com/ 執筆時点でのバージョンは v2.3.0 が提供されており、1度のメジャーアップデートが実施されています。 また、 Ionic Framework の v4.x 以降は Stencil によって実装されています。 Stencil.js は、再利用可能なコンポーネントを、 CustomElements として定義するためのツールチェイン・コンパイラです。(公式でフレームワークではないと名言しています。) TypeScript ファーストであり、 Decorator (TC39 proposal にあるものではなく、 TS 実装の legacy なものなので、将来的に変更になる可能性はあります)と React に依存しない JSX でコンポーネントを記述します。

12/6/2020
Read more from ユーン
Published on HackMD