はじめに

本稿は、
SvelteKit + FastAPI + vercel + heroku でやる気があれば誰でも簡単フルスタックエンジニア (前半戦)
の続きです。

前稿でやったこと

svelteKitで、フロントエンドを実装した
実装したフロントのソースを、vercelにあげてネットに公開した。

後半戦では、サーバーの実装に触れていきます。

(そして、毛色がわかったら、それをフロントに繋いてみよう！)

準備

サンプルをダウンロード

こちらをクローンしてください！
もしくは、上級者の方は、

tiangoloさん (fastapi作者の~~ヒゲ親父~~)　が公開している、Full-Stack用のプロジェクトテンプレートを使った方が、いいかもしれません！

この記事では、サンプルを元に説明します。

ダウンロードしたら、まず、README.mdの指示に従って、ローカルの環境構築を行なってください！。
(サーバはまだ実行しなくていいです。$ uvicorn ....の部分)

herokuに登録

前半戦での説明通り、herokuにサーバの実装をデプロイします。
ここで行うことは3つで、

herokuに登録
herokuで「アプリケーション」を作成
herokuで、PostgreSQLのデータベースを無料で貸与

です。

↑から、アカウントを作成 & ログインからの、

◆ Create new appを押して、

適当なアプリケーション名とサーバの置き場所を指定して、[Create app]

これで、herokuの母体の準備はOK。

次に、Resource > Add-onの検索窓から、「Heroku Postgres」を探す。 > 決定
Hobbyプランが無料です。

登録すると、Heroku Postresのコンソールに行けるようになるので、

コンソール移動 > Setting > Database Credentials > View credential で、
DBへの接続情報をGETできます。ここのURIを、サンプルソースコードの、/config/db_config.pyの、「ここにURI入れて！」部分に入れてください。
注意として、URIの先頭はpostgres: ですが、今回使うソースでは、postgresq;:と書き換えてください。

from sqlalchemy import create_engine
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy.orm import sessionmaker

engine1 = create_engine(
    "postgresql://...残りはそのまんま..."
)

pgadminのインストールと利用

DBの中身を覗くことは実は結構難儀します。そこで、pgadminを使って、可視化します。

この辺を参考にしつつ、pgadmin4をインストール

Serverを右クリック > Create > Server
すると、設定画面が出てくるので、先ほどHeroku Postgresで出てきたCredentialの情報を入れていきます。

Generalタブ
- Nameに、好きな名前を設定(pgadmin4上での、表示名になる)
Connectionタブ
- Host name/address に、「Host」の記載を入力(ほとんどの場合、ec2-から始まるやつ)
- Portに、「Port」の記載を入力 (ほとんどの場合5432)
- Maintenance databaseに、「Database」の記載を入力
- Usernameに、「User」の記載を入力
- Passwordに、「Password」の記載を入力。そしてセキュリティ意識高い系でもない僕たちのような人は、特別な理由がない限り、~~こんなクソ長いパスワード忘れるので~~下のチェックマークをONにして、入力を省略できるようにしとこう

Saveを押すと、左メニューバーに作ったDB接続が表示されるので、プルダウンしていきます。

{🐘 作った名前} > Databases > {Maintenance databaseの名前までスクロール} > Schemas > Tables　> 何も表示されないが正解

ちなみに、Databases移行に死ぬほどDBが並んでいるのは、Herokuが一つの接続に、複数のDBを登録して、その1つ1つをユーザに対して間借りする形でやってるからだと思われます。課金したら変わるのかな？

ここで、DB関連で、注意事項をいくつか。

低料金プランでは、最大接続数が決まっています。Hobbyはたった20接続しか確保されません。
「間借り」しているので、ちょっと重たいです。
登録できるレコードは、Hobbyで上限10000レコードです。上限を超えると、メール通知ののちに、1週間程度の猶予期間が始まり、そのあとは、消えるかなんらかの対処がなされます。

