近年のWeb開発ではSPAが流行しており、API方式で実装することが多いです。 このレッスンではこのアーキテクチャでAPIサーバを立てる方法を学んでいきます。 そのために、Web開発におけるアーキテクチャや方針などに触れながら、 よりよいサービスを作ることを目標に、これから作っていくアプリケーションの実装方針を考えていきます。

アーキテクチャ紹介

Express.jsでは、さまざまなアーキテクチャにおいて柔軟に対応することができます。

本章ではそれぞれのアーキテクチャの特徴、メリット、デメリットについて説明していきます。

現代のアプリケーション開発では、フロントエンドとバックエンドの機能分離を行いAPI方式で通信することが一般的です。 具体的にはフロントエンドがユーザーインターフェースやユーザー体験を担当し、 バックエンドがデータ処理やビジネスロジックを担当します。

これにより、フロントエンドとバックエンドを別々に開発・保守できることにより開発効率や保守性の向上が見込め、 また別々に動作していることからそれぞれのリソースをそれぞれのタイミングや規模で最適化することができるなどのメリットが得られるため、 API方式で実装することが重要視されています。

SPA

SPAとはWebアプリケーションの一種で、 単一のHTMLページからJavaScriptやAJAXなどの技術を使って動的にコンテンツを入れ替えページ表示を行うアプリケーションです。

一般的なWebアプリケーションでは機能ごとにページを分けて、それぞれの機能のページから毎回データを取得してきます。 SPAでは初回のアクセスでHTML/JavaScript/CSS/画像等のファイル群一式を取得した後は非同期通信で通信を行い動的に表示内容を変え、 ファイルのやり取りは基本的には行わないことが異なります。

SPAでは、単一の HTML ページと必要な JavaScript、CSS ファイルをダウンロードし、その後ユーザーがページ内での操作に応じて動的にコンテンツを更新できます。

例えばSPAの例としてGmailでは、一つの画面を開くとその画面の中でメール閲覧、送信、その他設定などがおなじ画面でできます。 メール送信やメールの受信はAjaxを用いてページ遷移を伴わずに行っているということです。

従来の Web アプリケーションはページを遷移するたびに新しい HTMLページをダウンロードする必要がありました。

これにより、ページ遷移が遅くなったりUIが更新されるたびに再描画をする必要があります。

SPA では一度ページを読み込んだ後に必要なデータを非同期で取得し UI を更新します。 再描画がないためスムーズで、ユーザエクスペリエンスの向上が期待できます。

SPAの代表的なサイトとしては以下のようなものが挙げられます。

1. Gmail: Googleが提供するメールサービス
2. Facebook: 世界最大のSNS
3. Twitter: ツイートを投稿・閲覧するためのサービス

API方式

API 方式とはアプリケーションと外部のプログラムの間でデータをやり取りする方式です。 具体的にはデータベースサーバにあるデータをWebサーバとインターネットを通してブラウザから閲覧や操作するなどの用途に用いられます。

SPAを作る上で、 フロントエンドとバックエンドを切り離すことは重要です。 その上でデータをやり取りするインタフェースとしてAPIを利用することで、フロントエンドやバックエンドを独立して開発することができます。

API方式を採用することでフロントエンドとバックエンドの機能分離がを行え、 それぞれを独立して開発や保守ができるため開発効率や保守性の向上 を図ることができ、また柔軟な開発スケジュールを設定できるようになります。

複数のフロントエンドから同じAPIを利用できるため、 それぞれを独立してアップデートやサーバの増強などスケーラビリティの確保が容易になります。

また、フロントエンドとバックエンドを別々にデプロイできるため、デプロイのタイミングを柔軟に調整できます。

このように、API方式による開発手法は現代のアプリケーション開発において必要不可欠なものとなっています。

API方式の代表例として RESTfullAPI が挙げられます。

RESTfullAPIではCRUD(Create, Read, Update, Delete)を下の表のように実装します。

CRUD	HTTPメソッド	動作
Create	POST	作成
Read	GET	取得
Update	PUT	更新
Delete	DELETE	削除

HTMLでは標準の機能ではGETとPOSTしか使えないことや設計簡略化などのために Create と Update を統合し Upsert(Update&Insert) としてPOSTを利用して開発する場合もあります。

今回は Express.js を利用する例として TODO アプリを作成します。

具体的にどのような機能が必要になってくるか考えていきます。

