This issue tracks reimplementing the work from stale PR #2416, which has been closed because it is too far out of date to merge directly.
## Original pull request
- PR #2416: [Allow building custom standalone servers](https://github.com/clockworklabs/SpacetimeDB/pull/2416)
- Original author: @m1guelpf
## What the original PR was trying to do
# Description of Changes
Expands the spacetimedb-standalone crate to also serve as a library to build your own standalone servers with custom auth services and more. This is accomplished by:
- Publishing some structs/properties to allow reusing the existing
StandaloneEnv instead of having to recreate it from scratch.
- Make
StandaloneEnv abstract over any JwtAuthProvider and not just the default (but still default to DefaultJwtAuthProvider, so no API changes for existing clients)
API and ABI breaking changes
I don't believe this includes any breaking changes, other than some of the crate's API now being public. Since the crate is currently marked as unstable, this should be fine.
Expected complexity level and risk
Changes are very simple.
Testing
I'm using this branch locally to develop a custom SpacetimeDB server with stricter authentication requirements.
## Closure context
- Closed from the `close-stale-pr-create-issue` stale-PR sweep.
## Reimplementation notes
- Reimplement this work on top of current `master` in a new PR.
- Keep the original PR linked as historical context and as a source of useful implementation ideas where still relevant.
This issue tracks reimplementing the work from stale PR #2416, which has been closed because it is too far out of date to merge directly.
Expands the
spacetimedb-standalonecrate to also serve as a library to build your own standalone servers with custom auth services and more. This is accomplished by:StandaloneEnvinstead of having to recreate it from scratch.StandaloneEnvabstract over anyJwtAuthProviderand not just the default (but still default toDefaultJwtAuthProvider, so no API changes for existing clients)API and ABI breaking changes
I don't believe this includes any breaking changes, other than some of the crate's API now being public. Since the crate is currently marked as unstable, this should be fine.
Expected complexity level and risk
Changes are very simple.
Testing
I'm using this branch locally to develop a custom SpacetimeDB server with stricter authentication requirements.