Last Updated: 2/6/2024, 5:44:57 AM
Image by flask.pocoo.org

# Flask ってなに？

WARNING

書きかけです。

WARNING

完全に妄想です。

# 0. その前に...

Flask にはあまり手を出さない方が良い気がします。詳細は後述しますが、ざっくり概要だけ。

国内のウェブなら PHP と Ruby って話やろ？、思われるかもしれません。 実はそれとは違う流れの話になります。

バックエンドの役割が薄くなりつつあり、 フロントエンドとインフラの分離が進んでいる気配があります。

フロントエンドの方は TypeScript/JavaScript を使って Firebase, AWS Lambda, AWS ECS などを使われている方が多い気がします。

バックエンドの方は Go を使われている方が増えている気がします。

機械学習やディープラーニングを使われると Python からは逃げられなさそうです。 サーバを切り分ければいいだけの話ですが、分けるのも面倒ですしね。

もし負荷が気にならないなら Flask は使わずに Firebase 等の BaaS を使って JavaScript で組んだ方が良い気がします。 もし負荷が気になるなら Flask は使わずに AWS Lambda 等の FaaS を使って Go で組んだ方が良い気がします。

マイクロサービスの記事を見かけるとき、大抵は Go が使われているからです。 ただ、機械学習, ディープラーニングを扱う場合は Python が使われています。

大量のトラフィックをブンブン捌きたいときは Go がベターな気配があります。

クラウドのお値段が気になるなり、かつ JSON をやり取りするだけの API サーバの様なものが欲しいなら、 さくらインターネットなどの VPS で Flask を使ってもいいかなという気がします。

この記事は Python でウェブサーバアプリケーション書きたいよ！って人のための記事です。

# 0. お仕事リスト

  1. まずお仕事の領域が大きく３つに分断されています。
  フロントエンド <-> バックエンド <-> インフラ

フロント ... HTML, CSS, JavaScript,...
バックエンド ... PHP, Ruby,...
インフラ ... Nginx, Apache, MySQL, ...
  1. フロントエンドはもうちょっと分かれていて...
  ランディングページ <-> ウェブアプリケーション

ランディングページ ... jQuery, ウェブ制作, ホームページの作成, ウェブ広告の作成
ウェブアプリケーション ... Vue.js, Angular, React, Progate, teratail のようなデータベースと連携のあるサービス

# 1. Flask ってなに？

Python のウェブアプリケーションフレームワークです。

# 2. フレームワークってなに？

ウェブアプリケーションフレームワークとは、 ウェブサービスを作る時によく使う関数をまとめたものです。

# (1) 流れ

ウェブアプリケーションの流れは、以下の様なものです。 (1)リクエストを受けて関数を起動する。(2)データをやり取りする。(3)結果を返す。

# (2) サンプル

MVT のサンプルを提示します。 ただし、ここでは何故 Flask を使わない方が良いのかの説明をするためのものです。 適当に読み流してください。

# (3) WSGI

# 3. サーバレスってなに？

FaaS と mBaaS を組み合わせたものらしい。CNCF なんてものがあるのか... 用語の定義はこの辺から引っ張ってこよう...

簡単にいうと、サーバーレスコンピューティングとは、FaaSとBaaSのいずれか一方か両方を指すという定義になっている。
サーバーレスアーキテクチャ再考 - ゆううきブログ (opens new window)

サーバレスの流れが強い気配を感じます。 サーバレスというのはサーバが無いわけではなく、 意識しない程度の話だと個人的に理解しています。

例えば Python ではウェブサーバからウェブアプリケーションフレームワークを呼び出すために WSGI を定義しています。 Flask を uWSGI から呼び出すと以下の様になります。

サーバレスにすると uWSGI の部分を意識しなくてよくなります。 サーバレスをサーバレスのまま理解できる人が羨ましい...

# Python はオワコンなのか。

反面、フロントエンドよりの方は、サーバサイドでも JavaScript, Node.js を使っていきたいと言われているのをよく目にします。

# 反論

なんだよ、じゃあ Flask でもいいんじゃ無いの？って話なのですが、 例えば AWS では Chalice という Flask の様な専用のフレームワークを用意しています。

Chalice は、各種 AWS のサービスと連携するための機能を備えています。 ここに画像付きのチュートリアルがあります。いや、凄い...笑

