BridgeパターンでTauriアプリ開発を効率化する方法

React TypeScript Tauri techどうも、CoeFont でフロントエンドエンジニアをやってる uzimaru です。 フロントエンドエンジニアなんですが、最近は Tauri でデスクトップアプリアプリを作ってます。 そこで最近、Tauri でデスクトップアプリを開発する際に UI の開発やレビューのサイクルを高速化するために Bridge パターンを導入してみたので、その話をまとめようと思います。

Web フロントエンド開発と比べて、デスクトップアプリ開発には特有の悩みがあると感じています。

PM やデザイナーに変更内容を確認してもらうために、毎回アプリケーションをビルドする必要があります。 しかし、Web アプリケーションのようにビルドが速くなかったり、アプリケーションのバイナリを配布する必要があるため、この作業が大きな負担となります。

UI コンポーネントカタログツールである Storybook は非常に便利ですが、アプリケーション全体の挙動を確認するのは難しいという課題があります。 小さなコンポーネント単位での確認や実装には Storybook が有効ですが、実際の API との接続部分の動作確認は容易ではありません。

Web アプリケーションのように修正後すぐに全ユーザーへ反映できるわけではない点もデスクトップアプリ開発の難しさの一つです。 小さな修正ごとにリリースするフローを取るのは難しく、ユーザーが常に最新バージョンを使ってくれるとも限りません。そのため、頻繁なリリースが難しい場合があり、これはモバイルアプリ開発に近い感覚かもしれません。

これらの課題、特に確認の手間は開発スピードに大きく影響します。なんとか改善したいと考えました。

解決策: Bridge パターンの導入

そこで、 Bridge パターン を導入することにしました。 具体的には、Tauri の API に直接依存している部分を抽象化されたインターフェース（Bridge）に依存するように変更します。 interface の名前は tauri が invoke

このようにすることで、以下のようなメリットがありました。

UI コードから Tauri 固有の API 呼び出しがなくなります。これにより、UI 部分を Tauri 環境がなくても動作させやすくなります。

