はじめに

WARNING

書きかけです。

1. この記事の目的

二部に分かれています。

第一部「Flask の仕組み」では、まず Flask の機能の概要を復習します。 次に Flask の内側を探検、仕組みを見ていきたいと思います。

第二部「Flask の環境構築」では Heroku にデプロイしながら、バックエンド周りを見ていきます。

  • DNS(独自ドメイン)
  • CDN(高速化)
  • SSL/TLS(https に対応)
  • OAuth(Twittter, GitHub アカウントでログイン)

1.1. Flask のしくみ

下記以外にも取り扱うのですが、とりあえず雰囲気だけ伝わりそうなものをピックアップします。

(1) コンテキスト

Flask の肝はコンテキストです。 基本的にグローバル変数で取り扱っていきます。 これが癖でありなかなかの引っかかりどころです。

(2) 複数の起動方法

その他の引っかかりどころとしては flask run した時と app.run() した時で パスが変化してしまうことです。

基本的な考え方としては flask run だけ使い app.run() は使わない方がいいかなと思いました。 app.run() を使うと沼にはまります。

ただ、このページでは動作例を示すサンプルコードで app.run() を使っています。 app.run() の方が対話モード >>> でコピペで動いて楽なので。

1.2. Flask の環境構築

Heorku にデプロイするチュートリアルをよく見かけはするのですが、 HTTPS に対応していなかったりします。

近年の SEO では HTTPS 対応は必須です。 なぜなら Google が また HTTPS 対応していないとブラウザに危険!と表示されてしまいます笑

Chrome で表示させた時にこのサイトは危険みたいなことを全画面で表示された時は、 そこまでやらんでも... と思って笑ってしまいました笑

また他にも Twitter, GitHub アカウントでログインさせたいし、 せっかく買ったドメイン名には CNAME Flattening もしたいです。 CDN でアクセスの高速化もしたいです。 そんなことをここではやっていきます。

  • SSL/TLS
  • OAuth
  • DNS (CNAME Flattening)
  • CDN (Cloudflare)

2. この記事の対象

巷でよく売っている Flask 入門を終えたくらい。 SQLAlchemy は使いません。

WARNING

ここまで妄想。そして、ここからも妄想。

3. Flask を学ぶ意味はあるの?

あんまり無い。できれば、触らなくていいなら触らない方が良い気がします。 すでに Flask を触っていて、もうひと押し触って見たいという人のための記事です。

と思ったのですが 2019/6/9 現在、まだ結構、普通にハッカソンでも使われてる。

3.1. 駆け出しエンジニアの方へ

ウェブをやって見たいと思われる駆け出しエンジニアなら特に避けた方については。

大手の学習サービスでは Flask も取り扱ってくれていますが、 かっこいいウェブサービスを作りたいと思っているなら Python は触らない方が良い気がします。

Vue.js という JavaScript フレームワークの勢いが強そうです。 とりあえず Vue.js と Firebase で作って、遊んだ方が思ったものが作れる気がします。 それにそっちの方がいくらか楽しいかなと感じます。

もしどうしても使いたいなら Flask よりも Django の方が良いです。 なぜなら日本語の情報が Flask よりもあるからです。 Django も情報は少ないですが、Flask はもっと少ないです。

3.2. 駆け出しエンジニア以外の方へ

ASGI が必要になるシーンとはそんなにないとは思うのですが、一大潮流です。 現在 WSGI から ASGI へと進化しつつあります。

Django は ASGI への対応が完了しつつあるようですが、 Flask は @methane さんのいう通り、活動があまり活発ではありません。

これを現在の Local Context から async, await を前提にしたコードに書き換えるのは、 かなり作業ボリュームがあるのではと想定されます。

Does werkzeug have plans to support ASGI?
Yes, Werkzeug and Flask will eventually support ASGI. I do not have a timeline for this, although I would be happy to help review a PR if someone started one.

ASGI タグがつけられたものが、1年前から更新されていません。

Flask のようなマイクロフレームワークを、新しいものに手を出すのも危険です。 しかし Flask を使い続けるのも安心という感じではない気がします。

Responder, FastAPI などの ASGI 対応ウェブアプリケーションフレームワークに手を出すのが賢明そうです。

4. Flask と Django

4.1. 雰囲気の違い

Armin Ronacher は、イケメンです。 天才かつイケメンなんて羨ましい限りです。 Flask は、この人によって生み出されました。

Django というウェブアプリケーションがあります。 Flask が自由なのに対して、Django はもうすこしガッチリした印象です。 Flask がイケメンなら Django はマッチョな感じです。

Django Girls があるのに Flask Girls はありません。 Django Girls という言葉を見て、 いつも思うのは Flask Girls はないんだろうって疑問でした。 ま、どうでもいいんですが。

Django のどの辺がマッチョかというと、全てオールインワンなところです。 全部の機能がはいっていて、それを使います。 使うものが決まっているので、書き方も定まっている印象です。

反面 Flask は、必要な機能は最小限で自分で pip install したりします。 また request オブジェクトを flask というグローバル変数から取り出すところも 自由な感じがします。

自由っていうといい感じがしますが、ふわふわしていてどうしていいかわからないところがあります。 Django も Flask も一長一短です。

