Closed ben-ryder closed 11 months ago
I'm not going to implement this, as managing things like access control, allowed origins etc would just get much more complex and I don't think apps should share storage when another server could just be spun up instead.
Describe the feature Currently the server only supports one set of changes per user (or multiple vaults after #11), but you would need to spin up a new server for every application. The server could be setup to support multiple applications as well as multiple vaults.
This could be added like so:
apps
CRUD object which includes the fields:id, name, identifier, description
/apps
[POST, GET]/apps/:appId
[GET, PATCH, DELETE]/apps/:appId/vaults
[POST, GET]/apps/:appId/vaults/:vaultId
[GET, PATCH, DELETE]/apps/:appId/vaults/:vaultId/changes
[GET, POST, DELETE]/apps/:appId/vaults/:vaultId/changes/ids
[GET]Apps would be standard API resources and would not be 'local-first' in the same way that data contained within changes are. Vaults would then also have an
appId
field and on the deletion on an app, this should cascade to deleting all vaults.There are a number of potential issues with doing this, especially around user managemnet and access control. Should each app be a difference audience, does that mean the server will have to validate tokens on an application level?
Should users be able to see all apps or only ones they have access to? How would this be implemented given the server doesn't directly manage user auth...
Additional context n/a