Amazon が専用の Chalice というものを用意してくれているなら Flask を頑張って使う必要性があるのかと 聞かれるとちょっと厳しい気がします。ちゃんと調べきれていないのですが。

サーバーレスのメリット＆本質を、AWS Lambdaを使って理解しよう (opens new window)

サーバーレスアーキテクチャには、デメリットもあります。

サーバーレスでは、基本的にはクラウド依存が前提になります。 クラウド事業者の設定している上限を超えるような使い方はできませんし （Lambdaの場合、同時実行数などに制約がありスケールが難しい場合もあります）、 まれにサーバーレス環境自体に障害が起きることもあります。

そのため、あらかじめ特定のサーバーレス環境に依存しない設計で作っておくことが重要です。 本稿でも、ハンズオンの途中で「コードを良くする」工程を入れ、 AWS Lambda以外の環境でも使える設計を目指します。

ウェブサーバのことを考えるのは面倒だから、 関数だけしか考えていたくない人のためのものです。

# BaaS

あるいはデータベースなどの BaaS があります。 Google が買収した Firebase などが良い例です。

# FaaS

HTTP リクエストが来た時に関数を呼び出す FaaS があります。 Amazon Web Services(AWS) の Lambda, Google Cloud Platform(GCP) の Google CloudFunctions, Microfost Azure の Azure Function が該当します。

負荷が気にならないなら BaaS で済ませて、 負荷が気になるようなら FaaS で対処していく様なイメージだと思い込んでいます。

# 傾向

この動画が本当に参考になります。

お二方ともフロントを避けられている。

このつぶやきも本当に助かります。

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

フロントは競争が激しくなりそうな気がする。 フロントの方が人がたくさんはいってくるみたいな噂をどこかで聞いた。 デザインとかの方がカッコいいイメージあるし、 すぐに画面が動いてわかりやすいし、女性も入りやすいからかな...

インフラはつまんないし、面白みもないからな。 黒ひげ危機一発的なドキドキ感しかない... ハートはドキ土器...

インフラサイドに寄せて置いた方が良いのかな... とにかく大量に負荷をさばけるところに行ければか...

この動画も面白かったです...

# 4. Flask と Django の違い

# (1) 雰囲気の違い

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

Django というウェブアプリケーションがあります。 Flask がチャラいのに対して、Django はマッチョな印象です。

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

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

反面 Flask は、必要な機能は最小限で、必要な機能は自分で pip install しないといけません。 またリクエストを flask というグローバル変数から取り出すところもチャラい感じがします。

チャラくて、ふわふわしていてどうしていいかわからないところがあります。 でも触っていてコード書いてる感がして楽しかったりするのが悔しいです。

Django も Flask も一長一短です。

# (2) 使われ方の違い

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

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

Flask は後続ながらすこしずつシェアを伸ばしている印象があります。 JetBrains 社の調査があります。 JetBrains 社は Python でよく使われる IDE の PyCharm を出している会社なので信頼があります。

2019 年のものが出たそうです。

こちらは PyCon の時の口頭での質問結果。 PyCon は年に１回開かれている Python 祭りです。 質問していただいてるのは、BeProud という Python の老舗の会社なので、こちらも信頼がある数値です。

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

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

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

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

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

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

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

# 5. マイクロサービスってなに？

わからない。

たくさんの Flask のサーバを立ち上げる。 切り分けられているから、役割分担をしやすい。障害が切り分けやすい。と言ったメリットがある。 みたいなざっくりした理解しかしていない。

個人でこれを学習しようと思うと、なかなか厳しい気がする。 ボトルネックになりうる箇所を想定しながらどうやって組み立てていけばいいんだ？

大量に自身の AWS にトラフィック流し込んで、AWS 切腹決め込みながらやったら面白いのだろうか。 結局この辺は、知識を持っている人に聞いいてガツガツ組み上げて練習するイメージなのだろうか。

# 6. ASGI - Python の中での話

じゃあ Flask でもいいかもって希望が湧いてくるじゃないですか？ でもそうでもないのか。

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

ASGI が何かわかっていません。 動画のストリーミングやリアルタイムチャットを実装するときにインパクトがあるようです。 WebSocket とかという単語を見かけます。

Flask の場合 while 文でひたすら待ち続けるみたいになります。

@app.route('/pipe')
def pipe():
    if request.environ.get('wsgi.websocket'):
        ws = request.environ['wsgi.websocket']
        while True:
            time.sleep(1)
            message = ws.receive()
            if message is None:
                break
            datetime_now = datetime.datetime.now()
            data = {
                'time': str(datetime_now),
                'message': message
            }
            ws.send(json.dumps(data))
            print(message)
            print(data)
    return

# ストリーミング
class Camera(BaseCamera):
    """An emulated camera implementation that streams a repeated sequence of
    files 1.jpg, 2.jpg and 3.jpg at a rate of one frame per second."""
    imgs = [open(f + '.jpg', 'rb').read() for f in ['1', '2', '3']]

    @staticmethod
    def frames():
        while True:
            #time.sleep(1)
            yield Camera.imgs[int(time.time()) % 3]

FastAPI の場合、この手のものは、async, await を使って綺麗に書けます。

import asyncio


async def app(scope, receive, send):
    """
    Send a slowly streaming HTTP response back to the client.
    """
    await send({
        'type': 'http.response.start',
        'status': 200,
        'headers': [
            [b'content-type', b'text/plain'],
        ]
    })
    for chunk in [b'Hello', b', ', b'world!']
        await send({
            'type': 'http.response.body',
            'body': chunk,
            'more_body': True
        })
        await asyncio.sleep(1)
    await send({
        'type': 'http.response.body',
        'body': b'',
    })

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

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

Does werkzeug have plans to support ASGI? (opens new window)
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 タグがつけられたものが、１年前から更新されていません。

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

ASGI 自体もそこまでインパクトの大きいものではなさそうです...

現状では「Django3.0がASGI対応をした」という事実だけで、私たちが普段作るDjangoアプリケーション的に大きな変化はありません。

Responder, FastAPI などの ASGI 対応ウェブアプリケーションフレームワークに手を出すのが賢明なのかなと思ったり、思わなかったり。

とはいえ、GitHub のスター数の勢いやらダウンロード数にしても Django, Flask が圧倒してますが...どうなのでしょうか。

# 6. フレームワークの動向

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

こちらのつぶやきから知りましたありがとうございます。

基本的に Flask or Django が二大巨頭で、資料がなかったりして、それ以外には手を出せません。 そんな中どう言ったシチュエーションでどのフレームワークを選ぶと良いかということについて触れられています。 寺田さんという結構有名な方が書かれて、それを @c_bata_ さんという この業界では神の様な存在の方がチェックされた資料です。

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

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

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

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

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

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

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

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

# 7. Laravel と Rails

Flask には手を出さない方が良いと言ったのですが、Laravel と Rails も立ち位置は同様な気配を感じます。

もちろん国内の求人に関していえば、バックエンドで Laravel, Rails というのは多らしいですし、おそらく圧倒的です。 直近で消えることも絶対にありえないです。 直近で仕事を得る場合には必要な気がします。

ただ長い目で見れば Flask 同様、避けた方が望ましい気配を感じます。

しかし、サーバレスの流れが強いです。加えて言語としての PHP, Ruby は減衰傾向にあります。 （要, グラフ） 可能なら手を出したくないです。

PHP は純増, Ruby は純減です。

Ranking Programming Languages by GitHub Users

言語論争は、嫌というほど見ましたし PHP も Ruby も良い言語だと思います。

この記事ははてブが１つしかついていませんが、とてもとてもとても素晴らしい記事です。 なぜ PHP が素晴らしいのか、明確には書かれていない、でもその背景が伝わってきます。 このお父さんの日曜大工的な雰囲気が好きです。

言語の根本の部分は同じで枝葉末節にとらわれてはいけない。 面接時に Python しかやりたくないというのは良くないという記事を見かけます。

もちろん正しいことはわかります。 しかし、私のキャパシティも、そして残り許された時間も本当にごくわずかです。

そのごくわずかの時間をツールやフレームワークを覚えるための差分の時間に浪費できないのです。 私が学習するときは多くの時間を要します。 それは優秀な人が言う、些細な問題ではないのです。

目くじらを立てる必要はないと思います。 しかし、なにも考えなくて良いのかといえば、おそらくそうではないと思います。 私の１時間に価値はありません。 それでも、ほんのちょっとのなけなしの手札を無駄にするわけには行かないのです。

