You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Deepkit Broker has been around for quiet some time, but played a niche role. Mainly in the Debugger GUI (profiler) to collect data from all workers and publish it to the currently connected client. It brought beside application lock also cache + pub/sub functionality.
However, we need a more robust implementation. Seeing other frameworks having proper caching and queue libraries, we need to provide that too. I plan to provide that under Deepkit Broker:
"Distributed" because it should use consistent hashing to distribute load across multiple servers. Typesafe because it always automatically serializes and deserialises with validation.
Deepkit Broker is the foundation for other features like Deepkit Dashboard (monitoring, profiling, etc), a new Job API (distributed job execution),
and an upcoming distribution configuration service that allows for example to apply server settings (like adding a new Node to the caching pool) atomically. It plays also a important role in Deepkit/RPCs peer2peer communication (as it acts as the message router)
The implementation is based on an adapter pattern where Deepkit Broker Server is the first adapter (that is faster than Redis for most use-cases and easy to deploy). Support for Redis & AWS follow after first release.
Examples
Application Lock
constlock=broker.lock('locky-xy');awaitlock.acquire();//blocks until acquiredtry{// do critical stuff}finally{awaitlock.release();}
Caching
constcache=broker.cache('cache-xy');typeCacheEntry={value: string;};constresult=awaitcache.get('my-key',async(): Promise<CacheEntry>=>{// this function is only called if the key is not in the cachereturn{value: 'my-value'};});
Deepkit Broker has been around for quiet some time, but played a niche role. Mainly in the Debugger GUI (profiler) to collect data from all workers and publish it to the currently connected client. It brought beside application lock also cache + pub/sub functionality.
However, we need a more robust implementation. Seeing other frameworks having proper caching and queue libraries, we need to provide that too. I plan to provide that under Deepkit Broker:
"Distributed" because it should use consistent hashing to distribute load across multiple servers. Typesafe because it always automatically serializes and deserialises with validation.
Deepkit Broker is the foundation for other features like Deepkit Dashboard (monitoring, profiling, etc), a new Job API (distributed job execution),
and an upcoming distribution configuration service that allows for example to apply server settings (like adding a new Node to the caching pool) atomically. It plays also a important role in Deepkit/RPCs peer2peer communication (as it acts as the message router)
The implementation is based on an adapter pattern where Deepkit Broker Server is the first adapter (that is faster than Redis for most use-cases and easy to deploy). Support for Redis & AWS follow after first release.
Examples
Application Lock
Caching
Decoupling cache building and safe cache paths:
Message Bus
Message Queue
Todo
Application Lock
Caching
Message Bus
Message Queue
message.release(seconds)
message.fail(error)
Server Persistence (snapshotting) using fork
Consistent Hashing
CLI to start server
CLI to start consumer
The text was updated successfully, but these errors were encountered: