「信じられないほど小さい」Microdotウェブフレームワーク

概要

Microdot は、 CPython と MicroPython の両方に対応した超軽量Webフレームワーク。 IoTデバイスからクラウドサーバーまで幅広く利用可能。開発者は Miguel Grinberg で、 Flask にインスパイアされた設計。機能は最小限かつ実用的で、拡張も容易。ドキュメントやテストも充実したオープンソースプロジェクト。

Microdot：超軽量Webフレームワークの誕生背景

Microdot は、 Miguel Grinberg によって開発されたPythonベースのWebフレームワーク。
CPython と MicroPython の両方で動作し、IoTデバイスから大規模サーバーまで対応。
Grinbergは Flask Mega-Tutorial の著者としても有名で、Flaskから多くのアイデアを得ている。
Flask や Bottle はMicroPython環境では重すぎて動作不可、標準ライブラリの機能制限も課題。
Grinberg自身のスマート暖房体験から生まれた実用的なニーズが開発のきっかけ。

Microdot開発のきっかけと実体験

アイルランド移住後、暖房コントローラの不調に直面。
サードパーティ製サーモスタットの温度誤差が±3°Cと大きく、快適な室温維持が困難。
オーナーの協力を得られず、自力で MicroPython 搭載の独自制御システムを構築。
温湿度センサーと連携し、5分ごとに温度を計測してヒーターを自動制御。
精度±0.5°Cのセンサーで問題解決、さらにWebダッシュボードで情報を取得したい要望が発生。

Microdotの特徴と設計思想

microdot.py 単一ファイルでコアが完結、フル非同期設計（ asyncio ベース）。
マイコン向けに プロセスやスレッド非対応、非同期処理のみ対応。
Flask風デコレータ でルート定義、Request/Responseクラス、前後処理フックを搭載。
クエリストリング・フォームデータ・JSONはPython辞書で処理。
メモリ制約を考慮し、 ストリーミング対応 や静的ファイル送信も可能。
サブアプリケーション （FlaskのBlueprint相当）でモジュール構成に対応。
独自Webサーバー（ TLS対応）を内蔵。

拡張機能とエコシステム

拡張機能は各1ファイルで提供、コアを肥大化させず機能追加が可能。
- multipartフォーム （ファイルアップロード対応）
- WebSocket/SSE 対応
- テンプレート（ utemplate /Jinja for CPython）
- 認証・セッション管理 （jwt.pyによるトークン認証）
ドキュメントは書籍レベルで詳細、 9,267語・47分相当 の読みごたえ。
100%テストカバレッジ、30以上の実例付き。

設計原則と他フレームワークとの比較

「 No dark magic」を掲げ、暗黙的な動作や複雑な依存性注入を排除。
- リクエストオブジェクトは明示的にルート関数へ渡す設計。
- FastAPIのような依存性注入は明示的デコレータで代用。
コード規模比較：
- Django ：110,000行
- Flask+Werkzeug ：15,500行
- FastAPI+Starlette ：14,900行
- Bottle ：3,000行
- Microdotコア ：765行、拡張込みでも約1,700行
URLマッチングも63行で実装、Flaskの1,362行に比べて圧倒的な軽量さ。

実機デモとハードウェア要件

発表では ESP8266 搭載サーモスタットをUSB接続しデモ。
- ESP8266 ：64KB RAM/4MBフラッシュ、WiFi内蔵、約5ユーロ
- Raspberry Pi Pico W ：256KB RAM/2MBフラッシュ
- ESP32 ：512KB RAM/最大8MBフラッシュ
ノートPC（32GB RAM）と比較し、超小型・低コストでWebサーバーが実現可能。

コードサイズ・パフォーマンス・最適化

