Here’s a diagram of roughly how things fit together:
url:Architecture/Architecture.excalidraw
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|object index. 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.
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|Syncs 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.
The server has only three jobs:
Note that all indexing, querying etc. happens in the client. The server effectively acts as a file store.