In May 2026, the discussion around Dropping Indirect Type Sharing via OpenAPI and Adopting oRPC trended on Zenn, accelerating the shift in TypeScript monorepos from OpenAPI-based (generated typing) to oRPC-based (direct typing) type sharing.
The frequent problem in custom development where "the OpenAPI schema diverges from implementation, breaking the frontend" fundamentally stems from "sharing types indirectly via generation." This article outlines how to modernize client API projects to the 2026 standard.
Why OpenAPI type sharing is called "indirect"
Type sharing centered around OpenAPI follows this flow:
[OpenAPI YAML/JSON]
│
├─ generate ─→ [TS 型定義（クライアント）]
│
└─ generate ─→ [TS 型定義（サーバー）]
│
└─ 実装が変わると YAML 更新が必要The four issues with this flow are as follows:
| Issue | Impact on custom development projects |
|---|---|
| Dual management | YAML and implementation fall out of sync |
| Generation timing | Generated in CI → forgotten commits → breaks |
| Degraded type expressiveness | TypeScript's discriminated unions cannot be fully expressed |
| Decoupled runtime validation | Schemas and Zod validations are written redundantly |
This extends the discussion of "API surfaces" covered in Design patterns for turning existing SaaS APIs into MCP servers to internal communications between frontend and backend.
How oRPC transforms "direct type sharing"
oRPC is a library that shares TypeScript types directly between frontend and backend, originating from the tRPC lineage. The crucial difference from OpenAPI is that it does not rely on code generation.
[サーバー側 oRPC ルーター定義（TS）]
│
├─ export type AppRouter = ...
│
▼
[クライアント側 import type { AppRouter }]
│
└─ 完全な型補完が効くFour structural advantages
| Item | OpenAPI generated typing | oRPC direct typing |
|---|---|---|
| Generation step | Required (mandatory CI) | None |
| Type expressiveness | Constrained by YAML | Full TypeScript capabilities |
| Runtime validation | Separate Zod, etc. | Schema and types are unified |
| API documentation | Automated from YAML | Can export OpenAPI (oRPC supports both) |
| Public availability | Supported out of the box | OpenAPI compatibility layer available |
Because oRPC supports OpenAPI export out of the box, a hybrid approach is possible: "OpenAPI for external consumption, and direct typing internally between frontend and backend." This is a major differentiator from tRPC, explaining why it is viable for custom external SaaS projects.
Application criteria in custom development projects — Three pillars
Pillar 1: Client types
| Client | Recommendation |
|---|---|
| In-house TypeScript frontend (Next / Astro) | oRPC recommended (superior type completion) |
| Public API for third-party developers | Maintain OpenAPI + internal implementation via oRPC |
| Mobile (Swift / Kotlin) | OpenAPI required (cross-language) |
| For AI agents | Consider MCP server implementation separately |
Pillar 2: Monorepo configuration
oRPC delivers maximum value when built on a monorepo premise. Having frontend and backend in separate repos halves the benefits of type sharing. This alignment matches the "repository strategy" discussed in Custom AI development with a centralized multi-repo map.
Pillar 3: Team organization
In custom development projects where frontend and backend are developed by the same team or identical engineers, oRPC's productivity boost has an immediate impact. Conversely, when frontend and backend belong to completely separate organizations, OpenAPI may offer clearer boundaries that are easier to manage.
Migration design roadmap
[Phase 0: 評価] 1 週間
├ 既存 API の棚卸し（エンドポイント数・複雑度）
├ クライアント種別の整理
└ Go / No-Go 判断
[Phase 1: 基盤導入] 2 週間
├ oRPC ルーター骨組み
├ CI / build 統合
└ 既存 OpenAPI との並行運用準備
[Phase 2: 段階移行] 6 〜 12 週間
├ エンドポイントを機能単位で oRPC 化
├ FE 側で oRPC クライアント呼び出しに置換
└ E2E テスト維持
[Phase 3: OpenAPI 出力] 2 週間
├ 外部公開エンドポイントの OpenAPI 出力
├ ドキュメントサイト整備
└ クライアント SDK 自動生成
[Phase 4: 旧コード除去] 2 〜 4 週間
├ 旧 OpenAPI 生成コード削除
├ 関連ライブラリの整理
└ 移行完了報告By advancing Phase 2 feature by feature, teams can maintain the classic custom development pattern of "continuous delivery without downtime during migration."
oRPC adoption clauses to include in client contracts
| Clause | Details | What the client should verify |
|---|---|---|
| Public API compatibility | Maintenance and compatibility guarantees for OpenAPI output | Impact on existing external clients |
| Endpoint naming conventions | RPC style vs. REST style | Alignment with customer operational conventions |
| Error design | Mapping business errors to HTTP status codes | Consistency with existing monitoring |
| Runtime validation | Scope of Zod-based input validation | Security requirements |
| Rollback conditions | Rollback provisions if migration proves impractical | Risk management |
In particular, by explicitly stipulating "public API compatibility" in contracts—guaranteeing that "even if oRPC is adopted internally, it remains exposed as OpenAPI externally"—teams can migrate without disrupting external developers.
Four common pitfalls
Pitfall 1: Overestimating the speed of "efficient type completion"
The greatest value of oRPC lies in "preventing type mismatches," rather than claiming to "triple implementation speed." Explain this to customers from the perspective of "reducing defects."
Pitfall 2: Confusion in REST-accustomed teams
Teams unaccustomed to RPC styles often feel uncomfortable with the pattern of "expressing functionality through method names." Schedule a design review session during initial reviews.
Pitfall 3: Explanations to external developers
Even if external endpoints are exposed via OpenAPI, some clients become anxious when hearing that "the internal implementation uses oRPC." Share sample OpenAPI outputs early on.
Pitfall 4: Omissions in error response design
Because oRPC can express errors via TypeScript errors, teams tend to downplay HTTP statuses. Establish a design consistent with monitoring and logging early in the contract.
Summary — Moving from "generation" to "sharing"
What oRPC signals is the end of the era of "indirect type sharing via generation." In the typical custom development setup of a TypeScript monorepo with in-house frontend and backend, migrating to oRPC reduces failures caused by OpenAPI generation discrepancies to near zero.
Migrating from OpenAPI to oRPC involves effort levels that vary widely depending on endpoint volume, client types, and monorepo structure. We provide customized estimates ranging from migration feasibility assessments to roadmap design based on your project's context. If you are experiencing challenges such as "OpenAPI sync discrepancies causing monthly incidents" or "wanting to modernize a TypeScript monorepo to the 2026 standard," feel free to reach out via our inquiry form.