Tauri 固有の API を Web API ( MediaDevices

これにより、UI の変更確認のために毎回ビルドする手間が省け、開発サイクルを高速化できます。

Bridge パターンの実装方法はいくつか考えられます。

React Context を使う フロントエンドが React なので、Context API を使って Bridge の実装を注入する方法です。ただ、今回は React コンポーネント外のピュアな JavaScript/TypeScript モジュールからも利用したかったため、採用しませんでした。

モジュールスコープで実装を切り替える アプリケーションの初期化時に、実行環境（Tauri か Web か）を判定し、適切な Bridge の実装を読み込む方法です。

今回は 2. のモジュールスコープで実装を切り替える 方法を採用しました。 具体的には、Vite の import.meta.env.MODE

// src/bridge/index.ts import { useMemo } from "react"; import type { AudioCommand } from "./audio"; import type { CoreCommand } from "./core"; import type { LogCommand } from "./log"; import type { OsCommand } from "./os"; import type { UpdaterCommand } from "./updater"; // 他にも色々... type Command = { audio: AudioCommand; core: CoreCommand; log: LogCommand; os: OsCommand; updater: UpdaterCommand; }; let command: Command | null = null; // この関数を経由して実装を注入する export const setCommand = (c: Command) => { command = c; }; // この関数を経由して実装を取得する。主に React が使われていない関数などで使う export const getCommand = <T extends keyof Command>(cmd: T): Command[T] => { if (command === null) { throw new Error("command is not set"); } return command[cmd]; }; // React の場合はこの hooks を経由して取得 export const useCommand = <T extends keyof Command>(cmd: T): Command[T] => { const command = useMemo(() => { return getCommand(cmd); }, [cmd]); return command; };

この方法を導入する際に、一つ問題が発生しました。 Bridge の実装が dynamic import

// エラーになる例 // src/config.ts import { getCommand } from "./bridge"; // モジュールのトップレベルで呼び出すと初期化前に実行される可能性がある const osInfo = getCommand("os").type(); export const config = { os: osInfo, };

この問題は、Bridge の関数呼び出しを、初期化が完了した後に行われるように遅延させることで解決しました。具体的には、トップレベルでの直接呼び出しをやめ、関数やクラスのメソッド内など、アプリケーションの実行フローの中で呼び出すようにします。

// src/config.ts import { getCommand } from "./bridge"; // 関数にすることで評価を遅延する export const getConfig = () => { const osInfo = getCommand("os").type(); return { os: osInfo.type, }; };

Bridge パターンを導入することで、新しい機能を追加するたびに対応する Bridge インターフェースとその実装（Tauri 用と Web 用）を作成する必要が出てきました。この作業はパターン化されており、ボイラープレートコードが多くなりがちです。 そこで、plop というコード生成ツールを導入して、これらのボイラープレートコードを自動生成できるようにしました。

// plopfile.mjs export default ( /** @type {import('plop').NodePlopAPI} */ plop ) => { // generator 名: "bridge-context" plop.setGenerator("bridge-context", { description: "Generate a new context + type for a Bridge feature.", prompts: [ { type: "input", name: "name", message: "Bridge name:", }, ], actions: [ { type: "add", path: "src/bridge/{{kebabCase name}}/index.ts", templateFile: "plop-templates/bridge/type.hbs", }, { type: "add", path: "src/bridge/{{kebabCase name}}/tauri.ts", templateFile: "plop-templates/bridge/impl.hbs", }, { type: "add", path: "src/bridge/{{kebabCase name}}/web.ts", templateFile: "plop-templates/bridge/impl.hbs", }, ], }); };

// plop-templates/bridge/type.hbs export type {{pascalCase name}}Command = { // ここにメソッドや型を記述します } // plop-templates/bridge/impl.hbs import type { {{pascalCase name}}Command } from '.'; export const command: {{pascalCase name}}Command = { // ここに実装を記述します };

これにより、以下のようなコマンドで新しい Bridge コマンドを簡単に追加できるようになりました:

$ bun generate:bridge ? Bridge name: Example ✔ ++ /src/bridge/example/index.ts ✔ ++ /src/bridge/example/tauri.ts ✔ ++ /src/bridge/example/web.ts

このアプローチには、以下のようなメリットがあります:

開発スピードの向上 新機能のためのコードスケルトンを素早く生成できます

一貫性の確保 全ての Bridge コマンドが同じパターンで実装され、一貫性が保たれます

ミスの低減 必要なファイルやインポート文の追加漏れなどのミスを減らせます

Web 環境と Tauri 環境の実装差異

これでフロントエンド側には Tauri の API との依存がなくなったためブラウザで動かすことができるようになりました。 しかし、Tauri の環境でしか動かせない機能（FileSystem にアクセスするなど）もあるため完全に再現はできません。

オーディオ関連の機能は、Web ブラウザでも Web Audio API を利用することで Tauri 環境と同様の挙動をある程度再現できました。

// src/bridge/audio/index.ts // 入出力のAudioNodeの生成を管理する型 export interface AudioIOManager { connectDevice: (id: string) => Promise<AudioNode>; disconnect: () => void; } export type AudioCommand = { createInput: (audioContext: AudioContext) => AudioIOManager; createOutput: (audioContext: AudioContext) => AudioIOManager; };

一方で、以下のような機能は Web ブラウザでの再現が難しいものでした

// src/bridge/os/tauri.ts import { type } from "@tauri-apps/api/os"; export const command: OsCommand = { type, }; // src/bridge/os/web.ts export const command: OsCommand = { type: async () => { console.warn("Web環境では OS type の取得はサポートされていません"); // 仮で macos として処理する return "macos"; }, };

// src/bridge/fs/tauri.ts import { writeTextFile } from "@tauri-apps/api/fs"; export const command: FsCommand = { writeTextFile, }; // src/bridge/fs/web.ts export const command: FsCommand = { writeTextFile: async () => { console.log("Web環境ではファイルへの書き込みはサポートされていません"); }, };

このように、Web ブラウザの制約によって再現できない機能については、適切なログメッセージを出力したり、可能な範囲で代替実装を提供したりすることで対応しました。開発中はこのような差異があることを理解した上で、UI の確認を進めることができます。

Bridge パターンを導入した結果、以下のような効果がありました。

UI の変更確認のために Tauri アプリをビルドする必要がなくなり、Web ブラウザでほとんどの確認が完結するようになりました。これにより、待ち時間が大幅に削減されました。

これまでは Tauri 環境でしか動作確認が難しかった部分も、Web ブラウザで動作するようになったことで、Playwright のようなブラウザベースの E2E テストツールを導入しやすくなりました。 まだ、導入していませんが今後導入をしてリリース前の挙動の担保や意図しない変更を CI で防げるようにしたいと思っています。

今回は、Tauri アプリ開発の課題を解決するために Bridge パターンを導入した話を紹介しました。 フロントエンド開発ではあまり意識しないかもしれませんが、依存性逆転の原則のようなソフトウェア設計の基本原則が、このような場面で非常に役立つことを再認識しました。

CoeFont ではデスクトップアプリの他にもWebアプリケーションを一緒に作ってくれる仲間を募集しています！ 興味のある方は下の応募フォームからご連絡ください！

CoeFontPublicationAI音声プラットフォーム「CoeFont（コエフォント）」の公式テックブログです。