1d73209e89
* docs: add Architecture Decision Records (ADRs) Established a system for documenting architectural decisions. - Created docs/adr directory - Added ADR template (0000-template.md) - Established ADR process in docs/adr/README.md - Documented 4 key existing decisions (0001-0004) - Integrated ADRs into mkdocs.yml and docs/index.md * docs: add Architecture Decision Records (ADRs) Established a system for documenting architectural decisions. - Created docs/adr directory - Added ADR template (0000-template.md) - Established ADR process in docs/adr/README.md - Documented 4 key existing decisions (0001-0004) - Integrated ADRs into mkdocs.yml and docs/index.md - Fixed formatting in pkg/io/local/client.go * docs: add ADRs and fix auto-merge CI - Added Architecture Decision Records (ADRs) to docs/adr/ - Integrated ADRs into mkdocs.yml and docs/index.md - Localized .github/workflows/auto-merge.yml to fix "fatal: not a git repository" error in the reusable workflow by adding explicit --repo context.
1.5 KiB
1.5 KiB
ADR 0002: IPC Bridge Pattern
- Status: accepted
- Deciders: Project Maintainers
- Date: 2025-05-15
Context and Problem Statement
Wails allows direct binding of Go methods to the frontend. However, as the number of services and methods grows, managing individual bindings for every service becomes complex. We need a way to decouple the frontend from the internal service structure.
Decision Drivers
- Decoupling services from the frontend runtime.
- Simplified binding generation.
- Centralized message routing.
- Uniform internal and external communication.
Considered Options
- Direct Wails Bindings for all services.
- IPC Bridge Pattern (Centralized ACTION handler).
Decision Outcome
Chosen option: "IPC Bridge Pattern", because it allows services to remain agnostic of the frontend runtime. Only the Core service is registered with Wails, and it exposes a single ACTION method that routes messages to the appropriate service based on an IPC handler.
Positive Consequences
- Only one Wails service needs to be registered.
- Services can be tested independently of Wails.
- Adding new functionality to a service doesn't necessarily require regenerating frontend bindings.
- Consistency between frontend-to-backend and backend-to-backend communication.
Negative Consequences
- Less type safety out-of-the-box in the frontend for specific service methods (though this can be improved with manual type definitions or codegen).
- Requires services to implement
HandleIPCEvents.