From faf93d776438117f2fc73ed928156ecebbd2cdbf Mon Sep 17 00:00:00 2001 From: Zeke Foppa Date: Fri, 8 Aug 2025 09:38:06 -0700 Subject: [PATCH 1/5] [bfops/workflow-preview-in-index]: Add workflow preview diagram --- docs/docs/index.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/docs/docs/index.md b/docs/docs/index.md index 2d8840b402f..0598a3ed9cd 100644 --- a/docs/docs/index.md +++ b/docs/docs/index.md @@ -36,6 +36,23 @@ SpacetimeDB is optimized for maximum speed and minimum latency, rather than batc Speed and latency is achieved by holding all of your application state in memory, while persisting data to a commit log which is used to recover data after restarts and system crashes. +## Application Workflow Preview + +
+ SpacetimeDB Application Workflow Preview +
+ SpacetimeDB Application Workflow Preview +
+
+ + +The above illustrates the Workflow that happens when using SpacetimeDB. + +* All clientside reads happen with the data view that is cached locally. +* Clientside subscriptions tell the server what data client cares about and wants to be synced within its data view. Changes to data will be pushed by the server to the clientside cache. +* RLS filters restrict the data view serverside before subscriptions are evaluated. These filters can be used for access control or client scoping. +* Reducers are effectively async RPC's. The request is sent off and if the results of that reducer makes changes to data, it will be written to the database directly. As a result of that, if those changes make it through the two layers above, then the client will see the result when it queries its local cache. + ## State Mirroring SpacetimeDB can generate client code in a [variety of languages](#client-side-sdks). This creates a client library custom-designed to talk to your database. It provides easy-to-use interfaces for connecting to the database and submitting requests. It can also **automatically mirror state** from your database to client applications. From e54ab7b0227dc2273aa59021c803f9a5636a1caa Mon Sep 17 00:00:00 2001 From: Zeke Foppa <196249+bfops@users.noreply.github.com> Date: Fri, 15 Aug 2025 10:32:35 -0700 Subject: [PATCH 2/5] Update docs/docs/index.md Co-authored-by: Tyler Cloutier Signed-off-by: Zeke Foppa <196249+bfops@users.noreply.github.com> --- docs/docs/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/index.md b/docs/docs/index.md index 0598a3ed9cd..78e8f03a55a 100644 --- a/docs/docs/index.md +++ b/docs/docs/index.md @@ -50,7 +50,7 @@ The above illustrates the Workflow that happens when using SpacetimeDB. * All clientside reads happen with the data view that is cached locally. * Clientside subscriptions tell the server what data client cares about and wants to be synced within its data view. Changes to data will be pushed by the server to the clientside cache. -* RLS filters restrict the data view serverside before subscriptions are evaluated. These filters can be used for access control or client scoping. +* RLS filters restrict the data view server-side before subscriptions are evaluated. These filters can be used for access control or client scoping. * Reducers are effectively async RPC's. The request is sent off and if the results of that reducer makes changes to data, it will be written to the database directly. As a result of that, if those changes make it through the two layers above, then the client will see the result when it queries its local cache. ## State Mirroring From 3d23a5eda9c226eb93f7d94b7271bc416f590c26 Mon Sep 17 00:00:00 2001 From: Zeke Foppa <196249+bfops@users.noreply.github.com> Date: Fri, 15 Aug 2025 10:32:43 -0700 Subject: [PATCH 3/5] Update docs/docs/index.md Co-authored-by: Tyler Cloutier Signed-off-by: Zeke Foppa <196249+bfops@users.noreply.github.com> --- docs/docs/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/index.md b/docs/docs/index.md index 78e8f03a55a..b797b45d993 100644 --- a/docs/docs/index.md +++ b/docs/docs/index.md @@ -49,7 +49,7 @@ Speed and latency is achieved by holding all of your application state in memory The above illustrates the Workflow that happens when using SpacetimeDB. * All clientside reads happen with the data view that is cached locally. -* Clientside subscriptions tell the server what data client cares about and wants to be synced within its data view. Changes to data will be pushed by the server to the clientside cache. +* Client-side subscriptions tell the server what data client cares about and wants to be synced within its data view. Changes to data will be pushed by the server to the client cache. * RLS filters restrict the data view server-side before subscriptions are evaluated. These filters can be used for access control or client scoping. * Reducers are effectively async RPC's. The request is sent off and if the results of that reducer makes changes to data, it will be written to the database directly. As a result of that, if those changes make it through the two layers above, then the client will see the result when it queries its local cache. From 312cf1ca38b86d2d4ed8109279186582d149d454 Mon Sep 17 00:00:00 2001 From: Zeke Foppa <196249+bfops@users.noreply.github.com> Date: Fri, 15 Aug 2025 10:32:49 -0700 Subject: [PATCH 4/5] Update docs/docs/index.md Co-authored-by: Tyler Cloutier Signed-off-by: Zeke Foppa <196249+bfops@users.noreply.github.com> --- docs/docs/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/index.md b/docs/docs/index.md index b797b45d993..1af72429f3e 100644 --- a/docs/docs/index.md +++ b/docs/docs/index.md @@ -48,7 +48,7 @@ Speed and latency is achieved by holding all of your application state in memory The above illustrates the Workflow that happens when using SpacetimeDB. -* All clientside reads happen with the data view that is cached locally. +* All client-side reads happen with the data view that is cached locally. * Client-side subscriptions tell the server what data client cares about and wants to be synced within its data view. Changes to data will be pushed by the server to the client cache. * RLS filters restrict the data view server-side before subscriptions are evaluated. These filters can be used for access control or client scoping. * Reducers are effectively async RPC's. The request is sent off and if the results of that reducer makes changes to data, it will be written to the database directly. As a result of that, if those changes make it through the two layers above, then the client will see the result when it queries its local cache. From 5f0d76a5b67271938ae8f383f34c815122c9fa23 Mon Sep 17 00:00:00 2001 From: Zeke Foppa <196249+bfops@users.noreply.github.com> Date: Mon, 18 Aug 2025 14:00:43 -0700 Subject: [PATCH 5/5] Update docs/docs/index.md Co-authored-by: Tyler Cloutier Signed-off-by: Zeke Foppa <196249+bfops@users.noreply.github.com> --- docs/docs/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/index.md b/docs/docs/index.md index 1af72429f3e..2661ee1ef34 100644 --- a/docs/docs/index.md +++ b/docs/docs/index.md @@ -46,7 +46,7 @@ Speed and latency is achieved by holding all of your application state in memory -The above illustrates the Workflow that happens when using SpacetimeDB. +The above illustrates the workflow when using SpacetimeDB. * All client-side reads happen with the data view that is cached locally. * Client-side subscriptions tell the server what data client cares about and wants to be synced within its data view. Changes to data will be pushed by the server to the client cache.