Microdotは外部でバイトコード（ .mpy）へプリコンパイルし、デバイスへ転送。
- デバイス上での直接コンパイルは非現実的。
- ファームウェアに組み込み、RAM消費をさらに抑制可能。
パフォーマンスは「 本当に遅い」が、IoT用途では十分実用的。
コア機能の取捨選択で、 80%のユースケース を20%の実装でカバーする方針。

Microdotの今後とコミュニティ

Grinbergは ドキュメントの質 や 拡張性 に強いこだわり。
Flaskユーザーは移行が容易、IoTや小規模Webサービスに最適。
オープンソースとしてコミュニティも活発、今後の発展が期待される。

Hackerたちの意見

Microdotは、CPythonとMicroPythonの両方で動作するPythonのウェブフレームワークらしいよ。ルーティング、JSON処理、クッキー、ストリーミング、TLSを備えた765行の単一ファイルで構成されてる。IoTデバイス用のウェブサーバーを提供するために作られたんだって。

└

https://github.com/miguelgrinberg/microdot MITライセンス付き

└

esp32でMicroPythonを使うとすごくいいよ。サーバー送信イベント（SSE）にも対応してるし。htmxと組み合わせると、IoTデバイス向けに楽しいインタラクティブなウェブ体験ができるんだ。GPIOの状態インジケーターとかも即座に表示できるし。いじるのが楽しかったよ。ソースコードもすごく読みやすいし。

このフレームワークは、元のRailsと同じくらいのサイズみたいだね。元のRailsは1000行未満だったから（microdotは765行だって記事に書いてあった）。でも、元のRailsがmrubyで動くかは分からないな（当時存在してたらだけど）。それに、Railsはmicrodotの作者が「ダークマジック」だと思うようなことをたくさんやってたし。

自分の作品がトップページに載ってるのを見ると、いつも嬉しい驚きだね。Microdotについて質問があれば、何でも聞いてね！

└

この投稿が本当に好きだな。作者は素晴らしい記事を書いてるし、それは明確なプレゼンテーションから来てるんだろうね。自分の温度と湿度のモニターを使ったアプローチに魅了されたよ。記事のリンクに載ってたらごめんだけど、どうやって暖房ユニットを制御したのか気になって。聞いた理由は、私がNestデバイスを使ってエアコンと連携させてるからで、これがGoogleのエコシステムに縛られてるんだ。うまく動いてるけど、家の他のものとHome Assistantシステムが繋がってないんだよね。Nestの依存をなくしたいか、少なくともエアコンの電力利用を最適化する方法をいくつか持ちたいな。

└

なんでサーバーにPythonを使いたかったの？シンプルなタスクなら、Cでやるのも簡単そうだけど。

└

あなたのベンチマーク記事を見たよ。サーバーを使ったSoCが、シンプルなタスク（現在の時刻を表示する）で、HTTPとHTTPSの両方で1秒あたり何リクエスト処理できるか見てみたいな。よろしく！

└

実験用のガーデンシェッドで、スカイサーム屋根を使って複数のポイントで温度と湿度を測定したいんだ。パッシブ加熱と冷却のためにね。君のサーモスタットのコードが必要なものの90%をカバーしてるかも。ただ、まだPythonはよくわからないんだ。AIの助けを借りれば、コードを理解して修正するのは簡単だと思うけど。

└

組み込みのニーズには、TurboLuaにかなり頼ってるんだ。これが本当にすごいんだよ！信号やfd_setsがサポートされてるから、ウェブサービスとハードウェアをうまく結びつけられる。GPIOを簡単に接続できるしね。まだMicrodotには手を出してないけど、似たようなメカニズムはあるのかな？TurboLuaを基にしたLuaプロジェクトが大好きだけど、Pythonのスキルも磨かれるのを見てみたいな… 編集：調べてみたら、欲しいものはPythonの標準ライブラリに含まれてるみたいだし、MicrodotはmicroPythonにとっても小さな追加で、読むのも楽しいよ。

