バックエンドエンジニアがフロント開発をする意義
はじめに
こんにちは、まつぼっくりです。ナビタイムジャパンで公共交通データを利用したサービスのバックエンド開発を担当しています。
今回フロントエンドの開発を経験し、それを通じて得られたバックエンドエンジニアとしての気づきについてご紹介いたします。
なお、本記事で述べている「バックエンド」とは、BFF(Backend For Frontend)のことを指しています。今回開発したサービスにおけるBFFの役割、メリットについても合わせて簡単にご紹介したいと思います。
今回開発した内容
Webで経路探索を行う新規サービスにおいて、探索結果を表示する画面を開発しました。
経路探索エンジンが求めた複数のルートに対して、ルート概要の一覧や各ルートの詳細な内容を表示します。ルートの詳細に表示する内容は、時刻はもちろんのこと、運賃や利用する公共交通機関の情報、運行情報など多岐に渡ります。
バックエンドとフロントエンドの役割
今回のサービスではBFFを採用しています。フロントエンド（各クライアント）は、本サービス用に設計されたAPIを呼び出して情報を取得します。
BFFが存在しない場合、取得した情報を処理するロジックをフロントが全て行う必要がありましたが、これをBFFへ分離することでフロントは表示に関する処理に集中することができます。
また、アプリ版とWeb版といった、異なるプラットフォームに跨るプロダクトの開発も容易になります。
バックエンドとフロントエンド、それぞれの役割をまとめると以下になります。
バックエンド
サービスが提供する機能に必要な情報を外部リソースから取得する
取得した情報を扱いやすく加工する
フロントエンド
画面仕様に沿った描画を行う
インターフェースからの操作に応じて情報を更新する
…とは言え、以上の原則はあるものの、いざ実際に手を動かしてみるとどこまでバックエンドにまかせるのか？という疑問は常に生まれ、線引きを決めることの難しさを感じていました。
実際にフロントを触って見えた理想と現実
フロントエンドを触るまで、私は表示・画面に関する情報はフロントエンドの仕事という意識が強く、表示仕様に依存する情報は必要に応じてフロントエンド側で処理して欲しいという考えで開発を行っていました。
しかし、いざ自分がフロント側を開発する番となると、扱いやすいように加工されたはずの情報でもフロントエンドでの実装に手間がかかってしまう場面に直面しました。
例えば、定期券運賃には以下の情報が含まれます。バックエンドのAPIが返却する内容では、検索結果の一部分として定期券情報がルートの区間ごとに返却されていました。
定期券が適用される区間
区分（通勤・通学・高校）
期間（1か月・3か月・6か月）
運賃額
しかし、今回のサービスでは定期券の運賃を表示する画面はルートの内容とは別に存在し、区分ごとに切り替えて表示する必要もあったため、これを区分ごとにまとめる処理がフロント側で必要となってしまいました。
このAPIの返却値の構造は、バックエンドの開発者という視点では、定期券の情報という事実自体は表現できており違和感のないものだったので、いままで私が開発してきたバックエンドはフロントエンドの開発者にとっては使いづらい、実装が大変なところがあったかもしれないと反省したのでした。
役割分担の考え方
では、バックエンドとフロントエンド、どのような役割分担が望ましいのかという話になります。先ほど挙げたの例のように、バックエンド側で表示する画面に合わせた構造にすることはメリットがある一方、特定のプラットフォームの表示に依存しすぎた情報をバックエンドに持たせるのはBFFを構築したメリットを活かせなくなってしまいます。
ひとつの考えとして、以下のような場合には表示に依存する内容でもBFF側の役割とするのが良いのではないでしょうか。
特定のUIの技術・コンポーネントに依存していない
データの操作にドメイン知識が必要
ビジネスロジックが含まれている
まとめ
バックエンドとフロントエンドの両方の開発を経験することで、BFFにおける最適な役割分担についての理解を深め、今後のバックエンド開発のための学びを得ることができました。このことはプロダクト全体の開発効率向上にも寄与すると考えています。
この経験が少しでもみなさんのお役に立てれば幸いです。また、機会があれば是非とも挑戦していただければと思います。