少佐 「でもロボットを買って自分好みの彼女にしようなんて発想からしてマッチョよね。気に入らないわ」
トグサ「マッチョ!?少佐が言うなよ」 攻殻機動隊 STAND ALONE COMPLEX 第 3 話 ささやかな反乱

4.2. 需要の違い

Flask は、国内ではデータサイエンス系の人たちが、 簡単なバックエンドを作るために使われているのを Qiita で見かけます。

それ以外の用途では大抵国内では Django が主流な気配があります。 Django Confarene などもあります。 Flask とかもどこかでやっているのかもしれません。

Flask は後続ながらすこしずつシェアを伸ばしている印象があります。 JetBrains 社の調査があります。

こちらは PyCon の時の口頭での質問結果。

[* 質問1]
 Pythonの [Webフレームワーク]、何を使ってる?
  1. [Django] -> [* 50人]
  2. [Flask]  -> [* 40人]
  3. その他    -> [* 5人] -> [Bottle] 4, [Tornado] 1

これらの数値を見ると Django と Flask が半々に見えるのですが、 それでも Flask の情報は日本語では Django に比べるとあまり見かけない気がします。

いくらか Flask が切り返してきた背景としては、 おそらくこれは SPA, Single Page Application の関係があるかと思われます。

このツイート本当に助かりました。ありがとうございます。

Flask には JSON だけ返すようにして、 あとの表示は JavaScript に任せるような設計になります。

Flask, Django についている template は使わない感じです。 最近は SPA の流れが強らしいです(Twitter 調べ)。

それでも Django RESTfull API とかあるので、 まだよくわかってはいないのですが。

4.3. Laravel

当初 Ruby の Rails が失速して PHP の Laravel が勢いを得ているのを見て、 Flask もポジション的には厳しいかなという気がしました...

Python の世界では小さい Flask が勢いを盛り返して、 PHP, Ruby の世界では Rails よりも自由度の高い Laravel が勢いを得たのが理解ができませんでした。

Rails がダメというわけではないのですが、 どうもあまりにも JavaScript, CSS フロントエンドと蜜につながりすぎて辛いという記事やつぶやきを見かけました。

前述の通り SPA が勢いを得つつあり、フロントとバックエンドが分離しつつある流れを感じます。

が、前述の通り Flask はすこしずつ勢いを伸ばしています。 これは SPA の流れがあるかと思われます。

ただ SPA 狙いなら個人的には FastAPI の方が良さそうな気配を感じます。 ASGI への対応も、おそらく遅れそうな気配を感じるし。

5. フレームワークの動向

こんなの売ってるんですね、欲しい、お高そう...

SPA の流れがあるからじゃあ Flask なのかというとそうでもなく、 基本的な GitHub 上での開発は緩やかな気配を感じます。

代わりに FastAPI というのがとても勢いを感じます。

Flask は WSGI という仕様でウェブサーバとやりとりをするのですが、 最近は ASGI というものが策定されているらしいです。

Flask のコミッターの方曰く Flask も ASGI に対応していくよ! と書かれていたのですが、 そこそこ大きい改修が必要になるんじゃないかなと思ったり、思わなかったりします。

responder というフレームワークが出たのも見てはいたのですが、 関数型言語の良さが叫ばれる昨今 return 文が無い形式、 状態を書き換える形式は個人的に嫌だったので、見ていませんでした。

また PHP の Laravel ライクな Mesonite という Python の フレームワークが出ました。 Mesonite が勢いを得て Laravel と対抗したりするのかなと思ったりもしました。

しかし GitHub の活動は頓挫してしまっています。 Django があるからもういいということなのでしょうか。

この辺りのことを踏まえると、 もし Python のウェブアプリケーションに手を出さないといけない状況に追い込まれたらな、 FastAPI が望ましい気配を感じます。

確かに Laravel は爆発的な人気を得たのですが、PHP という言語そのものはどうも低下傾向にあります。

上記のつぶやきのおかげでその辺の雰囲気みたいなのがなんとなく、ほんの少しだけ見えました。 FastAPI は、ええなと思ったのですが、あまり GitHub 上のスター数とかの伸びが、 若干イマイチでした。

そこまで無理くり FastAPI に手を出す必要性は低そうです。 その辺のことを踏まえるとなるべく FaaS がいいかなと思いました。 まあ、とはいえ FaaS だけなら WSGI となんら変わりないのですが...

その辺りのことを踏まえると ASGI に絡むことをしない限りは、 FastAPI に手を出すメリットがないか... まあ、かといって FaaS だけでも得るものなさそうだしな...

バックエンドもそれなりのトラフィックさばくところに行かないと、 あんまり面白いことはできないかもしれない。

6. Flutter, ReactNative について

個人的な能力の低さから iOS/Android は切っていました。 このつぶやきも本当に助かります。

このつぶやきも、本当にありがたかったです。 口語で伝えてもらうと肌感覚が、なんとなくわかった感じになるのなんだろう...

クオリティ高いのはネイティブアプリだからやってみたい思いはあるけど、自分の能力を鑑みて...

7. おわりに

以上になります。

Last Updated: 6/19/2019, 6:53:33 PM