次に、用意しましたサンプルデータを突っ込みます。
./createtable.pyを実行すれば、あなたの用意したHeroku Postgres DBに勝手にサンプルデータを流し込みます。少量なので帯域とかは気にしなくて大丈夫。

python createtable.py
or
python3 createtable.py

そうすると、DBにデータを入れられるので、
早速、pgadmin4で確認してみましょう。

Table > どれかのテーブル(3つ入っているはず) > 右クリック > View/Edit Data > All Rowsで、
ユーザらしきものが2つ出れば成功です。

最後に、README.mdにも記載しております、起動シーケンスを実行して、サーバをあなたのPCで立ててみましょう。

uvicorn main:app --reload

を実行して、

INFO:     Will watch for changes in these directories: 
...
INFO:     Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)
INFO:     Started reloader process [27454] using watchgod
INFO:     Started server process [27456]
INFO:     Waiting for application startup.
INFO:     Application startup complete.

Application startup complete が出たら、事前準備はこれにて終了です！

Fast API実装

お待たせしました。インフラ整備は、さっきのでほとんど終わりです。
いよいよサーバの実装です。

流し込んだデータを見てもらえればわかる通り、サンプルでは、Twitterっぽいシステムを構築しようとしています。
FastAPIの魅力はなんといっても、その早さ (実装のシンプルさ) と速さ (処理速度的な) です。
ヒゲ作者の方が、「Flaskを意識して作った」と言うとおり、コードが直感的でわかりやすいです。

では、それらの機能を、実装とともにみていきます。
サンプルを見れば、初心者の方も実装のイメージがつくと思いますので、頑張ってみていきましょう。

リクエスト/レスポンスの実装

リクエスト/レスポンス　は、いわばAPIの窓口です。
窓口をしっかりしないと、APIというのはどんどん使いづらくなっていきます。

その点、FastAPIはかなり楽にリクエストの窓口を定義できます。
/api/twitter_modoki/__init__.pyの、このコードをみていきましょう。

/api/twitter_modoki/__init__.py

twitterModokiRouter = APIRouter() #一旦ここは気にしない

# .(メソッド名) ('{パス}', response_model={レスポンスの形式})
@twitterModokiRouter.get('/tweet/list', response_model=List[TweetResponseModel])
def 全てのツイートを取得するAPI( # APIの関数名が、自動生成ドキュメントのAPIの説明文になります。
    user_id: UUID = None, # クエリパラメータ。 型チェック(もしくは変換)・軽いバリデーションもしてくれる
    offset: int = 0,    # クエリパラメータ, デフォルト値を設定すると自動的にOptionalになる。
    limit: int = 100,   # クエリパラメータ
    session: Session= Depends(get_session)  # APIの開始時にget_sessionが呼び出され、終了時にはget_sessionのfinallyを実行する。
):
    try:
        .......

このコードで、以下の機能が実装されました

http://****/tweet/list　に窓口開設
窓口ではuser_id、limit、offsetの3つのパラメータを任意で受け付けるし、型チェックや、軽いバリデーションなども行う。(user_idはUUID形式出ないとエラーを吐く。limit, offsetは、数値型になりうるならパラメータから勝手に数値型に変形する。)
3つのパラメータは、任意である。(= ***　と書くと、その値がデフォルトになり、パラメータがOptional・任意になる)
窓口は、レスポンスの形式をTweetResponseModelの配列で返すように約束。
get_session関数(DBの接続を確保する関数、自作)を、レスポンスを返すまで取り回せるようにする。この例では、「APIが終わったら、DBの接続をきる」という実装がこれだけで済む。(詳しくは、get_sessionの実装を参照)

どうでしょうか。
これらの実装が、数行で済んでいることがまず驚きである。

では、サーバを起動して、

uvicorn main:app --reload

APIを呼んでみよう。

curl -X GET http://127.0.0.1:8000/twitter-modoki/tweet/list?user_id=12341234-1234-1234-1234-123412341234&offset=1&limit=10

or

