“The DOM is the API” — Micro Frontends パネルディスカッションレポート(後編): Microservices Meetup vol.7
qsona (twitter) です。本記事は、2018/7/31 に 弊社FiNCで開催されました Microservices Meetup vol.7 (Micro Frontends) の中で行われたパネルディスカッションのレポートの後編になります。前編は以下をご覧ください。
なお、本記事は100%正確な書き起こしではなく、編集を行っております。意図を損なわない努力をしておりますが、文責は qsona にあることを明記しておきます。
アウトライン
- Micro Frontends の境界・独立性
- グローバルな状態の共有
- Micro Frontends と BFF (Backends for Frontends), GraphQL の関係性
- Micro Frontends と BFF は思想レベルで対立する
- 職能横断的組織を作るのは難しい？
- 実際に技術異質性を得られるのか
- Frontend Monolith の分割はどれくらい大変なのか？
- Micro Frontends 間の API Versioning について
- Micro Frontends のビルド (Bundle されるべきか？)
- Micro Frontends のテスティング
qsona: では、再開していきたいと思います。質問をいくつか頂いているので、紹介したいです。
Micro Frontends の境界・独立性
nsienaさん:
マイクロサービスだと各サービスごとに内部実装を隠蔽されるので自由度があるけど、マイクロフロントエンドだとそういう独立性を確保しにくくなったりしないのかなと、どのような見通しがあるのか、あるいはどのような課題があるのか、それぞれのご意見を聞きたい。
qsona: いきなり最初から良い質問ですね。フロントエンドだと境界があいまい、的な話ですよね。
teppeis: これは The DOM is the API ですね(会場笑)。例えばReactの人とAngularの人のように、いろんなのを使いたい人がいたときに、共通項が何かというと DOM is API ということ。今現在では Web Components はその一番の候補になっているので、 Micro Frontends の文脈で Web Componentsが出てきていると理解しています。特定技術に寄ってしまうと選択の幅が狭まっちゃうから、インターフェイスを標準技術に寄せるということだと思っています。
lacolaco: 粒度があるけれど、境界を完全に分けるには、 window って邪魔なんですよね。global scope が邪魔。global scope があるから、どうしても境界がなくなってしまう。だから僕はWeb仕様として Zone (参考: https://github.com/angular/zone.js/ )とかが導入されたあとが真の世界なのではないかと思っています。完全にクローズドな世界を持たないといけないんじゃないか。現在はDOMで頑張るしかないけど、iframeを使うと境界がしっかり分かれるのでおすすめです(会場笑)。
グローバルな状態の共有
筆者注: この部分で qsona の勘違いにより議論が上手く繋がっていないため、一部を省略しました。
lacolaco: 認証ってけっこうマイクロサービスになる率が高いと思っていて、真っ先にマイクロサービス化されやすいと思うんですけど、そことUIが紐づくみたいのは大きい気が。
qsona: 認証されてるとこういうを画面出して、認証されていないときはこういう画面出すみたいなのもありますね。globalに状態を共有しなければいけないことは、どれくらいあるのか。基本的にはしないのが正しいのでしょうか？
Quramy: 認証状態とかがglobalにあるのはサービスとして当たり前だと思っていて、ゼロにしなければならないということはないと思うんですね。ただ、これが Micro Frontends だろうと思って切り出したものの、双方にものを共有したり、片方を片方に変えるというようなことが頻発していると、それはそもそも分けるべきではなかったという話になります。
なので、少なければ少ないにこしたことはないが、globalに参照しなければならない状態というのはあると思います。変更していいサービスはなるべく一つにしたほうがいいとか、そういうガイドライン的な話でしかないのかなと思うのですが。
qsona: globalに何をもつかは丁寧に設計する必要がある。
Quramy: そうですね。認証なんかは真っ先に必要だと思います。
Micro Frontends と BFF (Backends for Frontends), GraphQLの関係性
qsona: GraphQL の質問がきました。
adwd さん:
マイクロサービスのBFFにおけるアグリゲーションとしてGraphQLを採用するパターンってあると思うんですが、GraphQLとマイクロフロントエンドってどうですか？
qsona: これは GraphQL Tokyo 主催の Quramy さんにぜひお願いします。
Quramy: 僕のいまの理解では、Microservices の文脈において GraphQLというのは、 BFF のように各APIを Aggregation (集約)するようなものだと思っています。なので、あくまで横断的に、 Gateway として考えられるような層なので、あんまり Micro Frontends との相性は良くないというのが現状の意見です。ただ、ちょっと GraphQL を使いこなしていたり本番で使っているわけではないので、最近 GraphQL をよく触っていそうな lacolaco さんに。
lacolaco: そもそもQuramyさんに聞きたいんですけど、BFF と Micro Frontends って両立・共存すると思いますか？
Quramy: さっきもちらっとBFFの話をしたんですけど、僕がやりたいのはMicro Frontends で Backend と1対1のサービスを作りたいというよりは、でかいモノリシックからちょっとずつ将棋崩しのように小さいリポジトリに分け、それによってその分けた部分では React も Angular も両方使えるよね、CIも別々に走るよね、という状態にすることです。
将棋崩しで残った最後の山みたいなところはたぶん今のBFFが普通にのこると思っていて、小さくなるんですよね。それは悪いことではないと思っていて、最後に残った塊は Micro Frontend でもなんでもないんと思うんですけど、 ”シュッとしたBFF” が残ってくれればそれでいいやと。
BFF が GraphQL と違うのは、BFF はかなり用途に特化したAPIを提供するというところです。GraphQL はスキーマで提供できるものをなんでも提供できますよという雰囲気のものですが、わりと BFF はそこまでではなく、本当に必要なものだけを提供する BFF が残ることはあるのかなと思います。
teppeis: Micro Frontendが何かしらAPIを叩くとしたとして、GraphQLを通るかというと、多分通さないですよね。
Quramy: 通らないと思います。通す必要がない。
Micro Frontends と BFF の思想の対立
teppeis: なんかこう、Micro FrontendsとBFFは相反する気がするんです。
lacolaco: 同じ軸にはないですよね。
teppeis: Micro Frontendsをやろうという人は、BFF とか GraphQL はやらない。やらないというか、それが目的じゃない。
BFF はフロントの方にビジネス的な主眼があって、そこからいろんな Backend を触りたいという時に、例えば GraphQL によって Aggregation できるよというところが嬉しいのだと思うのですが、Micro frontend はBackendと Frontend の一貫性のあるものをやりたいという文脈だから、共存できるかどうかというか、考え方が全然違うんじゃないかなという気がしますね。
lacolaco: この間ブログで Backend for Resource と Backend for Usecase って書いたんですけど ( GraphQLとRESTfulについて今日考えてたこと Backend for Usecase/Resourceについて — lacolaco ) 、アプリケーションがユースケースをどこに持つかが違って、BFF を使う場合は BFF に Usecase がつまっている。
Micro Frontends って Usecase 持たないんじゃないですか。単一の責務があって、それをやるためのリソースと直結してる気がしています。僕の語彙で言うと Micro Frontend は Backend for Resource に直結するところで、 Usecase にはくっつかないのかな、と。
BFFだけやっていると BFF になんでもかんでも詰め込まれてくるんですけど、そのなかで、ここは Usecase 関係なく単一の責務として切り出せるよねというものが出てくると、だいたいそこが Micro Frontend になっていく気がする。
BFFは最初のワンステップとしてはよい気がしていて、ただふくらみすぎるとそこがモノリシックになるから、そこをモジュール化していくと自然と (Micro Frontendsに) なっていくんじゃないかな。
qsona: 最終的にどっちに主眼に置くかみたいなところで、 Micro Frontends が僕は理想だと思っているんですけど、さっきのQuramyさんの例のように、全部が Micro Frontends で行けるかっていうとうまくいかない時に、BFF が必要だよねということで、共存したら良いのかなと思ってるんですが。
lacolaco: 共存っていうのは難しいですよね。アプリケーションを作る上で、 Micro Frontends をやったところでマッシュアップする層は絶対必要です。そこにすべてを詰め込むのが Micro Frontendsで。BFF はむしろ BFFがその Aggregationをやって、フロントエンドは BFF だけを見ていればよいとなるはず。
どっちにもつかの違いですが、正直 BFF のほうがパフォーマンスいい気もするっちゃする。
qsona: Micro Frontends って、基本的に各マイクロサービスがUIを返すんですけど、その合成するレイヤーをいかに薄くできるかという話だと思うんですよ。各マイクロサービスがUI返せるならそれがベストだと仮定して、それがどうしても無理なケースだけBFFを適用して集約して返すようにすれば、集約はBFFをつかってるところもあるんだけど Web Components を使ってるところもあるみたいなハイブリッドな世界にできるんじゃないかという気がします。
teppeis: だったら集約する必要あるのか？という感じになる気がします。パフォーマンスのためというのはあるが、それはチームとかアーキテクチャの本質じゃないという感じがして、ブラウザからいろんなAPIを叩いて集約できるUIを作っているチームがいるんだったら、それで良いはずで。
qsona: API Gateway 的なので十分だと。
teppeis: そうですね。チームやサービスという境界に対する解ではない。Micro Frontends はフロントエンドのところにちゃんとビジネスの境界があって、それを独立して提供するチームがいるみたいなことをやりたいので、BFF とは違う気がします。
職能横断的組織を作るのは難しい？
pontanさん:
マイクロフロントエンドをどのような組織で扱っているのか、組織の話を少し伺いたいです。 マイクロフロントエンドに対応する職能横断的組織を構築するのは簡単ではないと思うのですが、 マイクロフロントエンドを実践される上で、特定のロールのエンジニアが枯渇する（サーバサイドエンジニアは多いがフロントエンドエンジニアは少ない）等の問題は起きているのか？、起きていたらそれにどう対処しているのか？ もしくはフロントエンドエンジニアチームは職能別組織的に集約しているとか
teppeis: これlacolacoさんとかそうですよね？フロントエンドの人が少ないからいっぱい見なくちゃいけないみたいな文脈なんじゃなかったでしたっけ。
lacolaco: 作るアプリケーションが3つあって、フロントエンジニアが3人いて、1人1個確保できたが、とはいえUXが乱れるよねというのがあって、Componentをモジュール化して共通で使おう、みたいな感じです。
qsona: この問題、うちはありますね。例えばFiNCアプリとかはビジネスチームに4分割してやってるんですけど、iOSエンジニアは4人揃えるのがギリギリなので、兼任に近くなったり、ある人が休みのときは違う人がみなくちゃいけない、みたいなことはよく発生しています。
結構これはマイクロフロントエンドに限らない問題だと思います。マイクロサービスで有名な会社の方に、すべて職能横断的チームにすることでの効率性の問題はどうしてるのか聞いたことがあるんですが、全く気にしていないと。例えば社内で似たようなサービスが出てもよくて、競争原理働かせて勝ったほうを採用すればいいみたいなことを言っていて。
teppeis: そんなリッチな会社どこにあるんですか(笑)
(筆者注: Microservices の文脈ではサービス分割の単位を技術ではなくビジネスの単位にするべきで、そのサービスに沿った職能横断的チームが構成されるのが理想とされます。Martin Fowler はこの問題に対して、非効率性は気にしないという旨を書いています。出典: やっぱり機能別組織が好き , 原文 PreferFunctionalStaffOrganization , ただし現在この文自体は本人により deprecated とされているようです)
qsona: めちゃくちゃお金あってめっちゃ優秀なエンジニアめっちゃとれればそれでもいいのかもしれないけど、我々はそうではないので、現実解としては難しいなと。
うちはマイクロサービスの数に対してエンジニアの数が全然たりてないので、この問題は抱えています。
teppeis: それは逆転してしまっている気がします。チームとか組織に合わせてアーキテクチャを選択しなくちゃいけないのに、そこにフィットしてないアーキテクチャを選択してしまってるのではないのかという疑問はあります。それ以上に分割してしまっている。
qsona: 人は欲しいです(笑)
lacolaco: 逆に属人性が高まっちゃう問題もありますね。
実際に技術異質性を得られるのか
qsona: 技術異質性の話で、例えば React と Angular を一緒に使えるというのが Micro Frontends の特徴だと思いますが、現実的に本当に React と Angular を一緒に使えるのか、というような質問もあったのですが、どうでしょう。
lacolaco: いまうちのプロダクトの中で一番古いのは AngularJS で動いてるんですが、そのなかの一部は新規開発で、 iframe で React で動いています。AngularJS で開発するコストの方が高いので。(筆者注: Angular”JS” は 1.x系のことでアクティブな開発は終了しており、Angular (2系以降のこと) とは実質的に別物)
qsona: 強い人達だったらできるみたいな感じなんでしょうか。
lacolaco: うちは技術的なところで効率を採ろうとしていなくて、逆に分散させようとしています。いまは React 多めだけど Angular と React バラバラだし、React の中でも一人は mobx つかっていたり一人は redux だったりするし、あえてある程度バラしています。なんか、やってみたらやれますよ。結局 DOM is API って感じなので(会場笑)
Frontend Monolith の分割はどれくらい大変なのか？
atsukanrockさん:
Quramy さんから、リポジトリの単位がでかすぎて辛いという話がありました。同意するところですが、 micro frontends でない場合に、リポジトリをこれ以上細かく割れない単位ってどういう単位ですか？ なぜリポジトリを割れないのかが知りたいです。何らかの共通部分があるのだと想像しますが、想像しきれてません。
teppeis: リポジトリ割るのって、大変ですよね。
Quramy: たぶん、 React のコンポーネントを部分的に出すみたいのはやろうと思えばできるんですが、コンテナみたいなのはglobalなステートに依存してしまっているので、そのコンテナだけを切り出そうとしたときに、セットでひっぺがさないといけないのはなんなのか、共通のCSSなど、を考えると、多分コピペだらけになってしまうんですね。
一旦それでも分けてからリファクタリングすればいいじゃないか、みたいな話もあるかとは思うんですけど、そこまでの体力が自分たちにないというのが課題で。分けることを前提に設計してなかったから、というのが答えなのかなという気がしますね。
teppeis: デプロイフローに直結しますしね。
Quramy: それもありますね。分けた瞬間にビルドの大変さが5倍くらいになる。
teppeis: バージョン管理をどうするかなども。
Quramy: それも出てきますね。1個だけなら単品で出すか出さないかなんですが、2つあったときに細かい話がいろいろ出てくる気がして、まだ頭を回しきれていないという感じです。
Micro Frontends の API Versioning について
andoshin11さん:
Microfrontends間のAPIバージョニングの話とか気になります
qsona: API バージョニングするんですか？マイクロフロントエンドの。例えばイベントの形が変わったりする？
teppeis: Micro Frontends をやりたいならそれぞれを独立してデプロイしたいということなので、それぞれのUIパーツがどんどん上がっていくわけです。それに対してちゃんとバージョニングできていないといけない。いきなり上げて後方互換ないです、みたいなことは言っちゃいけないので、使ってる人がある程度コントロールできるとかが必要ですよね。それはどうしているのかなと。
lacolaco: そもそもマイクロサービスがバージョニングされている前提ですよね。マイクロサービスのデプロイと同時に行われるから、そこのバージョンは使えるはず。マイクロサービスの中のマイクロフロントエンドなので、マイクロサービスのデプロイという単位は、そこがアトミックになる。
qsona: そこの間の話ではないですか？マイクロフロントエンド A, B があって、Aを上げたらBが壊れるみたいなことはあるか。これの API っていうのは DOM is API の API ですよね。
lacolaco: イベントのペイロードの話とかですね。それはアプリケーションをマッシュアップする人の責任な気もしますね。
Micro Frontends のビルド (Bundle されるべきか？)
Quramy: どういうビルドを想定しているのかによって割と話が変わってくるのかなと思っています。バックエンドと違って、フロントエンドにはビルドという闇がいるわけですよ。
おそらくここで質問されているのは、マイクロフロントエンドのコンテナ A, B があって、その間で通信が必要というときに、DOM でやるなら A がイベントを投げて、一番上の body みたいなところがキャッチしてまた下に投げることで通信できるが、その中のペイロードのバージョニングをどうするか、みたいな話だと思うんですが。
AとBが、さっきの micro-frontend.org みたいに Web Components で提供されているとして、それをそのまま取ってきているのか、一番上のレイヤが webpack かなにかでビルドしているのか、で全然話が変わってくるのかなと思っています。
僕の肌感なんですが、Web Componentsを使っているからといって bundle (ビルド) していないという話では全然ないと思うんですね。Web Components をその場で取ってくる、エンドユーザーが叩いたときはじめて jsを script module とか dynamic import とかで取ってくるとかいうのは、最終的な、夢のimportの未来だと思うんですけど、今はまだブラウザ動く動かないの問題もある。なので、誰かがどういう単位でかはわからないけど bundle.js みたいなのを作らざるを得ないんじゃないかと思っています。ここは Kaizen Platform さんが Web Components を使っているという話もあったので、実際どうしているか興味があります。
lacolaco: 基本的にはbundleしたいと思っていて、Angular のアプリケーションの方ではbundleしています。Web Componentsを提供しているライブラリを静的にimportしていて、webpack がまとめます。そこではテストとかが通った状態のものが入ります。
Quramy: バージョンはbundleしたときに固定されている。
lacolaco: そうですね。アプリケーションのビルドのときに Web Componentsのバージョンは固定されます。ただ、実装上の問題がありReactはそうなっていなくて、React側はUMDの形式の別のjsを index.html で読んでいます。それはURLの中にバージョンを含めているから、UIライブラリ側がデプロイされても、アプリケーションが知りえないバージョンのUIライブラリが入ってくることはなく、コントロールされている状態です。
qsona: Micro Frontends の組織の分割的な文脈 (独立したデプロイを可能にしたい) でいうと、bundle されないほうが正しいという気がしてしまうんですが。
lacolaco: それは多分理想的にはそう。ただ、考えている粒度が違う気がしていて、僕がやろうとしてるのはデプロイごと分けるほどではない気もします。現実的には、アプリケーション作っていて実際どうなるかわからないものがそこにあるという状態は難しくないですか。開発していてここは実行時にどうなるかわからない、のような。今の所ちょっと想像できない。
Micro Frontends のテスティング
qsona: これは完全にバックエンド開発者としての視点ですけど、FiNCで Microservices を作るときはあんまりE2Eテストとかは書いてなくて、基本的に各サービスがちゃんとAPIをドキュメントで定義して、サービスの単体テストで担保したり、後は Staging だとドキュメントと合わないレスポンスを返そうとすると500エラーにして検知できるようにしたり、各サービスがAPIを守ることで全体の挙動を担保しています。いわゆる Good Citizen みたいな感じで、各サービスがちゃんと真面目にやってればそうそう壊れないというのを信じてやっているんですが、フロントエンド特有の事情でそういうのが難しくなるというのはありますか？
teppeis: そういう意味だと、テストってどうしてるんですかね？例えばバックエンドだったら、Consumer-Driven Contract (CDC) などの考え方があって、自分が使うものに対してそういう使われ方をするはずだ、というような。フロントでという文脈だとそういうのってあるんですかね。
※筆者注: Consumer-Driven Contract (CDC) テストは、E2Eテストに代わる複数サービスのテスト手法です。サービスを呼び出す側 (Consumer) が、呼び出されるサービス (Provider) との契約=Contract を定義します。この契約は「ProviderのこのAPIをこのパラメータで呼び出したらこういう形式のJSONが返される」のようなものです。Provider 側でこの定義を利用して、契約を守れていることをテストします。一般的にはProviderのCIに組み込まれ、後方互換性を崩す変更がデプロイされないようにします。代表的な実装として Pact があります。
qsona: ちょっと考えてみますか。
lacolaco: 例えば、AとBのマイクロフロントエンドを並べたとして、片方のビルドでwidthが変わったとして、そしたらもう片方が下に下がったとか、わりとありえる気がするんですね。そこがデプロイ前に確認できないのはめっちゃ怖い気がする。そのドメインでは正しいしテストも通ってるんでけど、AのせいでBが壊れるというのがありうる。
1つの解としては、semver (semantic versioning) をめちゃくちゃ使うというもので、絶対に私はアプリケーションを壊しませんという間は minor version を上げる。壊すかもしれないときは major version を上げて、そこは自動適用されないとか。
qsona: バックエンドだとAPIさえ守っていれば壊れないという自信があるんですけど、フロントエンドだとけっこうそういう、DOM、まあ DOM is API なんですが、DOM の変更が影響を与えると。
Quramy: DOMだけじゃなくてCSSもありえますよね。
lacolaco: 配置のずれもバグとされるわけです。ロジックのバグとUIのバグ両方と戦っている層ではあるので、テスト通っていれば良いということにはならない。
teppeis: これは Visual Test の話じゃないですか。(会場沸く)
(筆者注: Quramy 氏は画像回帰テストの第一人者として知られています。 reg-suit の作者であり、登壇も数多くされています)
Quramy: どんなやり方にせよ、一番外の大枠でそれぞれのコンテナをimportする層は、どんなに薄くとも必要だと思います。いまの話を聞いていると、そこで smoke test みたいなことは、これはせざるを得ない。自由度を上げれば上げるほど、それはしたほうがいいだろうなと思っています。そこで Consumer-Driven Contract みたいな文脈に沿うならば、各コンテナというのは Web Components の attributes だったりで挙動が規定されるわけで、この場合は親を Consumer とみなすのですが。いままで通っていたものとか、これは通るべきだというものに対する結果だけを最終的に提供してもらって、その状態でブラウザで画面を開いて大丈夫だよねという確認をしましょう、というのはQAの中で必要だと思うんですね。これをどう自動化するかというのはその先の話だと思いますけど、トップのレイヤで正常系を確認しましょう、いままで通っていたものを確認しましょうという営み自体は絶対なくせない、むしろモノリシックな頃よりも重要になるんじゃないかなという気はしますね。
lacolaco: 多分いま大体のアプリケーションは development / staging / productionの環境があって、全部それやらなきゃいけないんですかね？マイクロフロントエンドは全部でそれやらないと壊れるから、QA対象がめっちゃ増えて脳みそ疲れる気がします。
teppeis: DOM Based CDCじゃないですかね。(会場沸く)
qsona: Contractの定義の仕方がどうなるのか。Contractの定義が JSON 返すだったらわかりやすんですけど、どうやって定義するんですかね。Pact じゃ無理ですよね。
teppeis: Pactじゃないけど、 jsdom で DOM Based な CDC みたいなところを Web Components の上に構築するみたいのが、Web Components ベースで Micro Frontends やりたいとなったときはあるのかなと。Backend のアナロジーとしては、そういうのはあり得るのかなというイメージはありますけど。
Quramy: リクエストとレスポンスがなんなのかというのを定義することだと思うんですね、Micro Frontendsにおける。なので、DOMの中身もおそらくそうですし、イベントもそうなりうる。インターフェイスになりうるものでいうと。そしてスタイルがどうなるのかですよね。
teppeis: スタイルは Visual Test ですよ。 (会場笑)
Quramy: 手法だとそう(笑)、DOMが一致していたからといって壊れない保証はないので。
lacolaco: Constraint みたいなの欲しいですよね。 (参考: Constraint Layout (Android) )
Quramy: それはもう max-height とかで。
lacolaco: あー、maxのwidthとheightで縛るのはあり得る。
teppeis: これ以上は広がらないみたいなことを。そこでiframe。 (会場笑)
後半の総括
最後はまだまだ話足りないところでの時間切れでしたが、多岐にわたって議論が展開されました。組織やテストの話など、既存のバックエンドのマイクロサービスのアナロジーとして考察できる部分と、状態の共有やビルド、見た目レベルの問題など、フロントエンド特有の問題として考察するべき部分があり、いずれもこれから実践していくにあたってベースにできるものが作られたように思います。
Microservices の文脈では、各サービスや組織を独立・自律させたいという欲求と、一方でその統合された状態として品質等を管理したいという欲求があり、しばしばトレードオフになりますが、Micro Frontends においてはより統合された状態について気を配る必要があり、ビルドやテストの議論からはその具体例が垣間見れました。実際には、どこまで独立性を重視するか、組織の規模やアーキテクチャ採用のモチベーションによっても塩梅が変わってくるでしょう。
Micro Frontends と BFF の関係については若干意見が割れたように見えますが、この2つが違う軸にあるという点については意見が一致しています。筆者個人が想像していた組織構成は、Micro Frontends の実践として各マイクロサービスのチームにもフロントエンジニアが入っており、一方でそれを統合(マッシュアップ)する層を管理するUIチームも薄いながら存在するというもので、この場合UIチームの持ち物として BFF を別途管理していても良い (組織に沿ったアーキテクチャになっている) のではないかと思っていました。このあたりもやはり、具体的なプロダクトや組織デザインに沿った議論が必要になるところです。
前後半あわせておよそ1時間という短い時間の中でこれだけ議論を深められる、登壇者の方々: teppeis さん, Yosuke Kurami (Quramy) さん, Suguru Inatomi (lacolaco) さん の力量が本当に素晴らしく、おかげさまで私自身大変勉強になりました。
さいごに
FiNCでは、ヘルスケアのプラットフォームとして広くビジネスを進めていくためにマイクロサービスアーキテクチャを導入し、1つ1つの機能を高速に開発しやすい状態にしていますが、本文中にもあったように、今後サービスを大きく育てていくためにまだまだエンジニアの数が足りません。また、今後 Micro Frontends の取り組みも進めていきます。iOS, Android, Backend (主にRails), Web Frontend (主にReact) など各エンジニアを募集しています！ Wantedly や twitter (qsona, DM開放中) などで気軽にお声がけ下さい。
