Microservice Meetup #5 参加ブログ2(Webサービスの初期開発とマイクロサービス・BFF)

前回の記事に引き続き、Microservice meetupの参加ブログになります。
microservices-meetup.connpass.com


前回の記事はこちらです
takahiro-fujii.hatenablog.com

発表項目

「APIのことはすべてシーマンが教えてくれた。」 by @charlier_shoe さん

www.slideshare.net


「step by step BFF」 by @yosuke_furukawa さん
speakerdeck.com


「Webサービスの初期開発とマイクロサービス・BFF」 by @shimpeiws さん
speakerdeck.com


「Railsで作るBFFの功罪」 by @shotat_jp さん
engineer.recruit-lifestyle.co.jp

をベースにした話

目次

Webサービスの初期開発とマイクロサービス・BFF

今回は、
株式会社アカツキ（Akatsuki Inc.)　の@shimpeiws さんによる発表についてのまとめになります。

こちらも、"step by step BFF"と同じくSPA,BFFに関連するプレゼンテーションですが、

新規のアプリーケーション開発を通じて発生した課題と解決法、
これからのアクションを通じて、どのようにBFFを使おうと考えているかということが、
非常に分かりやすく説明されていました。
特に、これからSPA+Microserviceな構成で新規でアプリを作ることを検討されている方は見ておくと良いスライドだと思います。

発表は、大きく分けて、
1 - 要件とアーキテクチャ
2 - 開発初期での選択と集中と課題
3 - BFFのプロトタイプの実装
という三部構成でした。特に2を経て、どういう経緯でBFFを導入しようと思ったかという点が勉強になります。

1 - 要件とアーキテクチャ

要件
  • 今回はWEBからスタートするアプリだったそうです。(なんのアプリなんだろう、、)

後からネイティブアプリが出る可能性が高いとのこと

  • インタラクションが多いUI(ほんとにこれとSPAは相性いい)
  • 長期的な運用になる見込み(保守性とスケーラビリティ)
アーキテクチャ

Front-End

  • SPA(Single Page Application)

Server Side

Infrastructure

  • GCP
  • Kubernates

実際の構成も紹介されていました。(8~9スライド目)
一般的なSPA + API構成といった感じです。

2 - 開発初期での選択と集中と課題

まだまだ絶賛開発中な感じなのかもしれない。と話を聞いて思った。
短期間で結構色々変わっているな、という印象も。
このような組織のサイズと期間で、開発を進めているらしい。

立ち上げ期(2Month) 開発初期(4Month) 開発中期(これから)
チーム 1チーム(4名) 1チーム(5名) 4チーム
開発内容 - 開発フロー整備
- QA/Production環境構築
- 基本機能一通り
 - アイテムタイプの追加
- 口コミの実装
- 全文検索
- バグ・負債を若干返済
 - グロースハック施策
- 基盤となる機能の開発
- インフラ・ミドルウェア・デプロイの整備
ハイライト - アーキテクチャ・設計指針決定
- 開発ボリュームを抑えきれず混乱		 - アーキテクチャに大きく手は入れてない
- スクラム開発の運用を手探り		 - チームの分割
- マイクロサービス化の推進
- 中長期的な運用の開始
  • 開発中期に入っていきなり4チームになるとか結構ドラスティック。
  • 開発初期と呼んでいるフェーズで、ある程度なのかもしれないですが、きちんとバグ・負債を返している
  • 組織が別れたタイミングと、マイクロサービス化のタイミングが重なる

そして、この後のスライドが結構衝撃的だったんですが、

- Ruby(15,000行)
- React(60,000行!!!)
- JavaScript(25,000行)

上のスライドの期間をみても半年弱なので、期間に対してかなりのコード量だな、とは思いました。
とにかくガンガンコード書いた感じが伝わって来ますね。

初期の設計思想としては、

  • SPA + SSRすること
  • シンプルなAPIな設計

