kawaken’s blog

Flaskを１年仕事で使った感想

16:33 |

「Flaskの使いどころ」を拝見しました。

Flaskを業務で使用してますって話があまりないようなので（ちゃんと検索してないけど）一つの事例として書いておこうと思いました。

ただ、一般的な開発環境ではないと思うので、あまり参考にならないと思います。アンチパターン的な感じでしょうか…。

別にFlaskを批判するつもりもないです。

先に感想

MicroFramewokと謳ってるので自分で拡張していく前提で使い始めたけど、拡張していった結果「Flaskじゃなくて良かったんじゃね？」と、今になって、システムの規模に合ってなかったなというのを感じます。

でも、どのフレームワーク採用してても、そのフレームワークに起因する課題は出てくると思いますが。

以下、詳細です

○開発の状況

今運用してるのはB2Cのサイトです。規模感としては中規模？かな。DBのテーブル数でいうと、３０くらいあります。

開発者は私だけです。僕自身はPythonを触り初めて３年くらいです。敏腕プログラマでもないし、普通のレベルだと良いなって感じです。

○開発前

開発は１人なので自分の開発スタイルに合いそうなもので、小さいフレームワークを探してて、Flaskにしました。

その時の先入観として、

・小さいフレームワークの方が学習に時間がかからない

・足りない機能は拡張していけば良い

というのがありました。

コードも多くないし、何かあったらコード読んで理解すれば良いかなと思っていました。また、Flask-**みたいなエクステンションもぼちぼちあったし、それを使ったら良いと思っていたし。

○開発やってみて

・小さいフレームワークの方が学習に時間がかからない？

Flask自体の学習はそんなに難しくないです。

でも結局、SQLAlchemyとかjinja2とか、システム全体動かすために必要な他のフレームワークなりライブラリがあるわけで、全体的な学習というのはけっこう大変でした。

特にSQLAlchemyはリレーションの辺りが良くわかんなくて、SQL書いて、from_statementでやってたし。（SQL書くの好きなので）

・足りない機能は拡張していけば良い？

1.エクステンションについて

最初は、エクステンションを使ってました。Flask-SQLAlchemyとかFlask-WTFとか。でも、こんな感じで、

from flask import Flask
from flaskext.sqlalchemy import SQLAlchemy

app = Flask(__name__)
app.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:////tmp/test.db'
db = SQLAlchemy(app)

使用する前提として、appを渡してあげないといけない。

Flask関係ないバッチ処理とかで困ったので、結局エクステンションは使わないようになりました。唯一Flask-Mailだけ使ってます。

2.Blueprintsについて

最初はModuleだったけど、途中からBlueprintsに変わりました。ちょっと残念なのは、staticとかtemplateとか個別に管理できるっぽい雰囲気がありつつ、実際分けて管理できなかったりとか。使い方が悪かったのかな…。

例えば、

modA/templates/index.html
modB/templates/index.html

という二つのファイルがあったときに、

modB = Blueprint('modB', __name__, template_folder='templates')
@modB.route('/index')
def index():
    return render_template('index.html')

で、modA/templates/index.htmlが表示されたりします。

あれおかしいなと思ったんですが、詳しくはこの辺に書いてあるんですけど、

modA/templates/modA/index.html
modB/templates/modB/index.html

という構成にして、

modB = Blueprint('modB', __name__, template_folder='templates')
@modB.route('/index')
def index():
    return render_template('modB/index.html')

という感じにしないといけないみたいです。それblueprintごとに分けた意味ある？みたいな…。

結局、テンプレートは統一のテンプレートフォルダに入れて管理するようにしました。

それとpythonのモジュールとして分けて管理しているのは継続していますが、blueprintととしては使用していません。

3.PluggableView（ClassBasedView）について

他のフレームワークのClassBasedViewを触ったことないので比較できませんが、継承して、必要な部分だけオーバーライドして使えるって点が良いんじゃないかなと思います。

でもPluggableViewにして、add_url_ruleをいっぱい書かないといけなくなりました。

デコレーターでURLマッピングできるのが良かったんじゃなかったっけ…みたいな矛盾。

○そんなわけで

最終的に、拡張をどんどんとしていって、オレオレ感満載のコードになり、Flaskをベースとした何かになってしまいました。これは僕自身の反省点です。

適材適所って…

じゃぁFlaskってどの辺に向いてるんだろう…と考えたのですが、やっぱり規模が大きいのは向いてないと思います。

「Flaskをプロジェクトに合わせて拡張していく」というのもありなのかもしれませんが、それだったら、werkzeugとかwebobの辺りからやった方が良いんじゃないかなとも思います。別にFlaskじゃなくても…というのはその辺です。

以上です。