Skip to main content

OpenAPI Migration Plan for VibeTunnel

Overview

This document outlines the plan to adopt OpenAPI 3.1 for VibeTunnel’s REST API to achieve type safety and consistency between the TypeScript server and Swift clients.

Goals

  1. Single source of truth - Define API contracts once in OpenAPI spec
  2. Type safety - Generate TypeScript and Swift types from the spec
  3. Eliminate inconsistencies - Fix type mismatches between platforms
  4. API documentation - Auto-generate API docs from the spec
  5. Gradual adoption - Migrate endpoint by endpoint without breaking changes

Current Issues

  • Session types differ completely between Mac app and server
  • Git repository types have different field names and optional/required mismatches
  • No standardized error response format
  • Manual type definitions duplicated across platforms
  • Runtime parsing errors due to type mismatches

Implementation Plan

Phase 1: Setup and Infrastructure (Week 1)

1.1 Install Dependencies

1.2 Create Initial OpenAPI Spec

Create web/openapi/openapi.yaml:

1.3 Setup Code Generation

TypeScript Generation (web/package.json):
Swift Generation (Xcode Build Phase):
  1. Add swift-openapi-generator to Package.swift
  2. Add build phase to run before compilation:

1.4 Create Shared Components

Define reusable schemas in web/openapi/components/:

Phase 2: Migrate Git Endpoints (Week 2)

Start with Git endpoints as they’re well-defined and isolated.

2.1 Define Git Schemas

2.2 Update Server Implementation

2.3 Update Mac Client

Phase 3: Migrate Session Endpoints (Week 3)

Session endpoints are more complex due to WebSocket integration.

3.1 Standardize Session Types

3.2 Create Session Operations

Phase 4: Runtime Validation (Week 4)

4.1 Add Request Validation Middleware

4.2 Add Response Validation in Development

Phase 5: Documentation and Testing (Week 5)

5.1 Generate API Documentation

5.2 Add Contract Tests

Migration Checklist

Endpoints to Migrate

  • Git APIs (Phase 2)
    • GET /api/git/repo-info
    • GET /api/git/repository-info
    • GET /api/git/remote
    • GET /api/git/status
    • POST /api/git/event
    • GET /api/git/follow
  • Session APIs (Phase 3)
    • GET /api/sessions
    • POST /api/sessions
    • GET /api/sessions/:id
    • DELETE /api/sessions/:id
    • POST /api/sessions/:id/resize
    • POST /api/sessions/:id/input
    • WS /ws (v3 framing; not OpenAPI)
  • Repository APIs (Phase 4)
    • GET /api/repositories/discover
    • GET /api/repositories/branches
  • Worktree APIs (Phase 4)
    • GET /api/worktrees
    • POST /api/worktrees
    • DELETE /api/worktrees/:branch
    • POST /api/worktrees/switch

Success Metrics

  1. Zero runtime type errors between Mac app and server
  2. 100% API documentation coverage
  3. Contract tests for all endpoints
  4. Reduced code - Remove manual type definitions
  5. Developer velocity - Faster API development with code generation

Long-term Considerations

Future Enhancements

  1. GraphQL Gateway - Add GraphQL layer on top of REST for complex queries
  2. API Versioning - Use OpenAPI to manage v1/v2 migrations
  3. Client SDKs - Generate SDKs for other platforms (iOS, CLI tools)
  4. Mock Server - Use OpenAPI spec to run mock server for testing

Breaking Changes

When making breaking changes:
  1. Version the API (e.g., /api/v2/)
  2. Deprecate old endpoints with sunset dates
  3. Generate migration guides from schema differences

Resources