Why Livon Exists
LIVON exists to keep one deterministic schema across transport, runtime execution, publish/subscription flow, and generated client APIs.
Real-world context
In distributed teams, the same schema is often redefined multiple times:
- transport payload assumptions
- backend handler input/output types
- publish event payloads
- frontend subscription payload types
- API documentation snippets
Each redefinition creates another place where drift can start.
Structural duplication creates drift
| Execution boundary | Typical drift source | LIVON |
|---|---|---|
| Transport to runtime | ad-hoc payload parsing | parse with schema at receive step |
| Operation input to logic | handwritten input interfaces | operation input schema |
| Logic output to transport | implicit output shape | operation output schema |
| Publish to subscription | event payload remapping drift | publish map + subscription schema |
| Server to client docs | stale docs and examples | generated API + JSDoc from schema |
Why this matters for engineering managers
- Structural duplication increases coordination cost across teams.
- Boundary failures surface late and consume incident/debug time.
- Schema ownership becomes unclear when each layer has its own shape definition.
LIVON reduces structural duplication by making the schema executable and deterministic at each integration point.
Why this matters for senior developers
- Validated-by-default execution keeps business logic focused on valid data.
- Schema symmetry keeps backend/frontend composition mentally aligned.
- Generated client APIs and schema-driven docs reduce manual sync work.
Design decision
LIVON is not positioned as only validation or only transport. It is a deterministic runtime that treats validation, execution, publish/subscription, and client generation as one aligned system.
Distinction from gRPC, GraphQL, and Socket.IO
| Dimension | gRPC | GraphQL | Socket.IO | LIVON |
|---|---|---|---|---|
| Primary center | RPC transport schema | query and resolver graph | realtime transport channels | deterministic execution model |
| Where schema drift starts | between proto and runtime handler behavior | between schema, resolver behavior, and event payloads | between emitted event payloads and handler assumptions | one schema drives receive, exec, send, publish, subscribe, and generated client API |
| Realtime publish and subscribe alignment | usually added as separate stream/event modeling | often resolver-specific and implementation-defined | event naming is explicit, payload schemas are manual | operation publish mapping and subscription payload schema stay structurally aligned |
| Generated client developer docs | depends on toolchain and comments | depends on schema descriptions and codegen setup | typically manual for event handlers | schema doc metadata flows into generated TypeScript and JSDoc for operations and subscriptions |
gRPC, GraphQL, and Socket.IO can still be used as transport or API layers. LIVON focuses on keeping one deterministic schema through the full execution lifecycle.