Skip to content

Omnia needs a backend #35

Description

@ayushdevv2

Omnia has a well-designed simulation engine (the packages/* workspace) but it has no independent backend/runtime service. Everything that would normally live in a backend like session lifecycle, turn orchestration, model routing, state persistance and config/credential management is implemented inside apps/gui and reachable only through Next.js Server Actions.

The "GUI" is currently performing several functions:

  • a rendering layer
  • an RPC/API layer
  • a stateful runtime host.

What Needs to be done

  • Extract packages/runtime for core engine reusability  #36
  • Put an API boundary in front of it using REST/tRPC/WebSocket instead of Server Actions as the only contract. Server Actions can remain the client's way of talking to that API, but the API should be independently callable and versioned.
  • Replace client-driven polling with server-driven ticking. A background worker (queue, cron, or a long-lived process with its own event loop) should own turn advancement so turn orchestration is decoupled from the browser tab.
  • Separate session durability from the web process's local disk — even just moving data/ to a shared volume/DB service removes the single-instance constraint, and is a prerequisite for any multi-replica deployment.
  • Bring the turn-executor/alias-handoff logic under the existing Tier 1/2/3 testing discipline once it's a package which is the highest-value testing gap in the repo today.
  • Add an auth/secrets boundary or encrypt stored provider API keys and gate the config/provider-CRUD actions.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions