MuleSoft に出会いました

転職して３ヶ月が経ちました。新しい職場では MuleSoftというフレームワークでありランタイムであるツールを使って Web API の開発を行っています。

そのツール自体の良し悪しはおいといて... MuleSoft が API-led Connectivity という概念に基づき設計されており、初めてその概念を知りました。

今回は、そんな浅い状態で恐縮ですが API-led Connectivity について記載してみようと思います。

企業の抱える問題とDX

怪しげなタイトルですが、 MuleSoft は DX というキーワードに関連して登場することが多いです。「企業のあらゆるデータを API で統合して良い感じにしようぜ！（雑）」という、 API インテグレーションが MuleSoft の得意分野となっているようです。

この時に、 API-led Connectivity という設計思想で API を構築していくと、スマート、かつ、再利用性の高い状態になりますよ、という話です。つまり DX 実現のための設計思想なのかと感じます。

API-led Connectivity は、 API を３層に分割して配置する設計思想・パターンです。具体的には下図のような 3 層になります。

どこかで見たような 3 層構造ですよね。

MVC っぽいとか、 プレゼンテーション/アプリケーション/インフラストラクチャ っぽいとか、大体そんな感じだと思います。
つまり、既存の設計パターンを応用したマイクロサービス・アーキテクチャのパターンだと考えられます。

最下層に当たるシステム API は、データベースやバックエンドシステムを隠蔽しデータを抽象化します。この層のおかげで、どのようなデータベースを利用しているのか、何のバックエンドシステムなのかを気にせずにデータにアクセスできるようになります。

そのため基本的にシステムAPI は、データベースやバックエンドシステムと 1:1 で作成されます。

中間層のプロセス API は業務ロジックの集合です。システム API を利用してデータを集めドメインモデルを構築し、業務ロジックを実現します。

プロセス API は業務に応じて作成されます。また、プロセス API がプロセス API を call することもあります。

エンドユーザーに価値を提供するための機能を持つ API です。プロセス API を呼び出し価値を提供します。

エクスペリエンス API の関心は、エンドユーザーに向いています。つまり、フロントエンドアプリケーションに向いているので、 BFF として考えると分かりやすいと思います。

よく紹介される例では「Web用のエクスペリエンスAPI」と「ネイティブアプリ用のエクスペリエンスAPI」みたいな感じです（それが最適解なのかは不明ですが）。

私がこの API-led Connectivity に出会い最初に感じたことは「そんなにAPI連携して大丈夫なん？？？」でした。一つのデータを取得するだけでも、3 つの　API を経由するため、パフォーマンス面で非常に心配になりますよね。キャッシュとか活用するしかないですよねぇ。

また、本来(?)一つのコンポーネントが 3 つに別れ、 Web API として独立するため、複雑さは増していくと思います。
この辺りは Datadog などのオブザーバビリティリティ向上のためのツールの導入は不可避だと思います。

みなさん、 API-led Connectivity についてどう考えますでしょうか。すごく気になります。
これが主流になるのか、 DX を企む連中(言い方)の謳い文句なのか、、
私はまだなんとも言えません。

しかし、会社がこの流れに乗っているのは事実なので、何が良くて何が悪いのか、見極めていければと思います。