の2点に重きをおいているようでした。
ブレイクダウンしています。

SPA + SSRすること

なぜやったか?

  • 複雑なインタラクションとイニシャルビューの表示を早くしたい
  • -> SPA + SSR
  • -> React + Redux構成にした

Pros

  • ダイナミックなWebフロントエンドを作りやすい
  • SPAできる(ルーティング、State管理)

Cons

  • 開発工数が一時的にあがる
  • Node.js分が入って、開発全体でのデプロイ、管理コストが増えた
シンプルなAPI設計にすること

開発の初期段階では、API設計はとにかくシンプルにすることを意識、優先したということです。

具体的には、APIはRESTにしたそう。

  • ドメイン設計にかける時間を十分にとれないから一旦ある程度諦めたという話が考えさせられました。ドメイン設計は諦めたけど、RESTFulにはする、という点が特に。どれ位RESTなのか、という点が気になります。
  • 画面にべったりそったAPIで保守性をさげたくない(特定のアプリ用のAPIたくさん作りたくない)

ドメインは考えないものの、APIはRESTで作るから、ある程度リソースの粒度や認識が定義されていたということでしょうか。
いずれにしても、初期のレビューでチーム内の意識統一を進めて行ったという点が非常に共感できました。これがしっかり出来ないと、スケールしたりチーム分けた瞬間に崩れ去ります。。

Pros

  • SpecificなAPIは作られなかった(特定のプロダクト、機能に用途に限定されたような)
  • 設計・実装が楽でバグも少なかった(いいね)

Cons

  • フロントエンドが辛くなった(!!!)

"何が辛い?"
1.APIを呼ぶ回数が増える
オーケストレーション層がない状態でREST APIが増えると(設計次第な所はあると思いますが)ある操作をするのに、たくさんAPIを呼ばないといけないケースがあります。

2.APIを呼ぶのに、順番の依存が発生することがある
※これは、一概にRESTでAPIを作ったことだけが原因ではないと思いますが

APIを呼ぶのに依存が増えると、そのAPIの使い方が分かりにくくなるし、
リリースに結構厳しい依存ができて、結果的にRESTであるにも関わらず修正しにくくなる(フロントとの依存が結構強かったりして)とかもあります。

スライドでも

  • 6並列でAPIを呼んだ後で直接でAPIを2つ呼ぶ

という例が紹介されていました。(きっと実際にあるんだろうな、、)

これらの問題を"アーキテクチャ的な観点"で解決する為に、BFFを導入する流れになっているようです。

開発初期振り返り

3 - BFFのプロトタイプの実装

これからBFFを実装していく、というフェーズのよう。

  • I/Fは画面に必要なものをまとめて返す
  • レスポンス遅いのはダメ
  • フロントエンドと密結合するので、更新頻度は高い
    • フロントエンド側の人間が気軽に触れる方が良い
プロトタイプ
  • 一覧に商品と商品についたコメントを表示する
  • ログイン済のユーザのみ見れる(認証)

という例でBFFのプロトタイプの実装が紹介されていました。
基本的には、開発初期にシンプルなAPIを設計したことでフロントエンドが辛くなっていた部分を、BFFが引き受けているという印象です。

所感

  • SPAとしては割とベーシックで、SPAじゃないアプリでBFFやMicroserviceとやりとりする場合でも、共通して話せる話題が多かった気しました。
  • 新規でアプリケーションを作る際の流れにそって話が進んで行ったので、

直面されていた課題がイメージしやすく、自分だったらどうするのかな
ということを考えながら話を聞くことができました。

  • BFFをリアーキテクトとして使っている点は、前回のブログとも同じなのかなと。

ProxyとしてBFFを差し込む、という感じは、たとえ最初からSPA+Microserviceの構成で作ったとしても同じ、という印象を受けました
最初に裏をRestで作るところがうまく行ってるのか気になる、バックエンド側のリファクタリングとか今今発生しているのかとか