Skip to main content

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 boundaryTypical drift sourceLIVON
Transport to runtimead-hoc payload parsingparse with schema at receive step
Operation input to logichandwritten input interfacesoperation input schema
Logic output to transportimplicit output shapeoperation output schema
Publish to subscriptionevent payload remapping driftpublish map + subscription schema
Server to client docsstale docs and examplesgenerated 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.

How Livon Differs From Other Tools

LIVON is a deterministic runtime focused on cross-layer alignment, not just one layer of the stack.

Comparison

DimensionValidation-only toolsTransport/RPC-only toolsLIVON
Runtime boundary validationinput parsing onlyoften delegated to user landvalidated-by-default across receive, execute, send, publish, and subscribe
Schema drives executionpartialusually noyes, schema drives execution behavior
Publish/subscribe modeloptional custom layertransport events without schema couplingfirst-class operation-to-subscription mapping
Generated IDE documentationusually manualusually manualschema doc metadata to generated JSDoc
Deterministic execution envelopenot centraltransport-centricshared deterministic envelope model across modules

Positioning summary

LIVON should be evaluated as a schema-driven interface workflow:

  • a single schema source
  • deterministic boundary enforcement
  • interface symmetry between backend and frontend

Practical implication

This model reduces structural duplication and keeps behavior explicit where systems integrate.

Ecosystem comparison (gRPC, GraphQL, Socket.IO)

DimensiongRPCGraphQLSocket.IOLIVON
Primary centerRPC transport schemaquery and resolver graphrealtime transport channelsdeterministic execution model
Where schema drift startsbetween proto and runtime handler behaviorbetween schema, resolver behavior, and event payloadsbetween emitted event payloads and handler assumptionsone schema drives receive, exec, send, publish, subscribe, and generated client API
Realtime publish and subscribe alignmentusually added as separate stream/event modelingoften resolver-specific and implementation-definedevent naming is explicit, payload schemas are manualoperation publish mapping and subscription payload schema stay structurally aligned
Generated client developer docsdepends on toolchain and commentsdepends on schema descriptions and codegen setuptypically manual for event handlersschema 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.

Role-specific impact

For detailed role examples and tradeoffs: