Story: Client/server foundations
Table of Contents
This page documents a story in Sprint 02. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
Goal
Introduce a client/server architecture into the project. The Qt
application becomes the client; a runtime process — built on Boost
cobalt — becomes the server. A new comms library carries the
messages between them, and the risk module is the first consumer.
Status
| Field | Value |
|---|---|
| State | DONE |
| Parent sprint | Sprint 02 |
| Now | Story closed; cobalt server/client running, comms library extracted, risk module exchanges messages. |
| Waiting on | None. |
| Next | None. |
| Last touched | 2025-10-15 |
Acceptance
- A cobalt-based server runs and accepts connections from the Qt client.
- A
commslibrary exists and is consumed by both client and server. - The risk module sends and receives messages over
comms. - The architecture is documented in the whiteboarding artefact (see sprint housekeeping).
Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Implement a cobalt-based server and client | DONE | 2025-09-15 | 2025-09-21 | Build the runtime split: a Boost.cobalt-based server process and a client embedded in the Qt application. |
| Create a comms library | DONE | 2025-09-22 | 2025-09-25 | Extract a comms library so the messaging types live in one place, separate from client and server domain code. |
| Add messaging for risk | DONE | 2025-09-26 | 2025-09-30 | Wire the risk module as the first consumer of the comms library — request/response over cobalt. |
| Create a GRPC-based service | ABANDONED | 2025-09-01 | 2025-09-10 | Explore GRPC as the client/server substrate. Abandoned in favour of cobalt. |
Decisions
- Cobalt over GRPC
- GRPC was explored first but its codegen and build complexity for our use case did not justify the benefit. Cobalt gives us coroutine-based async over plain sockets with no IDL.
- 0MQ explored, not chosen
- 0MQ patterns were attractive but
added a second messaging substrate that was hard to justify
alongside the cobalt path. Both records preserved as
ABANDONED. - Comms as a separate library
- prevents the messaging types from bleeding into either client or server domain code.
Out of scope
- Authentication beyond the basic accounts/logins task — comes back as sprint 03's Login and sessions (with the authentication-bootstrap workflow itself further deferred).
- Performance tuning of the cobalt event loop.
- Reconnection / resilience semantics.
- Wiring the Qt client onto the cobalt server — sprint 03's Client console and Qt integration picks this up.
See also
- ores.connections — the connection-management primitives the cobalt server consumes.
- ores.eventing — the messaging substrate the comms library builds on.
- ores.qt — destination of the network surface in sprint 03.