Wailsの仕組み

Wailsは、バックエンドにGo、フロントエンドにWeb技術を使用してデスクトップアプリケーションを構築するためのフレームワークです。しかし、Electronとは異なり、Wailsはブラウザをバンドルしません。代わりにOSのネイティブWebViewを使用します。

Electronとの主な違い:

項目	Wails	Electron
ブラウザ	OS提供のWebView	バンドルされたChromium (~100MB)
バックエンド	Go (コンパイル済み)	Node.js (インタプリタ)
通信	メモリ内ブリッジ	IPC (プロセス間通信)
バンドルサイズ	~15MB	~150MB
メモリ使用量	~10MB	~100MB+
起動時間	<0.5秒	2-3秒

コアコンポーネント

1. ネイティブWebView

Wailsは、OSに組み込まれたウェブレンダリングエンジンを使用します。

WebView2 (Microsoft Edge WebView2)

Chromiumベース (Edgeブラウザと同じ)
Windows 10/11にプリインストール
Windows Updateによる自動更新
最新のウェブ標準を完全にサポート

これが重要な理由:

バンドルされたブラウザがない → アプリのサイズが小さい
OSネイティブ → より良い統合とパフォーマンス
自動更新 → OSの更新からのセキュリティパッチ
馴染みのあるレンダリング → システムブラウザと同じ

2. Wailsブリッジ

ブリッジはWailsの心臓部であり、GoとJavaScript間の直接通信を可能にします。

動作原理:

フロントエンドがGoメソッドを呼び出す (自動生成されたバインディング経由)
ブリッジが呼び出しをJSONにエンコード (メソッド名 + 引数)
ルーターが登録されたサービスからGoメソッドを検索
Goメソッドが実行され、値を返す
ブリッジが結果をデコードし、フロントエンドに送信
JavaScriptでPromiseが解決され、結果を受け取る

パフォーマンス特性:

メモリ内: ネットワークオーバーヘッドなし、HTTPなし
可能な限りゼロコピー (大量データの場合)
デフォルトで非同期: 両側でブロッキングしない
型安全: TypeScript定義が自動生成される

3. サービスシステム

サービスは、Goの機能をフロントエンドに公開するための推奨される方法です。

// Define a service (just a regular Go struct)
type GreetService struct {
    prefix string
}

// Methods with exported names are automatically available
func (g *GreetService) Greet(name string) string {
    return g.prefix + name + "!"
}

func (g *GreetService) GetTime() time.Time {
    return time.Now()
}

// Register the service
app := application.New(application.Options{
    Services: []application.Service{
        application.NewService(&GreetService{prefix: "Hello, "}),
    },
})

サービス検出:

Wailsは起動時に構造体をスキャン
エクスポートされたメソッドがフロントエンドから呼び出し可能になる
型情報が抽出され、TypeScriptバインディングに使用される
エラー処理は自動 (Goのエラー → JSの例外)

生成されたTypeScriptバインディング:

// Auto-generated in frontend/bindings/GreetService.ts
export function Greet(name: string): Promise<string>
export function GetTime(): Promise<Date>

サービスの利点:

型安全: 完全なTypeScriptサポート
自動検出: メソッドの手動登録不要
整理された: 関連する機能をグループ化
テスト可能: サービスは通常のGo構造体

サービスについて詳しく学ぶ →

4. イベントシステム

イベントは、コンポーネント間のpub/sub通信を可能にします。

使用例:

ウィンドウ間通信: 1つのウィンドウが他のウィンドウに通知
バックグラウンドタスク: GoサービスがUIに進捗を通知
状態同期: 複数のウィンドウを同期状態に保つ
緩結合: コンポーネントは直接参照を必要としない

例:

// Go: Emit an event
app.Event.Emit("user-logged-in", user)

// JavaScript: Listen for event
import { Events } from '@wailsio/runtime'

Events.On('user-logged-in', (user) => {
    console.log('User logged in:', user)
})

イベントについて詳しく学ぶ →

アプリケーションのライフサイクル

ライフサイクルを理解することで、リソースの初期化とクリーンアップのタイミングを知ることができます。

Lifecycle hooks:

app := application.New(application.Options{
    Name: "My App",

    // Called before windows are created
    OnStartup: func(ctx context.Context) {
        // Initialise database, load config, etc.
    },

    // Called when app is about to quit
    OnShutdown: func() {
        // Save state, close connections, etc.
    },
})

Learn more about lifecycle →

Build Process

Understanding how Wails builds your application:

Build steps:

Analyse Go code
- Scan services for exported methods
- Extract parameter and return types
- Generate method signatures
Generate TypeScript bindings
- Create .ts files for each service
- Include full type definitions
- Add JSDoc comments
Build frontend
- Run your bundler (Vite, webpack, etc.)
- Minify and optimise
- Output to frontend/dist/
Compile Go
- Compile with optimisations (-ldflags="-s -w")
- Include build metadata
- Platform-specific compilation
Embed assets
- Embed frontend files into Go binary
- Compress assets
- Create single executable

Result: A single native executable with everything embedded.

Learn more about building →

Development vs Production

Wails behaves differently in development and production:

Development (wails3 dev)
Production (wails3 build)

Characteristics:

Hot reload: Frontend changes reload instantly
Source maps: Debug with original source
DevTools: Browser DevTools available
Logging: Verbose logging enabled
External frontend: Served from dev server (Vite)

How it works:

Benefits:

Instant feedback on changes
Full debugging capabilities
Faster iteration

Memory Model

Understanding memory usage helps you build efficient applications.

Memory regions:

Go Heap
- Your services and application state
- Managed by Go garbage collector
- Typically 5-10MB for simple apps
WebView Memory
- DOM, JavaScript heap, CSS
- Managed by WebView’s engine
- Typically 10-20MB for simple apps
Bridge Memory
- Message buffers for communication
- Minimal overhead (<1MB)
- Zero-copy for large data where possible

Optimisation tips:

Avoid large data transfers: Pass IDs, fetch details on demand
Use events for updates: Don’t poll from frontend
Stream large files: Don’t load entirely into memory
Clean up listeners: Remove event listeners when done

Learn more about performance →

Security Model

Wails provides a secure-by-default architecture:

Security features:

Method whitelisting
- Only exported methods are callable
- Private methods are inaccessible
- Explicit service registration required
Type validation
- Arguments checked against Go types
- Invalid types rejected
- Prevents injection attacks
No eval()
- Frontend can’t execute arbitrary Go code
- Only predefined methods callable
- No dynamic code execution
Context isolation
- Each window has its own context
- Services can check caller context
- Permissions per window possible

Best practices:

Validate user input in Go (don’t trust frontend)
Use context for authentication/authorisation
Sanitise file paths before file operations
Rate limit expensive operations

Learn more about security →

Next Steps

Application Lifecycle - Understand startup, shutdown, and lifecycle hooks
Learn More →

Go-Frontend Bridge - Deep dive into how the bridge works
Learn More →

Build System - Understand how Wails builds your application
Learn More →

Start Building - Apply what you’ve learned in a tutorial Tutorials →

アーキテクチャについて質問がありますか？ Discord で質問するか、API リファレンスを参照してください。