フルスタックアプリとは？平易な言葉で解説

フルスタックアプリとは、動作に必要なすべての層を含んだアプリのことです。人が見てクリックするフロントエンド、サーバー上で動いてルールを適用するバックエンド、そしてすべてを記憶するデータベースです。タスクを保存し、どの端末からでもログインでき、ほかの誰にもリストを見せないTo-Doリストは、フルスタックです。営業時間を表示するだけの1ページは、フルスタックではありません。

「スタック」とは、技術の層が積み重なったものを指します。「フル」とは、そのすべての層が揃っていることを意味します。

AIで作るときにこの違いが重要な理由

AIビルダーにアプリを説明するとき、使う言葉によって、どの層が作られるかが決まります。「当店のメニューを表示するページを作って」と言えば、フロントエンドができます。「お客様がメニューから注文でき、厨房が新しい注文を見られるようにして」と言えば、注文は保存され、2種類の利用者の間で共有され、非公開に保たれなければならないので、3つの層すべてが必要になります。

この違いを知っておくと、次の3つの点で役立ちます。

• 正しいことを依頼できる。 データを保存したいなら、そう伝えてください。フロントエンドだけを作るビルダーは、完成したように見えても、再読み込みするとすべて忘れてしまいます。
• 見かけだけの完成に気づける。 サンプルデータを使ったデモは、実際に動くアプリとまったく同じに見えることがあります。層を理解していれば、データが本当にどこかに保存されているかを確認できます。
• 維持費を理解できる。 フロントエンドだけなら、静的ファイルとして配信できます。バックエンドとデータベースは、サーバー上で動くプログラムであり、ホスティング費用の大半はそこから生じます。

身近なたとえ：レストラン

レストランを考えてみてください。

• ダイニングルームはフロントエンドです。 メニュー、テーブル、ウェイターのメモ帳。客が目にするもので、心地よく使いやすくあるべきものです。
• 厨房はバックエンドです。 客は中に入りません。注文を受け、料理が作れるかを確認し、調理し、おかしな要求は断ります。ルールはここにあります。
• 食材庫と注文台帳はデータベースです。 存在するものと注文されたものを保持するので、シフトが交代しても何も忘れられません。

ダイニングルームだけのレストランでは、素敵なメニューを見せることはできても、食事は出せません。フロントエンドだけのアプリは、フルスタックのふりをしているだけです。

3つの層の詳細

層は決まった順序で連携します。フロントエンドは、バックエンドが受け付ける決まった種類の要求の集まりであるAPIを通じて、バックエンドに何かを依頼します。バックエンドは要求を確認し、データベースを読み書きして、応答を返します。フロントエンドがデータベースに直接アクセスすることはありません。

この順序は、スタック全体で最も重要なセキュリティの考え方です。フロントエンドのものは、訪問者のデバイス上で動くため、訪問者が読んだり変更したりできます。そのため、「この請求書は所有者しか見られない」「クーポンは1回しか使えない」といったルールは、バックエンドで強制しなければなりません。層の分け方について詳しくは、フロントエンドとバックエンドの違いをご覧ください。

具体例：クラス予約アプリ

ヨガスタジオを運営していて、オンラインでクラスを予約できるようにしたいとします。

訪問者の操作： サイトを開き、今週のクラスを見て、1つをタップし、サインインして予約します。

その裏側で起きること：

1. フロントエンドが時間割を表示します。そのために、バックエンドに「今週のクラスは何があり、空席はいくつあるか？」と尋ねます。
2. バックエンドがデータベースにクラスを問い合わせ、各クラスの予約数を数えて、返します。
3. 訪問者が予約をタップします。フロントエンドは「サインインしているこの人について、クラス42を予約」という要求を送ります。
4. バックエンドは確認します。本当にサインインしている人か。クラスは満席ではないか。すでに予約していないか。すべてが問題ない場合だけ、データベースに新しい予約の行を書き込みます。
5. バックエンドが「予約完了」を返し、フロントエンドは確認画面を表示します。
6. 後日、スタジオのオーナーがログインしてクラスの一覧を見ます。バックエンドは、彼女が管理者であることを確認してから、全員の名前を表示します。

