マイクロ管理ツールみたいな考え方

• 管理ツールを単機能でマイクロにやってみたら思いの外悪くなかった話
  • マイクロなフロントエンドだけどマイクロフロントエンドではない（はず）

思想

• 「1機能だけを持つアプリケーション」を作る
  • 例えば「投稿一覧ツール」みたいなものや「出金ツール」みたいな尖ったものまで
• 使わなくなったら捨てる
• コピペ上等
  • コアなAPIサーバーは用意しておいて、機能が固まってきたら移植

背景

• 管理ツールって色々考えること多い
  • どこに作る？
  • どう作る？
  • すぐほしい！
• プロダクトの初期においてほしいものは一部の機能
• 「今は困ってるけどこれ長期的にいる？」みたいなのある
  • 長期的に運用すると負債になりやすい

Tips

• 自分の場合はnext.js中心。
  • サーバーはCloudRunだったりvercelだったり。netlifyやらAmplifyやらHerokuでも良さそう
    • vercelの場合はproプランが必要
  • create-next-appで使えるテンプレートを自前で用意すると楽
  • ゼロベースから作ってしまったほうが早く作れたが、手馴染んだツールチェインがnext.jsだからうまく行ったのかも？
• 認証はslackにするとすごい楽
  • https://zenn.dev/terrierscript/articles/2021-02-27-next-js-api-resolved-without-middleware
  • 退職管理もしやすいし、外部ユーザーはシングルチャンネルで認証
• コアなAPIとマイクロ管理ツールの認証はちょっと悩みどころ。
  • 多分JWTで鍵認証とかが妥当そう
  • next-authのJWTはそのまま使うのはちょっと危険そうだったので別途JWT生成の機構が必要。このへんはめんどい
• データ周りはdynamodbとかfirebaseだと楽そう。GraphQLとかも相性良さそう
• クリティカルなデータを取り扱ったりしない
  • 雑にたくさん作ると穴を誘発しやすいので、そこは気をつける

撤退編

• 良きところで集約的な管理ツールにまとめていくことになる
  • 肌感5個ぐらい出てくると「そろそろまとめるかー」という気持ちになってくる
• 潰したツールはリダイレクトしたりする

Pros

• 高速式年遷宮感が出せて良い
  • 前のツールで良くなかった作りを替えてみたり
  • アーキテクチャを替えてみたり
  • 最終的に撤退時にガツッとリファクタリング
  • バージョンアップもしやすい
• 使えるまでのスピードが早い
• スコープを狭くできるのでデグレしづらい
• ビルドが早い
• メインのアプリに穴を開けたりする必要が
• 認可レベルをアプリケーションごとで考えればいいので

Cons

• セットアップはある程度簡易だが、envをセットして回るのはどのツールでも割と面倒い
• 組織によっては「ツール変わりました」と言うの嫌がられるかも・・・
• コピペは増える（覚悟の上だけど）
• 多人数開発には絶対向かない
  • 一人でババッとやるのに向いてる
  • 一人1ツールとか新人教育向けに一つ作ってもらうとかはアリかも