(↑これは、Talend API Tester. 便利だよ.)

すると、こんなのが帰ってくる。

パラメータを指定しなければ、

curl -X GET http://127.0.0.1:8000/twitter-modoki/tweet/list

こんなふうにリストが帰ってくる。

これらは、データを「取得」するAPI、たいていHTTPメソッドは「GET」で定義される。
では、「POST」の実装はどうだろう。

# api/twitter-modoki/__init__.py
@twitterModokiRouter.post('/tweet')
def ツイートを1つ登録するAPI(
    body: TweetRequestBody, 
    # POSTメソッドの場合、このようにbodyに格納される予定のjsonオブジェクトの定義と結びつけると、
    # 勝手に必要な情報を構造体として抽出してくれる
    session: Session= Depends(get_session)
):
    try:

-----

# schema/request.py
class TweetRequestBody(BaseModel):
    text: str = Field(....
    user_id: UUID = Field(...
    reply_tweet_id: Optional[UUID] = Field(....

GETと同じく、引数部分に何やらものを書くと、POSTメソッドで頻繁に使われる「BODYパラメータ」を取得できる。
POSTメソッドは、以下のように、BODYに構造体を定義してリクエストを送出する。

通信経路を通る際は、BODYはただの文字列と化すので、サーバ側はその文字列を構造体に直すのに難儀するはずだったが、この実装は、TweetRequestBodyの定義にそう構造をBODYから勝手に作り出し、bodyに代入する。あれまー

サンプルでは、GET, POSTメソッドを使ったパターンを紹介したが、基本的にリクエスト/レスポンスのすべての実装は、これだけで賄える。

ドキュメント生成

fastapiの真なる強みとして、ドキュメントの自動生成機能があります。
やるべきことをやっていれば、ドキュメントの生成自体は非常に簡単です。

/docs をつける。これだけ。

生成されたドキュメントの、/twitter-modoki/tweet/listの記述がこちら。

さっきの、リクエスト/レスポンスの実装をやっていれば、実務レベルにも耐えうる立派なドキュメントが完成します。これで残業しなくて済むね！

これには、見た目以上にたくさんのメリットがあります。
色々言い換えながら説明するなら、こんな感じでしょうか↓

ドキュメントをわざわざ別で作らなくていい。
サーバーの実装ができれば、即座にドキュメントが生成される
フロントの実装者は、サーバと同じドメインにアクセスすればドキュメントが手に入る
ドキュメントと実装にズレが生じることがない！！！！！ (神)

デフォだと、swagger形式のドキュメントが生成されますが、
redocが好きな人は、/docs じゃなくて、 /redoc　とすればそうなります。スゴイネー

また、ドキュメント自動生成機能は、もちろんOFFにすることも可能です。

app = FastAPI(docs_url=None, redoc_url=None, openapi_url=None) #オフにする

##　ルーティング
apiのルーティングが簡単な方が、実装にも幅が出るし、バージョニングも楽ちんです。
FastAPIの、APIRouter、include_router()は、本当に楽ちんです。

main.py

from fastapi import FastAPI
from api.twitter_modoki.v1 import twitterModokiRouter as v1
from api.twitter_modoki.v2 import twitterModokiRouter as v2

app = FastAPI()

app.include_router(v1, prefix="/twitter-modoki", tags=['TwitterModoki'])
app.include_router(v2, prefix="/twitter-modoki/v2", tags=['TwitterModoki2'])

ちなみにmain.pyは、このサーバー実装のスタートポイントです。appというのが全ての母体で、appに紐付ける形で、routerというのをどんどん繋げていきます。
prefixの定義もできるので、APIをお手軽にグルーピングしたい場合は、
このサンプルみたく、バージョンでAPIを分けたい時にも役立ちます。
tagsは、自動生成ドキュメントのグループ名になります。

Dependenciesによる依存性注入

では、APIのv2バージョンで、v1よりセキュリティを強化したり、リクエストをしやすくしたりしましょう。依存性注入(DI)で。
DIってなに？って人も、多分実装を見れば言いたいことがわかります。

さて、v2では、簡単なセキュリティ要件に対応したようです。

フロントは、HTTPヘッダーに、user_idと、認証キー(authorization)が必ず入れる。
user_idがDBに存在するか、存在チェックをしないといけなくなった
authorizationが違うなら、APIにアクセスできなくなった。

これらを、DIで実装しよう。

実は、ここまでにDIっぽい実装が一つ登場しています。

session: Session = Depends(get_session)

此奴です。この、Dependsというfastapiのモジュールが不可思議奇奇怪怪な存在で、DIの魔法に簡単に誘ってくれます。

/api/twitter-modoki/v2.py

@twitterModokiRouter.get(
    '/tweet/list',
    response_model=List[TweetResponseModel],
    #これにより、2つの関数がAPI処理実行前に必ず行われるようになった。
    dependencies=[Depends(required_header), Depends(required_authorization)]
)
def 全てのツイートを取得するAPI(
    #user_idはHTTP Headerからとる。 
    # A = Header(...)で、ヘッダーからカラムAを勝手に探して取る。
    user_id: UUID = Header(...),
    offset: int = 0,
    limit: int = 100,
    session: Session= Depends(get_session)
):
    try:
        .......

次に、dependenciesに紐付けた2つの関数の実装をみてみよう。

/api/common/authorization.py

from fastapi import Header, HTTPException
from sqlalchemy.orm.session import Session
from model.UserModel import UserModel
from config.db_config import SessionLocal
from uuid import UUID

def required_authorization(
        authorization: str = Header(...)
    ):
    if authorization == 'fast-api-token-barebare':
        pass
    else:
        #キーが違うなら、リクエストをRejectする。
        raise HTTPException(status_code=432, detail="Access invalid")

def required_header(
        user_id: UUID = Header(...)
    ):
    session: Session = SessionLocal()
    try:
        #get()によって、該当するidをもつユーザが0つ、あるいは2つ以上取れた時、エラーを吐く。
        session.query(UserModel).get(user_id)
    except:
        #ので、リクエストをRejectできる。
        raise HTTPException(status_code=432, detail="Access invalid")
    finally:
        session.close()

こんな感じ、単純に、要件にそうチェックを走らせている。
おそらく上級者の方は、「Header(...)ってこんなとこまで来ても中身引っ張れるんだ。。。」と驚愕かもしれないが、できてしまうものはできてしまうのである。

これらが通れば、API関数の↓の部分

# A = Header(...)で、ヘッダーからカラムAを勝手に探して取る。
    user_id: UUID = Header(...),

でHeaderからuser_idをとってもOKという感じである。

Headerに必要情報を記載して送信。これで、v2の要件達成である。

そして、この構文なら、

dependencies=[Depends(required_header), Depends(required_authorization)]

この記述を他のAPI関数にペチペチコピペするだけで、認証をかけたいAPIに同じ処理を実装することができるのです。

補足説明

初心者向けに、このサンプルが構成についての説明欄を設けました。

/api
- 窓口です。窓口の説明や機能は、おそらく今までに紹介した機能で十分だと思います。
/service
- /apiから、1:1対応で呼び出します。いわばAPIのメイン処理部分。
- /repositoryと組み合わせて、DBから欲しい情報を整理して、レスポンスの型に沿ったデータを作り出します。
/model
- サーバでいうModelとは、データベースに入ってるテーブルの定義の写し鏡です。
- SQLAlchemyというORMマッパ(写し鏡をやってくれるライブラリ)を使っているので、ORMマッパのルール通りにModelを実装しています。
/schema
- リクエスト、レスポンスの型を定義しています。/apiでも頻繁に使っているので、おなじみかと。
/repository
- /DBにやらせたい操作を、汎用性持たせつつ書いてます。
- /serviceから共通パーツを切り分けた・と捉えてもいいでしょう。
/config
- 各種設定。