Files
plainleaf/website/Architecture.md
T
Zef HemelandGitHub dc2987a3f9 Sync engine rearchitecture (#1516)
* Don't require auth for .ping
* Finally introducing loggers
* Remove file list caching from disk_space_primitives
I don't think this is required anymore with the sync model
* Simplification of space primitives and more tests
* More reliable online status
* Add .zed settings
* Remove selfUpdate argument from `writeFile` no longer used
- Add `sync` config schema and document sync options
- Move sync config handling to client boot logic
- Move BootConfig type to ui_types.ts
- Remove sync env vars from server
- Update documentation for sync and architecture
* Improve sync logic and proxy routing for full sync state
* Add BoxProxy for late-bound client and improve Lua boot
- Add isMobile syscall for editor
* Add concurrency to sync process and log indexing duration
* Better service worker lifecycle management
2025-09-12 14:43:57 +02:00

1.9 KiB
Raw Blame History

Note

Note This page contains sections that apply to the current edge release, it is not part of an official release yet.

Some notes on how things fit together.

Client

The client is what you see when you open SilverBullet in a browser tab or window. It renders the UI, interacts with the user, runs Plugs, Space Lua, and maintains the index. 90%+ of logic lives here.

The client relies on IndexedDB as a data store. It uses this data store primarily to keep the Objects. In your browser’s database list, this database’s name will end with _data. This data store is shared between tabs and windows (of the same browser).

The client interacts with the service worker and server primarily via the HTTP API, which exposes CRUD-style operations on files.

Service Worker

The service worker’s role is to make SilverBullet offline capable. When enabled (it is enabled by default) it:

  • Caches and serves the SilverBullet client code
  • Sync files with a local database
  • Implements the HTTP API, but handles it locally (where appropriate)

It does this by intercepting HTTP calls coming from the client aimed at the server.

The service worker embeds a Sync engine, that based on configuration constantly keeps a local copy of your files in sync with the server. To make the sync status visible, it emits events to the Client.

For debugging purposes you can disable the service worker by adding ?enableSW=0 to your URL. This disabling is persistent, to re-enable it use ?enableSW=1.

Server

The server has only three jobs:

  • Handle authentication
  • Serve the (static) client code
  • Implement the HTTP API, which mainly means listing, reading, writing and deleting files, and executing shell commands.

Note that all indexing, querying etc. happens in the client. The server effectively acts as a file store.