はじめに
MicroServicesを意識してGoogleカレンダー風な何かを作成して得られた知見を投稿しようかと思います。
主な環境
- VSCode
- .NET Core
- C#, F#, WPF, ASP.NET Core
- MagicOnion
- ConsoleAppFramework
- ProcessX
成果物
CalendarAppForMicroservicesLearning
概要
2020年にWebフロントエンドを勉強する人が作るべきたったひとつのアプリ
にてGoogleカレンダーが教材として良さげということだったので検討してみました。
参考にしたところはカレンダーの予定の中にToDoリストのタスクを混ぜ込んで表示できる機能です。
画面的には
こんな感じで2カラムで右はTODOリスト。左はカレンダー表示で、予定と終わったTODOがまぜこぜに表示するような感じで考えました。
マイクロサービスの機能分け
TODOを取り扱う機能(TODOサービス)とカレンダーを取り扱う機能(カレンダーサービス)のふたつが必要だと考えました。
カレンダー表示の際にTODOの内容を知っていないといけないので、カレンダーサービスはTODOサービスを知っていないといけないのかなと思い、
と想像したのですが、マイクロサービス同士が依存するのは良くないと思いとりあえずお互いに関与しない方向で検討しました。(後述しますがBFFという考え方でなんとかなりました)
フロントエンド
マイクロサービスで構築した際に利点になるのはフロントエンドを選ばないところだと思ったので、デスクトップアプリとWebアプリを用意してみました。このほかにはスマホアプリとかコンソールアプリとかありそうな気はしてます。
マイクロサービスとフロントエンドの関係
何も考えずに想像したら
となってしまい、N対Nになってつらいなあと思っていたら
マイクロサービスアーキテクチャにおけるAPIコールの仕方とHTMLレンダリング
の記事が参考になりました。どうやらあいだにAPIGateWayとかBFF（Backends For Frontends）を用意すればすっきりするそうです。
こうすればフロントエンドはBFFに、TODOとカレンダーを混ぜ込んだ一覧をください、とお願いすればマイクロサービスを気にすることなく情報を手に入れられます。
こんな感じでひとつのAPIGawaWayで全部こなすようになるとAPIGateWayが大変なことになるそうなのでフロントエンドのアプリ一つに専用のBFFを用意してあげたほうが良いそうです。
マイクロサービスのエントリーポイント
マイクロサービスのエントリーポイントってみなさん何を想像しますでしょうか。
私はマイクロサービスとやりとりをするための方法としては、マイクロサービスがWebサーバ立ててhttpclientで通信する、しか想像できていなかったんですが実際に作ってみるといろいろできました。
とりあえず今回用意してみたのはコンソールアプリとgRPCです。
例えば特にスケールとかを気にしない状況で、デスクトップアプリみたいに同一資源上にいるのであれば、マイクロサービスをコンソールアプリ化して、使用する側はプロセス実行を行い、実行結果をjsonとかで標準出力でもらえばやりとりできます。
また、gRPCを用意すればメソッドを非同期で呼び出すような感覚でマイクロサービスやBFFとやりとりできます。
全体構成図
フロントエンドのアプリ一つに専用のBFFを用意したほうが良いといっておきながら今回はエントリーポイントの分け方で作ってしまいました。
実業務では通信手段としてWeb(Http)、gRPC、コンソールetcなどからひとつ選ぶはずです。
結果
WPF
ちょうど良いライブラリがなくお手製でくそみたいなUIで申し訳ないのですが
Webアプリ
FullCalendarとList.jsを使わせていただきました。
作ってみた感想とまとめ
- デスクトップアプリでもマイクロサービス風に組めた(良い悪いはわからない)
- 最初にマイクロサービスの分割を間違えるとつらい(と思う)
- MagicOnionが便利すぎる
- ConsoleAppFrameworkとProcessXの連携も素晴らしい
- POCO(Plain Old CLR Object)作るのがちょっと面倒(DDD的集約 <-> POCO <--> json で変換している)
- C#大統一理論まであと少し(domainの再定義しなくて良いのは嬉しい。後はWebフロントエンドさえ何とかなれば。。)
- フロントエンドは画面の表現に集中できる