DjangoとFlaskについて

The pen is mightier than the sword.

sample graph

DjangoとFlaskをどちらも使ってみた感想

Pythonをやるようになってとりあえず、FlaskとDjangoを一通り試してみたので感想を記載しておこうと思う。
よくあるDjango vs Flaskの巷で溢れてる簡単な比較ではなく、どちらも動かしてみた経験を元に、実際にサービスを作っていく事を踏まえ考察する。

私は最初Flaskから始めた訳だが、理由は色々なサイトを見た時にディレクトリの数が少なくエラーになりにくいと思ったからFlaskから始めた。

今振り返って考えてみるとそれは大体当たっていたと思う。
インターネット上に転がってる記事を見ながらサイトを構築していく際に、ディレクトリの構造は実は結構ネックになる場合が多い。

何故かと言うと、殆どの記事はどうやって問題を解決するのか書いてあるんだけど、ディレクトリの構造まで書いてある記事はまれだからだ。
参考にした記事と同じようにプログラミングを書いて、実際プログラミング文にはエラーが無くても、ディレクトリの構造がそもそも違っていて動かないという事は多々ある。

そういった点においてFlaskから始めるのは悪くない選択だと思う。
その後、Flaskで動かせた事に満足していた訳だが、目標の一つにPythonのCMSを動かしてみたかったので、
下地に使われているDjangoをしょうがなくやる事になった。

Djangoを最初に触った時の感触としてFlaskと比べるとえらくファイル数が多くてもっさりしてるなと言うのが最初の感想だった。
それからDjangoのマイグレーション、MTVを理解して動かすためにFlaskで作ったサイトをDjangoに移植しながら触っていくのだが、
サーバー上でマイグレーションをやるところで少し詰まった。
更に非同期のPythonとJavascriptのデータのやり取りでCSRF対策をするところでも詰まった。

サーバー上のマイグレーションに関してはローカルと同じようにサーバー上のコンソールでマイグレーションを
コマンドを使用してやろうとしてたからで、それは自分の経験不足もあるのでしょうがないと思う。
(多分、その方法でも出来ると思うけど、通常の方法よりもかなり時間がかかると思う。)
この種の経験豊富な人はここはあっさり出来る可能性は高い。
非同期のCSRF対策に関しては、ディレクトリの構造がここでもネックになった。

振り返ってみて、非同期のパターンのCSRF対策のやり方を分かりにくくしてた理由は、
最初は、PHPみたいなやり方でワントークンを渡せるものだと思っていて、
その方法を調べていた為で似たような解決方法が検索しまくっても出てこなかった。

次にFetchでワンタイムトークンを渡す際に、Bodyに付けてもHeadに付けても動いてしまうので、
参考のサイトを調べても別々のやり方が書いてあり、それがらが問題の解決を分かりずらくしていた。
(こういうの問題を考えるとルビーの様に、問題を解決するのに色々なやり方があった方が、
より良いとする設計思想には疑問が残るところだ。)

そして一番の理由は、同期を飛ばしていきなり非同期のCSRF対策から始めたので、
所謂MTVのディレクトリ構造のパターンに準拠した構造になってなくてエラーになっていた。
非同期で何回やっても動かないので、同期のCSRF対策を調べてみたらMTVを利用するやり方しか書いてなかった。
そこで、非同期のCSRF対策もMTVのテンプレートを使わないと出来ないんじゃないかと思って同じようにやってみたら動いた。

前置きが長くなってしまったが、このようにDjangoはFlaskに比べると少し面倒どころではなく、
最初はそこそこ面倒になる事を覚悟した方がいいと思う。
構造は多少複雑なだけなのでプログラミングを理解できる人には直ぐに理解できると思うが、
最低限CSRFのセキュリティが求められて、それにはMTVと言うDjango流のやり方がある。
(Djangoでもやろうと思えばCSRF対策を無視して動かせるが、初期レベルで要求される敷居が高いと言う旨をここでは明記したい。)


ただ、本番環境でどちらかを選べと言われたら迷わずにDjangoと答えると思う。
色々なサイトで言われてるようなFlaskとDjangoは対立の構造にすらなっていなくて、
最終的にはサイトを本番環境で使うにはどのサイトも基本的にはDjangoにしないといけないと思う。
一番の理由はFlaskだと構造上、動的に処理するページ数が数十を超えた段階でかなり複雑になってしまう。
100まで行くとFlaskがDjanogよりも優れている点は殆どなくなってしまう。

要するにサイトで動的に処理をする所が増えれば増えるほどDjangoにしないと構造がどんどん複雑になって行きやすくなるのだ。
それの分岐点が数百ならまだFlaskを採用する理由になるんだけど、数十くらいで頭落ちになると言う事は経験上、
本番環境でFlaskを選択するのはメリットよりも遥かにデメリットの方が上回ってしまう。

それと、今ま経験豊富で色々なサイトを作ってきた人達のみしか、関わらないとかなら良いんだけど、
最低限のセキュリティはクリアしておく必要はあると思うので、その点でもDjangoを選択したほうがいいし、
SQLに接続する箇所の記述なんかもDjangoの方が書く場所を決められているので分かりやすく保守性が上がる。
あとは、MySQL系を使うならマイグレーション出来る点もDjangoの方が良い。

更に言うと、Djangoで作ったプロジェクトをFlaskのプロジェクトに移植するのは、やろうと思えば出来ると思うけど、
逆にFlaskで作ったプロジェクトをDjangoのプロジェクトに移植するのは後々かなり面倒になる。

なのでFlaskを選ぶ際は練習環境で慣れるために使う場合か若しくは、
どうしてもFlaskにしなければいけない理由がある場合かのどちらかだろう。
正直、実際総合的に比較してみるとFlaskは、手軽さ以外の良い点が殆ど見当たらない。

誤解を恐れずに行ってしまえばDjangoはターボエンジンみたいなものだ。
Flaskが優れている点は全くどちらもやった事のない初見の状態で、サイトを動かすまでの最初のスピードが速いと言う点で、
拡張性、セキュリティ、保守性等の面でDjangoの方が優れているので、やればやるほどDjangoの方が学習効率も上がってくる。

以上の理由から、ファイル数が増えていくとDjangoがFlaskの上位互換的な性質があり、
その性質はMySQLとSQLiteの構造にも似ているので、本番環境ではDjangoを採用すべきだと思う。

Camity