​
Current State

CrateStack already provides a usable Rust-first backend slice, but it is not yet the full target architecture described in the ADR and PRD.

​
Implemented Today

  1. a Rust 2024 multi-crate workspace under cratestack/
  2. schema parsing and semantic validation for an initial .cstack subset
  3. compile-time role-specific macros: include_server_schema!("…", db = Postgres), include_embedded_schema!, include_client_schema! — each emits a cratestack_schema module shaped for one deployment shape, with strict disjoint backend output (server never emits rusqlite, embedded never emits sqlx)
  4. SQLx-backed model delegates for create, upsert (insert-or-update on PK conflict), find_many, find_unique, update, delete, plus the five batch primitives (batch_get, batch_create, batch_update, batch_delete, batch_upsert) returning a per-item BatchResponse<M> envelope with savepoint isolation
  5. generated Axum model CRUD and procedure routes — for transport rest schemas (the default); transport rpc schemas instead get POST /rpc/{op_id} (unary, every CRUD verb + every procedure) plus POST /rpc/batch (sequence of frames in, sequence out in same order, per-frame error isolation, no in-batch dependencies). Streaming for Sequence-kind ops (list-return procedures) works on the same unary route via Accept: application/cbor-seq. Errors on the RPC binding are uniform RpcErrorBody { code, message, details? } with gRPC-style codes — see ADR 0005
  6. host-owned authentication through AuthProvider and internal binding through bind_auth(...) and bind_context(...)
  7. generated Rust client support via include_client_schema!, plus generated Dart package output
  8. policy enforcement for the current supported model and procedure policy subset (server only)
  9. generated telemetry for procedure wrappers, procedure routes, and model list routes
  10. top-level mixin declarations plus model @use(...) expansion for reusable field sets
  11. duplicate-execution protection via IdempotencyLayer with reservation tokens and header replay, backed by either SqlxIdempotencyStore (Postgres) or RedisIdempotencyStore (Redis, via cratestack-redis)
  12. optimistic concurrency via @version with If-Match / ETag round-tripping
  13. transactional audit log via @@audit + cratestack_audit + pluggable AuditSink (server)
  14. explicit transaction isolation via run_in_isolated_tx + procedure @isolation, with commit-time retry
  15. per-principal rate limiting via RateLimitLayer + pluggable RateLimitStore
  16. soft delete via @@soft_delete (server and embedded)
  17. forward-only migrations via Migration + apply_pending with checksum drift detection
  18. runtime validators (@length, @range on Int + Decimal, @email, @regex, @uri, @iso4217) with PII-safe error messages
  19. Decimal scalar with selectable backend (rust_decimal or bigdecimal)
  20. FIPS-validated TLS provider toggle via the crypto-aws-lc-rs workspace feature
  21. embedded SQLite backend via cratestack-rusqlite: sync API, bundled SQLite, the same include_embedded_schema!-driven ModelDelegate shape as the server, with Decimal, Uuid, DateTime, and Json round-tripping exactly through canonical TEXT storage. Compiles to native (mobile via FFI, desktop) AND wasm32-unknown-unknown (browser, OPFS-backed via sqlite-wasm-rs + sqlite-wasm-vfs). One source, three targets.
  22. dialect-agnostic SQL primitives crate cratestack-sql shared by both backends — value types, filter AST, order AST, model descriptor, and a narrow Dialect trait that only varies on placeholder syntax
  23. projection-decode tolerance (0.4.x) — generated client decoders for ?fields=… reads tolerate the server omitting fields the projection didn’t ask for, while still hard-failing on a missing required scalar. Optional scalars (T?) fall back to None; list-arity fields fall back to an empty Vec; required scalars reject. Same MissingFieldFallback ladder powers model ?fields=… reads and view projections
  24. codec-json opt-out on cratestack-pg, cratestack-sqlite, cratestack-client-rust, and cratestack-client-flutter (0.4.x) — default-on so existing setups are unchanged. Backend services that have standardized on CBOR can build with default-features = false on the facade to drop the JsonCodec wrapper type, the JSON fallback in CborCodec’s content-negotiation path, and the RuntimeTransportClient::Json FFI variant. serde_json stays linked (the view methods decode into serde_json::Value and the FFI bridge still encodes/decodes its bridge payloads as JSON); the opt-out narrows codec-negotiation behavior, not the serde_json-shaped surface area. CBOR stays unconditional (the schema macros emit pub struct Client<C = CborCodec>); the projection-view client methods (get_view / list_view / list_view_paged) route through the client’s codec, so they keep working over CBOR

​
Still Narrow Or Deferred

  1. COSE transport remains an unimplemented envelope seam
  2. negotiated multi-codec routing is not complete end-to-end
  3. the parser still validates only an initial schema subset
  4. production-stable exact non-Rust selection typing is not complete
  5. richer exposure controls and some field-level policy features are still deferred
  6. the client runtime remains partially spiked rather than fully mature
  7. the shipped rate-limit store is in-memory (single-replica); the trait is pluggable
  8. the migration runner is forward-only — schema-diff generation and zero-downtime coordination remain out of scope
  9. the embedded SQLite backend does not enforce @@allow / @@deny policies at SQL render time (by design — the client is untrusted; authorization is the server’s concern)
  10. @@audit and @@emit directives are currently no-ops in include_embedded_schema!; the local-journal / local-event-bus implementations (needed for sync-engine wiring) land in a follow-up release
  11. the umbrella cratestack crate compiles both backends unconditionally; binary-size feature gating to opt out of the sqlx/tokio stack on embedded-only builds is planned but not yet shipped (embedded-only consumers can already depend directly on cratestack-macros + cratestack-rusqlite to shed the server-side weight)
  12. multi-DB server support — include_server_schema! accepts a db = Postgres argument but only Postgres is wired today; MySQL and SQLite-via-sqlx are non-breaking future additions

​
Best Fit Right Now

CrateStack is currently strongest for:
  1. internal CRUD-heavy Rust services
  2. teams that want one schema to drive delegates, routes, and client contracts
  3. services that benefit from generated policy checks and typed query builders
  4. CBOR-first or CBOR-aware HTTP APIs that still need JSON fallback
  5. banking-adjacent workloads that need transactional audit, optimistic locking, idempotency, and explicit isolation out of the box
  6. offline-first apps that want one Rust schema definition to drive the server AND an embedded SQLite store — whether on a phone (Flutter or another UI toolkit over FFI), on a desktop, or in a browser tab via OPFS-backed wasm32-unknown-unknown running inside a Dedicated Worker
  1. ../getting-started/quickstart for a minimal setup path
  2. ./banking-readiness for the regulated-workload primitives shipped on feat/banking-readiness
  3. ../guides/auth-provider for the host auth boundary
  4. ../guides/offline-first-sqlite for the embedded SQLite backend (native + browser via OPFS)
  5. ../architecture/transport-architecture for transport design
  6. ../reference/auth-support-matrix for the current auth and policy surface