レストラン（サーバー）を用意して、住所（ドメイン）を決め、電話帳（DNS）に住所を登録する。
その店舗運営を管理会社（Firebase Hosting）に任せると、管理の手間なく誰でも来られるお店が完成します。

「山田さんに電話したい」→ 電話帳（DNS）で電話番号（コンピュータ用の数字の住所）を調べる →
番号に電話する（サーバーに接続する）→ 山田さんが出る（サーバーがデータを返す）→ 会話成立（ブラウザが表示）

正式名称：Domain Name System（ドメイン・ネーム・システム）

「gonmura.com」という名前を「203.0.113.42」という数字（IPアドレス）に変換してくれる仕組みです。
電話帳が「山田さん」→「090-xxxx-xxxx」に変換するのと同じ役割です。

DNS（電話帳の仕組み）の中で、実際に「このドメインの場所はここですよ」と答える担当のサーバーのこと。
ドメインを買ったあと「このドメインの問い合わせは、どのネームサーバーに聞けばいいか」を設定します。

国内・海外それぞれ複数の選択肢があります。サポート言語・料金・他サービスとの連携で選びます。

ネームサーバーに登録する「このドメインの〇〇は△△ですよ」というメモ書き。種類によって書く内容と用途が違います。

サーバーはレストランのようなもの。「この料理（ページ）をください」という注文に応じて、キッチンで準備して提供してくれます。

データベース = レストランの食材庫。データを棚ごとに分類して保管。

サーバーの中は「ホール・キッチン・食材庫」の3つが連携しています。

前のスライドの「ホール・キッチン・食材庫」の各役割を、Firebaseのどのサービスが担当しているかをマッピングします。

全部やってくれる「管理会社」。あなたは料理（サイト）を作るだけ！

この研修サイトもFirebase Hostingと同じ種類のサービス（Cloudflare Pages）で公開されています。 もっと詳しく知りたい方は バックエンド基礎研修 も参照してください。

サーバーは すでにGoogleが動かしている

「デプロイ」でサーバーが作られるのではなく、Googleの巨大なサーバー網に あなた専用の置き場が割り当てられる 仕組みです。

管理会社が用意してくれる xxx.web.app（または xxx.firebaseapp.com）は便利ですが、お客様に覚えてもらうなら自社ドメイン（例: gonmura.com）の方がいいですよね。その看板を自分のものに付け替えることができます。

Firebase Hosting でも Firebase App Hosting（動的なアプリ向けの新しいサービス）でも、カスタムドメインの設定方法はほぼ同じです。どちらもFirebaseの管理画面からドメインを追加して、DNS設定をするだけ。

Hosting の "キッチン付き" 版

Ch5の Firebase Hosting は「決まったメニューを並べておくだけのお店（中身が変わらないサイト）」向け。App Hosting は「Ch4で学んだキッチン（バックエンド処理）が必要な、注文ごとに料理を作るお店」向けの新しいサービスです。

GitHub = お店の「レシピブック」をクラウド共有

GitHub は、お店のレシピや調理手順（プログラム）をクラウドにまとめて保管しておくサービス。複数のシェフ（エンジニア）が同じレシピブックを共有・更新できます。

シェフ（エンジニア）が書いた新しいレシピを GitHub の main（正式版ページ）に push（反映）すると、管理会社（Firebase）が自動でそれを検知して、調理〜開店までを全部やってくれます。

GitHubのリポジトリ名を変更したため、Firebase App Hosting で 新しいバックエンドを作成して紐付け直した。…が、カスタムドメインの再接続を忘れていて、サイトが開けない状態になった。

教訓：厨房を建て直したら、看板も新しい厨房に向け直す

バックエンドは「厨房（キッチン）」、カスタムドメイン（new.e-mu-cloud.jp）は「お店の看板」。厨房を新しく建て直したら、看板も新しい厨房を指すように電話帳（DNS）に登録し直さないと、お客様は古い空っぽの厨房に案内されてしまいます。Ch3で学んだDNSの仕組みがそのまま当てはまる話です。