yuris/spacetimedb-defold

Fork 0

Vertical slice: chat over live 2.x server #2

New issue

Closed

opened 2026-08-19 06:49:07 +00:00 by yuris · 2 comments

yuris commented

2026-08-19 06:49:07 +00:00

Owner

Two clients connect to spacetime start + a published test module, both subscribe, one calls a reducer, both caches converge. Done = the SDK is real.

server/ test module (one table, two reducers) in Rust or TypeScript
example/ Defold project using stdb.connect
Verify subscribe -> reducer -> TransactionUpdate on both clients
Document the manual test in README

Ref: README 'Note' section.

Two clients connect to `spacetime start` + a published test module, both subscribe, one calls a reducer, both caches converge. Done = the SDK is real. - [ ] `server/` test module (one table, two reducers) in Rust or TypeScript - [ ] `example/` Defold project using `stdb.connect` - [ ] Verify subscribe -> reducer -> TransactionUpdate on both clients - [ ] Document the manual test in README Ref: README 'Note' section.

yuris added the

phase:slice

area:protocol

area:defold

labels

2026-08-19 06:49:07 +00:00

yuris added this to the v0.1 — vertical slice milestone

2026-08-19 06:50:03 +00:00

yuris referenced this issue from a commit

2026-08-19 06:56:01 +00:00

ci: unit tests + stylua + flake check on push and PR

yuris referenced this issue

2026-08-19 07:05:27 +00:00

Conformance in CI: works locally, blocked on runner environment #7

yuris referenced this issue

2026-08-19 07:05:40 +00:00

CD: tagged releases as Defold library dependency #13

yuris commented

2026-08-19 07:38:08 +00:00

Author

Owner

Server half is done (ee90548); the Defold half is what remains.

Working today:

server/index.js — chat module (table message with pk, reducers send_message / clear_all), published to a local 2.8.2 server with spacetime publish --js-path, so no Rust/wasm toolchain is needed
full round trip verified from a Node client: subscribe -> seeded rows, reducer call -> committed insert broadcast, clear_all -> deletes, bad query -> SubscriptionError, one-off query -> response
the Lua decoder + cache replay that exact session in test_fixtures.lua and end in the correct state

Two module gotchas worth remembering:

column options are a builder chain: t.u64().primaryKey().autoInc(), not t.u64({primaryKey:true}). The options-object form silently produces a table with no pk.
spacetime init and destructive publish need a TTY; in scripts use spacetime login --token "$TOKEN" and pipe yes y for --delete-data.

Remaining for this issue:

example/ Defold project consuming the SDK as a library dependency
Two engine clients against the same server, seeing each other's messages
bob build of the example in CI (#7)

**Server half is done** (ee90548); the Defold half is what remains. Working today: - `server/index.js` — chat module (table `message` with pk, reducers `send_message` / `clear_all`), published to a local 2.8.2 server with `spacetime publish --js-path`, so no Rust/wasm toolchain is needed - full round trip verified from a Node client: subscribe -> seeded rows, reducer call -> committed insert broadcast, `clear_all` -> deletes, bad query -> `SubscriptionError`, one-off query -> response - the Lua decoder + cache replay that exact session in `test_fixtures.lua` and end in the correct state Two module gotchas worth remembering: - column options are a **builder chain**: `t.u64().primaryKey().autoInc()`, not `t.u64({primaryKey:true})`. The options-object form silently produces a table with no pk. - `spacetime init` and destructive `publish` need a TTY; in scripts use `spacetime login --token "$TOKEN"` and pipe `yes y` for `--delete-data`. Remaining for this issue: - [ ] `example/` Defold project consuming the SDK as a library dependency - [ ] Two engine clients against the same server, seeing each other's messages - [ ] `bob build` of the example in CI (#7)

yuris referenced this issue

2026-08-19 07:38:08 +00:00

Generate schema.lua from spacetime describe --json #14

yuris commented

2026-08-19 08:34:35 +00:00

Author

Owner

Closed: the SDK runs inside a real Defold engine

SMOKE: PASS cached row id=1 sender=headless

The repo is now itself a Defold library project (game.project with include_dirs = stdb), whose bootstrap collection runs main/smoke.script: connect → subscribe → call_reducer("send_message", ...) → assert the row lands in the client cache. Driven by tools/conformance.sh, which brings up the server, publishes the module, builds headless with bob, and greps the verdict.

Two bugs it caught that no unit test could:

extension-websocket sends BINARY frames by default. The server then tries to BSATN-decode the JSON and drops the connection with unknown tag 0x7b for sum type ClientMessage (0x7b = {). Needs { type = websocket.DATA_TYPE_TEXT }.
require("websocket") fails at build time — native extensions register globals, so it must be _G.websocket. This one breaks the build, not just runtime.

Also fixed along the way: NixOS cannot exec Defold's generic linux binaries, so the flake gained defold-patch (patchelf interpreter + rpath) with an FHS env fallback.

What is deliberately not here

The "two engine clients seeing each other's messages" part. One client proves the binding, the protocol, and the cache; a second client proves the server broadcasts, which the fixture suite already covers (TransactionUpdate frames were captured from exactly that path). Not worth a second engine process at this stage — reopen if multiplayer-specific behaviour needs it.

CI integration is tracked separately in #7 (works locally, runner environment unresolved).

## Closed: the SDK runs inside a real Defold engine `SMOKE: PASS cached row id=1 sender=headless` The repo is now itself a Defold library project (`game.project` with `include_dirs = stdb`), whose bootstrap collection runs `main/smoke.script`: connect → subscribe → `call_reducer("send_message", ...)` → assert the row lands in the client cache. Driven by `tools/conformance.sh`, which brings up the server, publishes the module, builds headless with bob, and greps the verdict. Two bugs it caught that no unit test could: 1. **`extension-websocket` sends BINARY frames by default.** The server then tries to BSATN-decode the JSON and drops the connection with `unknown tag 0x7b for sum type ClientMessage` (`0x7b` = `{`). Needs `{ type = websocket.DATA_TYPE_TEXT }`. 2. **`require("websocket")` fails at build time** — native extensions register globals, so it must be `_G.websocket`. This one breaks the *build*, not just runtime. Also fixed along the way: NixOS cannot exec Defold's generic linux binaries, so the flake gained `defold-patch` (patchelf interpreter + rpath) with an FHS env fallback. ## What is deliberately not here The "two engine clients seeing each other's messages" part. One client proves the binding, the protocol, and the cache; a second client proves the server broadcasts, which the fixture suite already covers (`TransactionUpdate` frames were captured from exactly that path). Not worth a second engine process at this stage — reopen if multiplayer-specific behaviour needs it. CI integration is tracked separately in #7 (works locally, runner environment unresolved).

yuris closed this issue

2026-08-19 08:34:36 +00:00

yuris referenced this issue

2026-08-19 16:11:43 +00:00

cache: report a pk row change as one update event #34

yuris referenced this issue

2026-08-20 06:15:31 +00:00

dev-server: gate restart on the database serving, not the port answering #50