Express.js と MySQL を利用してリクエストにjson形式で応じるようなプログラムを作成します。

この講座では講座終了後にVue.jsやReactなどフロントエンドに SPA を採用したアプリケーションを作ることができる設計を念頭にjson形式で出力するところまでを解説します。 この講座を完了するとCRUDのできるAPIサーバが出来上がります。

API方式+SPA方式を採用することで フロントとバックエンドを別々に開発できるため、保守性が高く、通信を極力少なく、 軽量な扱いやすいWebアプリを完成させることができます。

また、視覚的にわかりやすく容易にリクエストを送信できるようにするため ejsというテンプレートエンジンによる簡易的なフロント画面も作成していきます。

アプリケーションの実装方針はAPI方式のSPAアプリを作ることを念頭にAPIサーバを作ります。 今回はSPAの部分には触れませんのでejsというレンダリングエンジンを用いたモノリシックアーキテクチャなフロント画面も作成します。

エンドポイント

エンドポイントとは、Web APIにおいてクライアントからのリクエストを受け取るURLのことを指します。

今回実装するTODOアプリの機能とエンドポイントの対照表を考えます。

メソッド	パス	機能
POST	/apt/task	タスクを追加する
GET	/apt/task/:id	タスクを取得する
PUT	/apt/task/:id	タスクを更新する
DELETE	/apt/task/:id	タスクを削除する
GET	/apt/tasks	タスク一覧を取得する
GET	/apt/logs	ログ一覧を取得する

順番に見ていきます。

・タスク追加

/api/taskにPOSTメソッドでリクエストがあった時にbodyの内容でタスクを追加します。

・タスク取得

/api/task/:idにGETメソッドでリクエストが来た場合に、 expressのparamsの機能でidを取得しそのidに一致するタスクをレスポンスします。

・タスク更新

/api/task/:idにPUTメソッドでリクエストが来た場合に、 paramsでidを取得しbodyの内容でタスクを上書きします

・タスク削除

/api/task/:idにDELETEメソッドでリクエストが来た場合にidが一致するタスクを削除します

・タスク一覧取得

/api/tasksにリクエストが来た場合にタスクの一覧をレスポンスします

・ログ一覧取得

/api/logsにリクエストが来た場合にログの一覧をレスポンスします。

このようなエンドポイントを持つアプリケーションを考えていきます。

SPAとしてjson形式でのリクエストが処理できるようなAPIサーバを構築していきます。

またejsフロント向けエンドポイントとして

• / トップページ 各機能へのリンクを配置
• /tasks タスクの一覧を表示する
• /create タスクを新規作成する
• /task/:id タスクの詳細を表示し、削除と編集のボタンを設ける
• edit/:id タスクの詳細を編集する
• /logs ログを表示する

このようなエンドポイントから各機能にアクセスできるよう設計を行います。

DB設計

今回実装するTODOアプリのDBに格納する内容と型を見ていきます。

タスクテーブル

論理名	カラム名	型	説明
タスク ID	id	VARCHAR	タスクごとに一意になるような短い文字列を保存します。
タイトル	title	VARCHAR	タスクのタイトルを短い文字列で保存します。
詳細	detail	TEXT	タスクの詳細を長い文字列で保存します。
作成日時	created_at	DATETIME	作成日時を日付型で保存します。
更新日時	updated_at	DATETIME	更新日時を日付型で保存します。
使用中フラグ	by_using	BOOLEAN	削除されているかを真偽型で保存します。

これらの内容をデータベース(MySQL)に格納していきます。

ログテーブル

ログとは、システムやアプリケーションが動作する際に出力される情報のことを指します。 ログは、プログラムの実行中に発生する様々なイベントやエラー、警告などを記録することで、システムの状態や問題点を把握しトラブルシューティングや監視に役立ちます。

このTODOアプリではタスクの作成、編集、削除のログをとります。

論理名	カラム名	型
タスクID	task_id	VARCHAR
何があったか('create','edit','delete'が入る)	action	VARCHAR
作成日時	created_at	DATETIME
更新日時	updated_at	DATETIME
使用中フラグ	by_using	BOOLEAN

上記で定義したエラーテーブルにCRUDのCUDの操作(作成、更新、削除)があるたびに追記していきます。

今回はGETメソッドによる取得はDB上変化がありませんのでログは取りません。

しかし大規模なWebアプリとして公開する際はアクセスログとして残す必要が出てくるかもしれません。