もしこれがフロントエンドだけで作られていたら、どうなるでしょうか。時間割は表示されるかもしれず、予約ボタンは素敵なチェックマークを表示するかもしれません。しかし予約は再読み込みすると消え、「空席数」は他の人にとって誤ったものになり、オーナーは予約を一度も見られません。ステップ4、つまり確認の処理がまったく存在しないのです。これが実際の違いです。

主な用語

• フロントエンド（クライアント側）： ブラウザ内で動く部分。
• バックエンド（サーバー側）： サーバー上で動く部分。APIサーバーとも呼ばれます。
• データベース： データを整理された形で保存する場所。データベースとはをご覧ください。
• API： フロントエンドや他のプログラムからバックエンドが受け付ける要求の一覧。
• 認証： 誰であるかを確認すること（ログイン）。認可： その人が何をしてよいかを確認すること。
• デプロイ： 公開できるように、すべての層をサーバーに配置すること。
• モノリス対サービス分割： すべてを行う1つのプログラムと、いくつかの小さなプログラム（たとえばウェブサイトと独立したAPI）の違い。どちらもフルスタックです。

よくある間違いと誤解

• 「完成しているように見えるから、完成している」。 サンプルデータや動いているように見えるボタンは、保存されたデータとは違います。ページを再読み込みし、プライベートウィンドウで開き、データがまだ残っているか確認してください。
• ルールをフロントエンドに置く。 ボタンを隠すことはセキュリティではありません。バックエンドが確認していなければ、要求の仕方を知っている人は誰でも同じ操作ができてしまいます。
• シークレットキーをフロントエンドに置く。 決済やAIのプロバイダーのキーをブラウザのコードに入れると、すべての訪問者が読めてしまいます。キーはバックエンドに、環境変数として置いてください。環境変数とシークレットをご覧ください。
• フルスタックは複雑という思い込み。 小さなフルスタックアプリは、数画面、数個のバックエンドのルート、3つのデータベーステーブルで構成できます。フルスタックとは層の説明であり、規模の説明ではありません。
• すべての技術を自分で選ばなければならないと思い込む。 最初のバージョンには、一般的で信頼できる技術の組み合わせなら何でも構いません。それよりも重要なのは、データとルールを明確に説明することです。

AIビルダーに依頼すること

3つの層の観点からアプリを説明してください。名前を知らなくても構いません。

• データ： 「クラス（名前、時間、定員）と予約（クラス、人、予約日時）をデータベースに保存してください。」
• ルール： 「定員を超えるクラスは予約できないようにしてください。同じ人が同じクラスを予約できるのは1回だけにしてください。管理者だけが誰が予約したかを見られるようにしてください。」
• 画面： 「週間の時間割、予約確認画面、クラスごとの予約者を表示する管理者ページを作ってください。」
• 確認： 「ルールはページだけでなく、サーバー側で強制してください。APIキーはサーバー側に保管してください。」

そのあと、疑い深い人のようにテストしてください。再読み込みし、2人の異なる人としてサインインし、見てはいけないデータを見ようとしてみてください。エンドツーエンドでの流れは、AIでアプリを作るためのガイドで紹介しています。

Mythexでのフルスタックアプリ

Mythexは、チャットでの説明からフルスタックのウェブアプリを作ります。標準では、新しいアプリにはReactとTypeScriptのフロントエンドが付きます。アプリがデータを保存する必要がある場合は、プロジェクトに専用のPostgresデータベースを追加します。また、ウェブサイトと並べて、別のAPIサーバー（Python、Node、C#、Javaなど）を依頼することもできます。すべてはライブプレビューで一緒に動き、公開URLに公開されます。ウェブサイトとAPIがどのようにプレビューされ、一緒に公開されるかについては、ドキュメントのマルチサービスのアプリのページをご覧ください。出発点としては、フルスタックアプリビルダーのページも参考になります。

よくある質問