何年も前にPHPで作ったMVCマイクロフレームワークを思い出したよ：https://github.com/Two9A/BirSaat 今さっきコピーを引っ張り下ろしたけど、フレームワーク自体は526行のPHPで、サンプルサイト（BBCから情報を引っ張るニュースフィード）はモデルとコントローラーでおそらく300行くらいだね。今でもこのフレームワークを使ってブログや他の小さなサイトを運営してるけど、邪魔にならずにうまく動いてるよ。

何年経っても、FlaskがBottleや他のマイクロフレームワークをバカにしたエイプリルフールのジョークから始まったってことが信じられないよ。ジョークは完全に失敗したみたいだね。

└

ジョークだけど、Pythonがフロントエンドのウェブ言語になれなかったのは面白いよね。JSがバックエンドになれたのに、PythonのフレームワークがJSを真似してるのも不思議だし、Pythonの方が古いのに、見た目は整ってるのにさ…。

Bottleにすごく似てるけど、MicroPythonに対応してるみたいだね。

https://github.com/miguelgrinberg/microdot > Microdot 2への移行まさか、冗談だよね…。

└

リンク先のREADMEにちゃんと書いてあるよ。「Microdotのバージョン2は、以前のリリースのユーザーからのフィードバックを取り入れて、問題があったデザインの決定を改善・修正しようとしている。」だから、以前のバージョン用に作られたアプリは、Microdot 2で正しく動作させるためにアップデートが必要になるんだ。移行ガイドには、互換性のない変更点が説明されてるよ。

└

コミュニティが分裂して、炎上戦争や個人的なドラマがあって、誰かがブログに自分の側だけの話を載せる必要があるね。

タイトルの「信じられないほど小さい」って部分に対するコメントがたくさんあるね。ちょっと皮肉っぽく入れたのかな、誇示するためじゃなくて。例えば、「そんなに大きくなくてもいい」っていうMicrodotウェブフレームワーク（正直言うと、最初は周りの車に付いてるMicrodotの盗難防止装置と関係あるのかと思った）。今、HNでは皮膚科医がアプリを作ってる投稿もあるし。「コーディングにAIが必要/使う」ってのは、ソフトウェア開発がどれだけ複雑になったかの証拠だと思う。私たちが驚くのは、時には本当にそれがシンプルであることができるってこと。DjangoやFlaskを使ってる99%の人は、実際にどう動いてるかをあまり理解してないし、「これだけ？」ってなる瞬間があるよね。基本に戻ると、80%のニーズはシンプルで理解しやすいものでカバーされてるってことがわかる。

└

今、HNでは皮膚科医がアプリを作ってる投稿もあるし。「コーディングにAIが必要/使う」ってのは、ソフトウェア開発がどれだけ複雑になったかの証拠だと思う。別の見方をすると、ソフトウェアは再利用可能性の夢を実現しつつあって、ほんの少しの理解で高レベルのスクリプトを組み合わせることが可能になってきてるんだ。全然楽観的にはならないけど、開発は今でも多くの場所で混乱してるし、これからもそうだろうけど、私が始めた頃に比べてフロンティアはずいぶん広がったよ。

└

今、HNでは皮膚科医がアプリを作ってる投稿もあるし。「コーディングにAIが必要/使う」ってのは、ソフトウェア開発がどれだけ複雑になったかの証拠だと思う。90年代後半から2000年代初頭にかけて、非技術系のキャリアからASPやColdFusionのような言語を使って開発に飛び込めた理由があるよね。その頃のスタックにはいくつかの欠点があったけど、機能的には多くのビジネスケースに対応できる能力は、あの頃からあまり変わってないと思う。

最後にCFML（ColdFusion）で作った大きなアプリはFW/1に基づいていて、1800行未満（コメント含む）のMVCフレームワークだったよ。外部依存はないけど、正直言うと、CFMLアプリケーションサーバーにはほとんどのアプリが必要とする依存関係が全部組み込まれてるからね。

ハクソク