はじめに
現在、zabbixのようなデータ蓄積機能をWebでサクッと作りたかったので、技術選定をしました。
非常に参考となった記事を含めて、アウトプットしておきます。
先にまとめると
「Web管理画面をサクッと作りたい」という目的だったので、
難しいことを考えずにPythonで全部完結させたかった というのが本音です。
- FastAPI でバックエンドをサクッと。
- HTMX でフロントのJSをサクッと。
- Pico.css でデザインをサクッと。
この「サクッと3点セット」のおかげで、本来やりたかった「監視ロジックの開発」に集中できました!
技術選定した結果は以下の実装で使っています。
コア機能をFastAPIで作っていた 問題
選定した技術
- FastAPI
理由
-
Pythonで非同期処理(async/await)を楽に書きたかったから
監視エンジン(Poller)をPythonの非同期処理で書いているので、Webサーバー側も同じ「非同期(async)」の書き方で統一したかったのが一番の理由です。
メリット
-
とにかく「今どき」の書き方で楽
型ヒントを書きながら実装できるので、エディタの補完が効きまくって開発がスムーズです。 -
おまけの「自動ドキュメント」が便利
コードを書くと勝手に/docsというページができて、そこでAPIのテストができるようになります。「外部連携もいつかやりたいな」と思っているので、このおまけ機能は地味に嬉しいポイントです。
デメリット
-
Jinja2(HTMLテンプレート)の準備が少しだけ面倒
Flaskだと最初から入っていますが、FastAPIは自分で「Jinja2を使うよ」と1、2行設定を書く必要があります。
でも、一度書けば終わりなので大きな問題ではありませんでした。
JavaScriptあまり書きたくない 問題
選定した技術
- HTMX
理由
- リアルタイム性が欲しいけれど、ReactやVueのような重厚なフロントエンド開発環境(ビルド工程や複雑な状態管理)は避けたいというニーズに合致したため。
メリット
-
「サーバーサイドのみ」で完結
Python(FastAPI)の知識だけで動的な画面が作れます。
JavaScriptをほとんど書かずに「5秒ごとに最新値だけ更新する」といった処理が書けるのは、開発スピードにおいて圧倒的な利点です。 -
低負荷・軽量
クライアント側で重いJSを動かさないため、私の低スペックなPCやでもサクサク動きます。 -
HTMLの拡張
hx-get や hx-trigger といった属性をタグに足すだけでAjax通信ができるため、コードの可読性が非常に高いです。
デメリット
-
複雑な対話性には不向き
ドラッグ&ドロップの高度なUIや、オフラインで動くアプリを作るには力不足です(今回の監視盤には不要な機能です)。 -
JSONではなくHTMLが流れる
通信量自体はJSONよりわずかに増えますが、ローカルネットワーク内(エッジ環境)であれば全く問題になりません。
参考となった記事
htmxとは何なのか?(Qiita)
↓↓本家です
↓↓本家のサンプルです
CSSルールいちいち探したくない 問題
選定した技術
- Pico.css
理由
-
HTMLを汚さない
Zabbixのような高機能なツールを作ろうとするとHTMLが複雑になりがちですが、
Pico.cssは「タグを書くだけ」でスタイルが当たるので、ロジック(HTMXやFlask)に集中できます。 -
「表(Table)」の視認性が高い
監視システムは表がメインになりますが、Pico.cssのテーブルは標準でスマホ対応も考慮されており、非常に見やすいです。 -
学習コストがゼロに近い
フレームワーク独自のクラス名(btn-primaryなど)を覚える必要がなく、ブラウザ標準のタグを正しく使うだけで、それっぽい「管理画面」になります。
メリット
-
HTMLのセマンティック(意味論)を強制できる
Pico.cssは「どのタグにどのクラスを付けるか」ではなく「正しいHTMLタグ(nav,main,section,tableなど)を使う」ことでスタイルが当たります。これにより、Zabbixのようなデータ密度の高い画面でも、コードが読みやすく構造的になります。 -
「表(Table)」の視認性が標準で高い
監視システムに欠かせない一覧画面において、Pico.cssのテーブルは適度な余白とストライプ、レスポンシブ対応が最初から備わっています。自分でCSSを書かなくても、現場で使える「監視パネル」の見た目になります。 -
ダークモードへの自動対応
OSの設定に合わせて、あるいは1行のJSで「ライト/ダーク」を切り替えられます。深夜の監視作業などで好まれるダークモードが標準装備されているのは大きな利点です。 -
HTMXとの相性が抜群
HTMXで「HTMLの断片」をサーバーから返して画面を書き換える際、複雑なCSSクラスを管理しなくて良いため、サーバー側のテンプレート(Jinja2等)が非常にシンプルになります。
デメリット
-
レイアウトの自由度が低い
「このボタンだけ右端に寄せて、さらに影をつけて……」といった細かいデザイン調整には向いていません。凝ったUIを作ろうとすると、結局自分でCSSを書くか、Tailwindなどの別のフレームワークを組み合わせる必要が出てきます。 -
コンポーネントが最小限
複雑な「タブ切り替え」や「モーダルダイアログ」などは標準で用意されていないか、非常にシンプルです。Zabbixにあるような「ドラッグ&ドロップで動くウィジェット」などを作るには、別途JavaScriptや追加のCSSが必要です。 -
「どれも同じ見た目」になりがち
Pico.cssを使っているサイトは一目で分かるほど特徴的です。「自分専用ツール」としては最高ですが、ブランド独自のデザイン性を追求する商用製品には物足りない場合があります。
参考となった記事
デザインがときめくPico CSSの魔法(Zenn)
↓↓本家
↓↓本家のサンプル