Trello風タスク管理アプリのアプリケーション構成を検討する日記⑥

はじめに

今回は機能実装はありません(´･ω･`)

今まで作成してきたフロント部分に対してAPIを作ってDB処理を実装していきたいと思うのですが、それをどういった構成で実現するか考えています。

NextはSSR(Server Side Rendering)の機能を持っているため、Node.jsによりサーバー側の処理を実装する事も可能なためです。
※React 16以降はSSRが可能

理解があいまいな部分もあるので、この辺の話を整理しながらこのアプリの技術スタックを決めていきたいと思います。

前回までのあらすじ

今までの内容

Next.jsでTODOアプリを作成する日記①

• Tailwindを導入できた
• ComponentにPropsを渡せた
• Componentの中でPropsを使用できた
• Componentをループを使って表示できた
• React Iconsを導入できた

Next.jsでTODOアプリを作成する日記②

• useStateを使って状態管理ができた
• setStateを使って状態の更新ができた
• 状態に対するイミュータブル(不変)な操作の必要性が分かった
• 子側で親のイベントをトリガーできた

Next.jsでTrello風タスク管理アプリを作成する日記③

• filterをかけて条件に一致したデータでComponentを表示できた
• Dnd kikを導入できた
• Dnd kikのDndContextとソート機能に関するSortableContextでカラム内ソートを実装できた

Next.jsでTrello風タスク管理アプリを作成する日記④

• Dnd kitのDropableでカラム間を移動した時に対応したidをhandlerに渡す事ができた
• onDragEndとonDragOverを使い分けてhandlerを作成できた
• カラム間を横断するドラック＆ドロップアイテムを作成できた

Next.jsでTrello風タスク管理アプリを作成する日記⑤

• Redux toolkitを導入してグローバルな状態管理ができるようになった
• 新しい機能実装に対応できるディレクトリ構成を検討できた
• Material UIを導入してModalを実装できた
• onDragとonClickイベントを持つDOM要素のイベントを制御できた

NextのSSR(Server Sidee Rendering)

Nextでは他サーバーサイド言語のフレームワークと同様にサーバー側(Node.js)でAPIとして動作しHTML,Jsも生成する事ができます。
そのため最初のリクエストに対してAPIからデータを取得した状態でHTML、jsを返したり、その後のAPIへのリクエストもNext側で捌く事ができるそうです。

またクライアント側は差分のみAjaxで取得するSPA構成なのでサクサク動くという事だと思います。
※NextでもCSR(Client Side Rendering)としてビルドする事も可能
　(その場合ServersidePropsなどサーバー側の値は使用できない)

「基礎から深堀りするWebアプリケーションアーキテクチャ」より

フロントエンドのアーキテクチャ

上記のようにNextが実装できる機能の領域はフロントエンドからバックエンドまで広く対応しているため、どういった技術を組み合わせてアーキテクチャを決めていくかはアプリの規模と目的に基づくと思います。

アプリケーション構成の選択肢

下記のZenn記事ではフロントエンドを包括した様々なアーキテクチャパターンの詳細を体系的に紹介しています。

Micro Frontends Architecture Patterns

こちらからいくつか抜粋させて頂きます。

Monolithic Applicationの中でビルドしたJavaScriptを使用する構成

こちらはLaravelやRuby on Railsなどサーバーサイドフレームワークのフロントエンド部分でJsフレームワークを使用する構成です。

おそらく昨今のサーバーサイドフレームワークでは、フロント部分にJsを導入する機能が備わっていると思います。
例えばLaravelでフロント部分にVue.jsを導入したい時には下記コマンドで実装できます。

php artisan ui vue

過去にLaravel × Vueアプリの個人開発でこちらの記事を参考にさせて頂いたことがあります。

また例えば、Vue(フロントエンド)とLarave(バックエンド)を完全分離して開発しこの構成を取る場合、メリットは感じませんが個別にVueでBuildしたJsファイルをLaravelサーバーに設置する必要があります。

いずれもあくまでLaravelのサーバー内でjsが使用される構成となっています。

JAMstack(JavaScript, APIs, Markup)

フロントエンドとバックエンドが明確に分離した構成になります。

フロントエンドとバックエンドはお互いの処理の詳細を知る必要はなく、API設計に則ってリクエスト/レスポンスを使用した実装を行うため完全分業の体制になると思います。

JAM(JavaScript, APIs, Markup)の解説を引用させて頂きます。

• JavaScript - アプリケーションに動的な機能を追加するのみならず、APIs、Markupを包括するランタイムとしての役割を持ちます
• APIs - バックエンドやサードパーティとのやりとりはすべてAPIを用いて行われます
• Markup - ビルドタイムで生成、静的にホストされ、CDNなどで配信されるHTMLです

JAMstackにおいてSPAは欠かせない技術
HTMLやjsなど画面描画を行うための基本的な情報は最初のリクエストでクライアントに配信され、差分のみAjaxでやり取りする技術はこちらの構成に必要不可欠だと思われます。

SSR(Server Side Rendering)

仕組みは上記で説明した通りです。

選択によってはNextが果たす役割もLaravelやRuby on Railsなどのサーバーサイドフレームワークと同じになると感じます。

結論

自分の理解を整理するためにつらつらと皆さんの記事を引用させて頂きました。

今回は特に大規模アプリになる予定もないのでサーバーサイドのフレームワークは導入せずNext一本で行こうと思います。

Trello風タスク管理アプリのアプリケーション構成

まとめ

今回はだいぶ内容があってるか怪しいです。
間違ってたらすみません。

今回できた内容

• アプリケーション構成を検討できた