This PR adds support for using Redis as the storage service of Apollon Standalone (instead of file-based storage). After merging this PR, Apollon Standalone will look for APOLLON_REDIS_URL environment variable, and if present, switch to Redis as its storage backend. See these docs for further info on the format of the Redis URL. If the environment variable is not present, Apollon Standalone will fallback into using the filesystem based storage it was already using.
The main benefit of using Redis as the storage backend is stability of high-frequency writes. Specifically in context of realtime collaboration, it can happen that diagrams are constantly updated, which, using a file based storage, means potentially colliding write operations resulting in corrupted files. The DiagramFileStorageService was already equipped with rate-limiting logic to mitigate this issue, but this means occasionally clients would get the wrong diagram if they requested it at the wrong time (for example, while a change is being debounced).
This PR refactors the rate limiting logic into a separate DiagramStorageRateLimiter class, which is in turn used by both the old DiagramFileStorageService and the new DiagramRedisStorageService. However, the Redis storage service can use a much more relaxed rate limiting configuration as Redis is much faster than a file-based storage scheme. Additionally, Redis, through its JSON module, allows for atomic patching of diagrams, which was again not possible in a file-based storage, further increasing the stability and performance of the storage.
This PR adds support for using Redis as the storage service of Apollon Standalone (instead of file-based storage). After merging this PR, Apollon Standalone will look for
APOLLON_REDIS_URL
environment variable, and if present, switch to Redis as its storage backend. See these docs for further info on the format of the Redis URL. If the environment variable is not present, Apollon Standalone will fallback into using the filesystem based storage it was already using.The main benefit of using Redis as the storage backend is stability of high-frequency writes. Specifically in context of realtime collaboration, it can happen that diagrams are constantly updated, which, using a file based storage, means potentially colliding write operations resulting in corrupted files. The
DiagramFileStorageService
was already equipped with rate-limiting logic to mitigate this issue, but this means occasionally clients would get the wrong diagram if they requested it at the wrong time (for example, while a change is being debounced).This PR refactors the rate limiting logic into a separate
DiagramStorageRateLimiter
class, which is in turn used by both the oldDiagramFileStorageService
and the newDiagramRedisStorageService
. However, the Redis storage service can use a much more relaxed rate limiting configuration as Redis is much faster than a file-based storage scheme. Additionally, Redis, through its JSON module, allows for atomic patching of diagrams, which was again not possible in a file-based storage, further increasing the stability and performance of the storage.