やばい案件は Python よりも PHP, Java の方が多いと聞きます。 明確な数字はありませんが。

しかし、この言語しかやりたくありませんは良くないことだ！ は採用側のポジショントークではないでしょうか？

VBA の仕事を押し付けられた逃げ出したくなります。 なんでもフルコッミトしないといけないかどうかは、その相手との関係次第だと思います。

それが良い契約であるとは到底思えません。 契約書レベルでこの仕事はしないことを宣言したいです。

実際、Amazon Web Services, Google Cloud Platform , Microsoft Azure と言った大手の クラウドベンダが対応している言語を見ると PHP は無し Ruby は AWS だけで採用されている状況です。

JavaScript が強い... JavaScript も衰退傾向にはありますが、 TypeScript に置換されていくと考えるのが妥当かと考えています。

TypeScript はパッ見の雰囲気が良いのに加えてバックグランドに Microsoft が居て、 さらにはナデラという CEO が凄腕過ぎて、この人を信じておけば大丈夫やろという思いさえします。 まだこの CEO は若いですし。

pyright が出てきたときは、 mypy より速いよ！みたいな触れ込みで、 凄すぎて軽く引きました笑

その直後に mypy をアプデしてパフォーマンス改善したよ的なつぶやきを Guido がしてて、 エコシステム的にはいろんなものがあった方が良い様な気もしつつ、 胸を撫でおろしたのを覚えています。 mypy 使ってないのですが笑

Guido がコミットしてるのが立ち消えるなんて嫌じゃないですか笑

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

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

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

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

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

# 7.2. PHP

# 7.2.1. Laravel

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

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

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

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

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

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

# 7.2.2. WordPress

最初に見た時になんか大げさな印象がありました。

危ないってわけないよなって思いながら...

ただちょっといくつか調べていく中で.... まず第一に、WordPress を本来使わなくてもいいシーンで使ってしまっているケースがあること。 また第二に、それに加えて動的ページを作りたいと思った時に Ajax 特に SPA でさっくりにがせる様になっている。

逃がし方があるっぽい。まだちゃんと読めてない...

カナダでは WordPress が減少傾向にある。 母数がそもそも少ないからどうとも言えあないところはあるのですが。

特に WordPress については言及されていないけど VuePress はおそらく WordPress 置換狙いなのでは。 理由は Vue.js の生みの親の Evan You さんが、 静的サイトジェネレータというマーケットの小さい分野にコミットすると思えなかったから。

# 7.3.

日本人は自由さを好む気がする。日本語の文法もそうだし、古く言えば "散らし書き" は "漢詩" と比較するとすごく自由に見える。 Ruby の自由さが好まれるのはそう言ったところにあるのかなという気がする。 国内の Python の人気は、Ruby にあった熱狂みたいなのは、ほとんど無い気がする。

コードを書くということを考えたときに、もしかしたらあまりこの自由なものを好む傾向はよくないのかもしれない。 もちろん良い方向で作用するものもあると思うけど。 なんか、こう静的型付であったり、KISS の原則とか見てると、そういう雰囲気なのかなという気がする。

反面、日本人は細かいことに対してとても几帳面なところがある気がする、自分はそんなことないけど。 相反する。これが何に由来しているのかはわからないけど、維新後の義務教育の影響が大きかったりするのだろうか。 それとも元々相矛盾するものが互いに共存しているのだろうか。

そう言った几帳面さが逆にアダになっているのではというのは面白かった。

IT 絡みでいうと、なんか全部逆の方向に作用してしまっているのではないかって気がした。 コードを書く段階では自由さを好むし、使う動機では几帳面だからあまり無いみたいな。 こう几帳面だけど自由さを好むから効率が悪いやり方になっているみたいな...

その国が勢いに乗るかどうかは、その国の地理的な「場所」と人の「性格」が大きな要因であるような気がする。 日本人の「性格」は、もしかして歴史的な役割をもう終えているのだろうか。とふと思った。

# 8. この連載の対象

巷でよく売っている Flask 入門を終えたくらい。

# 9. この連載の目的

二部に分かれています。

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

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

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

# 10. おわりに

以上になります。

Python で Web アプリが作りたい
(前編) Flask の外側 →