Skip to content

Instantly share code, notes, and snippets.

@Quramy
Last active May 20, 2019 02:06
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save Quramy/dd505a537fdf1c88f2f497039cac0845 to your computer and use it in GitHub Desktop.
Save Quramy/dd505a537fdf1c88f2f497039cac0845 to your computer and use it in GitHub Desktop.
InsideFE2019 A-5のAMAで時間内にできなかった質問に対する回答

実際にBFFの開発向けUIは、開発者以外に使ってもらってどのようなコメントがありましたか?

「便利」と言ってもらえたのがやはり一番うれしかったですね。 別の事例だと、社外のシステムへの外接部分について、必ずしもテスト環境から接続可能とは限らないケースで、API呼び出しをフックできる機能としても使えた、というのが好評でした。

フロントエンドが使いやすいように API を定義することで、バックエンド側の実装に影響を与えてしまうことはありましたか?

BFFの存在意義の1つに「マイクロサービスを開発しやすく」がある以上、なるべくそういうケースとならないように注意はしていますが、満足にできているかはわからないですね。。。 もしかしたら、より良いAPI粒度が存在するのに、バックエンドがある程度我慢してくれている部分もあるかもしれませんね。。。

サーバーサイドからフロントになったということでしたが、チームのほとんどは似たような経歴の方が多いのでしょうか?

誤解を与えたかもしれませんが、私はサーバーサイド出身じゃないんですよ。 サーバーサイドで動くJavaのフレームワークを仕事にしていましたが、アプリケーションエンジニアではなかったのです。 他のメンバーでいうと、制作会社出身のフロントメインでやっていたメンバーもいれば、Railsでアプリを作っていた経験があるメンバーもいるので経験は色々ですね。

BFF自体のメンテナンスはサービス内で一貫して管理されているのでしょうか?それとも開発要件ごとに作成し直されるのでしょうか?

改修要件が発生するケースや、システム全体(BFF + micro services含めた)のリファクタリングの一環で見直すことがあります。 特にBFFにマッチョなロジックが入り込んでしまっているケースで、そのロジック部分をバックエンドのマイクロサービスに切り出してもらったり、というケースがありました。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment