その他のユースケース
深くは紹介しきれませんが、最後にもう少し色々な使い方を紹介してみます
管理ツールとして
ちょっとした管理ツール・業務効率化ツールには非常に便利です。
前章まででも紹介したnext-authは非常に多彩なOAuthプロバイダーがあるため、これも便利に利用できるでしょう。
以前下記のような記事を書いていますので、興味があればご参照ください
また、前章までで軽く触れましたが、React AdminをNext.jsに組み合わせて使うのも一応可能です。(ただし、React AdminはData Providerによっては正しくないRangeヘッダを利用する結果Vercelでうまく挙動しなくなる等の問題もあるのでご注意ください)
フォームなどの簡易機能付きのLPサイトとして
「ちょっとLP作ってよ、ペライチだからさ」と言われて実は要件を聞いてみるとstatic siteではちょっと無理じゃないか、なんてことはWebエンジニアという職業をしていると一度は経験しているかと思います。
こういうケースでもNext.jsは大変重宝するでしょう。
だいたい作るなら下記のような流れになるはずです
-
pages
でLP、フォーム部分など動的な部分を作成する -
api/form.ts
のような形でフォームの受口を作る - APIの内部でフォームを別なサーバーへポストするなり必要な処理をする
- CORS回避の必要があれば
api
かgetServerSideProps
を利用する
モバイルアプリのバックエンド・BFF
モバイルアプリでのバックエンドとして利用してもかなり良い仕事をしてくれるでしょう(筆者はこの使い方をしてとても高速に作ることができました)
- 多くの部分はAPIでBFF部分を作成する
- 実際は裏側でFirebaseやDynamo・RDSへのアクセスを利用する
- 一部WebViewとして利用したい部分はReactで
pages
下に実装する - 利用規約や特商法のような「アプリ内部に入れたくはないけどわざわざサーバーを建てるのも…」という静的HTMLを
public
ディレクトリに配置する- 特に動的である必要も無いので納品がHTMLの場合React化すらしない
Raspberry PiなどシングルボードLinux上でのGUIアプリケーション・治具
セキュリティ上の観点からあくまで社内向けや自分の手元用に限定されますが、Raspberry PiのGUIとして利用するのも有効です。
特徴として、APIの部分でchild_process
を経由してLinuxコマンドを叩くことで様々な操作をすることが可能でしょう。
繰り返しになりますが、child_process
を利用するのはセキュリティリスクが高まる可能性のある利用方法なので、注意してご利用ください。
プロトタイピング・モックアップとして
FramerXやFigmaなどプロトタイピングツールは最近発達した世の中でコールドモックとしてナマのHTMLで始める人はあまり居ないと思いますが、筆者はそれらのツールが使いこなし切れないと感じた場合に利用します。
比較的ツールへの慣れの問題なので、プロトタイピングツールにそれほど勝つものではありません。ただ、プロトタイピングツールよりも実装に近づくので、「ここの実装は大変そうだ」とか「この考慮漏れをしている」というのに早めに気づけるという特徴はあります。
また、Reactによるコンポーネント化・pagesのディレクトリ構造での配置等、Next.jsで行うとやはり便利な部分は多く感じます