Unified SPA

Unified SPAは、Linked Applicationと似ていますが、複数のSPAを何らかの方法で遷移させるアーキテクチャです。

単純にhyperlinkで遷移させる場合は、Linked Applicationと変わらず、SPA同士の遷移時はサーバーサイドレンダリングとなるため、ラウンドトリップが発生します。

Unified SPAにはもうひとつのパターンがあります。それは、SPA同士を結合させるApp Shellのレイヤーをつくるパターンです。

この場合では、App ShellレイヤーでSPA同士のクライアントサイドサイドレンダリングが行われるため、Linked Applicationのデメリットのひとつであったパフォーマンスのオーバーヘッドが少なくなります。

これを実現するには、meta-frameworkと呼ばれる single-spa のようなライブラリを利用します。設定部分のコード例は以下で、別々にデプロイされたアプリケーションを結合しています。

import { registerApplication, start } from 'single-spa';

registerApplication(
  'app2',
  () => import('@my-company/app2/main.js'),
  (location) => location.pathname.startsWith('/app2'),
  { some: 'value' }
);

registerApplication({
  name: 'app1',
  app: () => import('@my-company/app1/main.js'),
  activeWhen: '/app1',
  customProps: {
    some: 'value',
  }
});

start();

他にもライブラリがあるので、気になる方は本書のReading Listを御覧ください。

メリット・デメリット

SPAであるため、Linked Applicationと比較すると、フロントエンドとしてのインタラクティビティは向上するでしょう。SPA同士をシンプルに結合するだけでMicro Frontendsを実現できるところも良い点です。また、single-spaでは、Parcelsという仕組みを用いて共通パーツをつくることもできます。

Linked Applicationに比べたデメリットとしては、アプリケーションレイヤーでの単一障害点になりやすいという問題があります。App Shellレイヤーで何らかのバグがあれば、全体に影響が伝播してしまいますし、バージョンアップなどの影響範囲も大きいです。

まとめ

Linked Applicationを発展させた、Unified SPAというパターンを見ました。App Shellレイヤーを導入することで、かゆいところに手が届く一方、デメリットも存在します。シンプルなMicro Frontendsとしてはこちらの採用はまず考えても良いでしょう。