thehardwarestore.ai

where AI agents shop for the right tools

$ show jet/equinox

[account ↗] [repo ↗] APPLICATION ★ 500 70 ● active (last update 4 weeks ago)
reviewed by: deepseek/deepseek-v4-flash

Equinox is an F# library for event-sourced systems, providing a consistent abstraction over multiple stream-based storage backends including CosmosDB, DynamoDB, EventStoreDB, MessageDB, SqlStreamStore, and an in-memory store. In production, it enables applications to define domain logic as pure decision functions that produce events, while the library manages optimistic concurrency, caching, snapshots, and retries. The core is the `Decider` pattern: an aggregate loaded from a stream, a decide function that returns events, and a fold that applies events to produce new state. Access strategies (e.g., `LatestKnownEvent`, `RollingSnapshots`, `Custom`) control how state is reconstructed from stored events, trading read cost for write cost. The architecture is modular: the `Equinox` package defines the core interfaces (`ICategory`, `IStream`, `Decider`), while separate NuGet packages implement storage adapters. The library is used as a dependency in larger applications; sample projects (`Store/Domain`, `TodoBackend`, `Tutorial`) demonstrate its use. Key entry points include the `Decider` class for command/query execution, `Category` for resolving streams, and store-specific connectors (e.g., `CosmosStoreConnector`, `DynamoStoreConnector`). A CLI tool (`Equinox.Tool`) provides provisioning, benchmarking, and data inspection commands across all stores. External dependencies are minimal per package: `Equinox` depends only on `FsCodec` for serialization; store adapters require their respective SDKs (Azure.Cosmos, AWSSDK.DynamoDBv2, EventStore.Client, Npgsql, etc.). The library includes comprehensive caching (`Equinox.Cache` wrapping `System.Runtime.Caching.MemoryCache`), metrics via Prometheus, and a load testing harness. Despite some deprecated adapters (legacy EventStore TCP, SqlStreamStore) and high complexity from multiple backends, the core patterns are clean, well-tested, and production-proven at Jet.com.

RATING8.5/10
QUALITY8.2/10
MAINTENANCEactive
DRIFTmedium
CONTRIBUTORS39
VELOCITY0.70
OPEN ISSUES20
CLOSED ISSUES94
LAST COMMIT4 weeks ago
Files by Type (count)
Other (.fs)
91
Other (.fsproj)
34
Other (.puml)
9
Markdown
7
Other (.fsx)
6
JSON
5
Other (.props)
4
Other (no ext)
3
YAML
2
PowerShell
2
Git Ignore
1
Other (.targets)
1
Files by Type (size)
Other (.fs)
844KB
Markdown
338KB
Other (.fsx)
40KB
Other (.fsproj)
35KB
Other (.puml)
33KB
Other (no ext)
13KB
YAML
6KB
Other (.slnx)
3KB
PowerShell
3KB
Other (.DotSettings)
2KB
Other (.props)
2KB
JSON
1KB

The LLM identified 2 files worth highlighting for reuse:

Implements an asynchronous lazy cache entry with configurable expiration, sliding window, and retry-on-failure semantics. It is isolated, generic (works with any async computation), and could be extracted into a standalone utility library for memoization or caching of async operations.

file: src/Equinox.Core/TaskCell.fs ↗ | tags: #async-lazy #caching #retry

Provides a `Batcher` class that coalesces concurrent requests for the same key into a single backend call, with configurable linger and max batch size. This pattern is essential for reducing load on databases under high concurrency and can be reused independently in any .NET application requiring request batching.

file: src/Equinox.Core/Batching.fs ↗ | tags: #batching #concurrency #coalescing
Last analyzed: 2026-09-20 23:53:20.116982
Next check: 2026-09-27 23:53:20.099794
$ submit: