Phase 2: バックエンドに使われる技術たち
さきほどから少しずつ触れていますが、 バックエンドに使われる技術たちを見ていきます。
バックエンドの処理そのもの
バックエンドの処理そのもの(Webアプリケーションの中心的なロジック)は、 任意の汎用プログラミング言語で記述できます。
といっても、言語の向き不向き(レイヤ的な書きやすさやライブラリの充実度合い)はあるので、 実際には選択肢はもう少し限られますが、 逆に言えばある程度の条件が合えば何を使っても良いわけです。
今回は TS を使います。 フロントエンドでも使われる言語で(今回の研修のフロントコースにも登場)、 学習者にとって知識の流用が効いて嬉しいので実際の現場でバックエンドに使われることがしばしばあるからというのが1つの理由です。 また、jsysでも今年度開発しているプロダクトでいくつかはバックエンドにTSが採用されており(SOS, TanPoPo等。詳しくは現役生に聞いてね)、 学習することですぐに役に立ちやすいからということも考慮しました。
コラム: どんな言語が使われているか
現代でバックエンドに使われている可能性がそれなりにある言語というと、
- Node.js (TypeScript等)
- PHP
- Ruby (Ruby on Rails)
- Java
- Go
- Rust
あたりじゃないでしょうか。
クライアントとのデータのやり取り
HTTP
現代のWebでは、Phase 1 から度々登場している通り、HTTPという通信プロトコルが使われます。
ブラウザのURLバーに表示される http:// とか https:// とかのあれですね。
URLにおいて<プロトコル名>://とあったら、そういう名前のプロトコルで通信していますよ、という意味です。
HTTPSはHTTPに外からTLS暗号化をかけたもので、つまり中身はHTTPです。
HTTP自体は原理的には大変シンプルなプロトコルで、現代のWebとは言わずとも1990年代のWebから使われています。
GET /messages HTTP/1.1ヘッダ...ヘッダ...
ペイロード...という感じに、/messagesというパスからデータをGET(メソッド)したいよ、というふうにリクエストするだけです。
ヘッダには取り決められたメタデータや任意のメタデータを詰めることが出来ます。
重要なのはペイロードに任意のデータを詰めることができる点(レスポンスも同様)で、 データを送りつけたかったら、予め相手と定めておいた任意の形式のデータをここに詰めれば良いわけです。 大変何でも出来そうですね。
そういうわけで、HTTPはシンプルかつ自由な拡張性を備えているために長らくWebの世界の標準プロトコルであり、 ブラウザはHTTPをおしゃべりすることになっており、 フロントエンドのファイル取得も、バックエンドとのデータのやり取りもHTTPに載せて行われるのです。
REST API
データを送りつけたかったら、予め相手と定めておいた任意の形式のデータを
と先ほど言いましたが、あるWebアプリケーションを作るときには、 フロントエンドとバックエンドの間でやり取りするデータの形式を予め定めておく必要があります。
だから、Web API は API (Application Programming Interface; つまり、定められた形式でやり取りするためのインタフェース) なわけですね。
近年のWeb APIの多くはJSONのような形式で、そのうえで独自のスキーマを定めて運用されることが多いです。
例えばSNSでメッセージを取得すると以下のようなデータが返ってくるという、イメージです。
{ "id": "a3070467-a078-4448-b72b-6cd2d4d1b065", "user_id": "db078812-e6c8-45cc-b332-7ea47f8ae9ee", "message": "こんにちは!\n今、何してる?", "created_at": "2026-06-06T13:00+09:00", "like_count": 3}なお、Web APIに関連してたまにREST APIという語彙が登場します。
正確には様々な主張があるのですが、 HTTP上でHTTPメソッドとパス(エンドポイント)の組み合わせで上手くリクエストの種類を設計し、 JSONなどの形式でやり取りされるWeb API, くらいの気持ちでいてくれればとりあえず大丈夫です。
データベース
色々あります。
データをテーブルの形で保存するリレーショナル・データベースというものが多く使われ、
SQLというのがその代表的な例です。
SQLにも(標準はあるものの)更に様々な実装があり、それぞれが標準をある程度満たしつつ独自の拡張を加えたりしています。
- MySQL (今回使います)
- PostgreSQL
- SQLite
などなど…
なお、データベースの操作をバックエンドの処理そのものを記述する言語から行いたいわけですが、 ここにもライブラリによる適切な抽象化が提供されています。
SQL文を直で書くようなものもあれば、データベース側でのデータ表現を汎用言語側のデータ構造にマップするORM(Object Relational Mapper)というものもあります。 今回使用するDrizzleはTS用のORMライブラリです。