フロントエンド・アプリ−バックエンド・サービスというアーキテクチャーを採用するとして、具体的に両者の役割分担をどのように線引きすればよいでしょうか。
一つの結論として下記のように考えることができるでしょう。
システムの利用シナリオをよく支援し、システムの持つデータをよく渡り歩けるフロントエンドと業務のドメインのデータとプロセスをしっかり保全するバックエンド
・
フロントエンド・アプリには、まさに「ユーザー・エクスペリエンス」と称されるところの、システム利用時のスマートさ、「ユーザーのしたいこと」をよく支援するUIが求められます。「システムで出来ること」（＝機能）が単に整然とメニューに並んでいるような旧来のUIでは済みません。UIは利用者の利用局面のコンテキストによく沿って、利用局面毎の関心点から機能は再配置されなければなりません。加えて、明らかにPC向けとスマホ向けでUIの構成は変える必要があるでしょう。PCでは俯瞰性がより求められ、スマホでは文脈性がより求められるでしょう。
例えば、カスタマーサポートの業務アプリにおいて、顧客のプロフィールを参照している画面から、顧客の購入履歴、返品履歴、問い合わせ履歴などを参照しようというとき、都度トップメニューに戻って「返品」メニューを選んでから当該データを参照できるというようなメニューベースの画面構成はもはや許されないでしょう。PCで求められる俯瞰性とは、「顧客の一覧がよく俯瞰できる」といった観点も変わらず重要ですが、それよりも「現在関心を持っている顧客に関わる全ての情報が一目で（＝ほぼ一画面で）閲覧できる」という意味での俯瞰性です。スマホではそういった俯瞰性を実現するのは困難なので、代わりに文脈性がより重要です。つまり「今関心を持っている顧客について」というサブ・セッションを管理して、そのコンテキスト限定下で各種情報を渡り歩くことができるようなUIが期待されるでしょう。
フロントエンド・アプリは、それが「ユーザー・エクスペリエンス」であるために、利用者目線で、まさに「顧客志向」で設計されなければなりません。
・
一方のバックエンド・サービスですが、バックエンド・サービスの最も重要な特徴はその中核に業務の永続化データを保持していることです。バックエンド・サービスは、フロントエンド・アプリに対して、インターネット越しにAPI（Web API）を提供します。つまるところ、保持している業務データにフロントエンドから如何にアクセスさせるかが、バックエンド・サービスの提供するAPIの設計意図となります。
APIを公開する以上（※サードパーティーに対して公開するのであれば特に）、そのAPIを介してアクセスされる限りどのようにアクセスされても、業務のデータのconsistencyやintegrityが保全され、業務のプロセスとしても破綻しないことを保証することが、バックエンド・サービスには期待されます。参照時には適切にアクセスコントロールされることも期待されます。
華やかでプロフィットセンターとして注目されるフロントエンドに対して、バックエンドは明らかに地味で保守的です。
以前、「フロントエンド・エンジニアは、サーバー・ネットワークだけでなく、Web APIを提供しているこのようなバックエンド・サービスまで含めて“インフラ”だと認識している」というある方の話を紹介しました。“インフラ”という言葉の定義はさておき、フロントエンド・エンジニアはそのように見ている、ということは極めて象徴的、、否、むしろ極めてよくアーキテクチャーを表現していると言うべきでしょう。
◇
＜追記１＞
私は、フロントエンドが提供するユーザーインターフェースに対して、バックエンドが提供するAPIを「システムインターフェース」と称する事としています。
＜追記２＞
PCの画面は広いが故に俯瞰性を実現できる、というよりも、俯瞰性が期待されるのです。スマホも、文脈性で表現するしか無い、というよりも、小型携帯端末でよくものを表現するときには文脈性が期待されるのです。そして、ファブレットには適度に俯瞰的で適度に文脈的な絶妙な落としどころのUI/UXが期待されると思うのです。
◆以上
