uokadaの見逃し三振は嫌いです

ここで述べられていることは私の個人的な意見に基づくものであり、私が所属する組織には一切の関係はありません。

Flaskを1ヶ月間使ってみた感想

2012年にpyconjpなどでFlaskを知ってマイクロフレームワークだし小さなサービス作るぐらいには使えそうって良さ気な印象をもった。

PyCon JP 2012 hands-on セッション/ FlaskによるWebアプリケーションの実装とプログラミングツール

それからしばらくして、RDBを使ってREST APIを作る話があったんだがそれにFlaskを使って苦労・失敗したって感想を書いていく。

  1. MethodViewクラスが使いやすい エントリポイントごとにMethodViewクラスを継承したクラスを作成して get/post/put/deleteメソッドを定義するとそれぞれGET/POST/PUT/DELETEリクエストに対応出来るのでREST APIを作るのはほんとうに簡単だった。

  2. リソース更新のためにPOSTを使わない
    API利用者のために更新もPOSTで受け付ける仕様にしたんだが実装始めた段階でやっぱり面倒くさいなって思ってしまった。 SQLAlchemyをORMな使い方してうまくやるにはこの方式はあんまり向いていなかった。
    REAST APIはPOST/PUT/DELETE/GETで作るようにすれば開発者も利用者も幸せになれるでしょう。

  3. Flask-SQLAlchemyが使いにくい。
    Flask-SQLAlchemyについてもあんまり参考になるような利用例がなくてサンプル以上の使い方をするのが難しい。素のSQLAlchemyを使ったほうが柔軟性が高いし他のバッチ処理とかでもコードを流用できるので拡張はなるべく使わないほうがあとあとウレシイんじゃないかな。

  4. Blueprintのドキュメントがあんまり無い
    しばらくしてコードが成長してくると1つのスクリプトでは大きすぎるように感じてBlueprintというコードを分割するモジュールを使いたくなるんだがこれもドキュメントが無くてどうやって使っていいのかコード読んだりして使えるようになるまで手間と時間がかかる。オレはBlueprint使った分割をあきらめて1ファイルに無理矢理収めてしまった。

  5. テストのやりかたがわかりにくい
    3,4,5 に関しては全般的にドキュメント/サンプルコードが少ないってことに帰結すると思う。Flaskはまだまだ利用例が少ないからこれからこの辺りのセクションの情報量が増えることに期待したい。

  6. DELETリクエストでパラメータを受けとれない 実装をはじめるまで気づかなかったので削除するタイミングでリソースを変更する仕様を採用しているとあとで困ることになるので知っておいて欲しい。

SQLAlchemyに関してはちょっと利用したことがあるだけの知識で使ってみたので的が外れてたかもしれない。けど、初心者でFlask + SQLAlchemy で何か作るってときにはハマるかもしれないので書いておいた。

2012年はFlaskを使っていろいろ経験できたので、2013年はFlaskは使いつつもよりも機能が充実したDjangoを使って新しい経験を増やしてみようと思います。

今年もよろしくおねがいします。


Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)