@hotmeshio/hotmesh 0.12.0 → 0.12.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +5 -15
- package/build/package.json +1 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -11,14 +11,14 @@ npm install @hotmeshio/hotmesh
|
|
|
11
11
|
## Use HotMesh for
|
|
12
12
|
|
|
13
13
|
- **Durable pipelines** — Orchestrate long-running, multi-step pipelines transactionally.
|
|
14
|
-
- **
|
|
14
|
+
- **Crash-safe execution** — Every step is a committed row. If the process dies, it picks up where it left off.
|
|
15
15
|
- **Distributed state machines** — Build stateful applications where every component can [fail and recover](https://github.com/hotmeshio/sdk-typescript/blob/main/services/collator/README.md).
|
|
16
16
|
- **AI and training pipelines** — Multi-step AI workloads where each stage is expensive and must not be repeated on failure. A crashed pipeline resumes from the last committed step, not from the beginning.
|
|
17
17
|
|
|
18
18
|
## How it works in 30 seconds
|
|
19
19
|
|
|
20
20
|
1. **You write workflow functions.** Plain TypeScript — branching, loops, error handling. HotMesh also supports a YAML syntax for declarative, functional workflows.
|
|
21
|
-
2. **HotMesh compiles them into a transactional execution plan.** Each step becomes a committed database row. If the process crashes mid-workflow, it resumes from the last committed step.
|
|
21
|
+
2. **HotMesh compiles them into a transactional execution plan.** Each step becomes a committed database row backed by Postgres ACID guarantees and monotonic integers for ordering. If the process crashes mid-workflow, it resumes from the last committed step.
|
|
22
22
|
3. **Your Postgres database is the engine.** It stores state, coordinates retries, and delivers messages. Every connected client participates in execution — there is no central server.
|
|
23
23
|
|
|
24
24
|
## Quickstart
|
|
@@ -56,7 +56,7 @@ export async function notifyBackorder(itemId: string): Promise<void> {
|
|
|
56
56
|
}
|
|
57
57
|
```
|
|
58
58
|
|
|
59
|
-
### Option 1: Code
|
|
59
|
+
### Option 1: Code
|
|
60
60
|
|
|
61
61
|
```typescript
|
|
62
62
|
// workflows.ts
|
|
@@ -305,8 +305,6 @@ ORDER BY
|
|
|
305
305
|
|
|
306
306
|
What happened? Consult the database. What's still running? Query the semaphore. What failed? Read the row. The execution state isn't reconstructed from a log — it was committed transactionally as each step ran.
|
|
307
307
|
|
|
308
|
-
You can also use the Temporal-compatible API:
|
|
309
|
-
|
|
310
308
|
```typescript
|
|
311
309
|
const handle = client.workflow.getHandle('orders', 'orderWorkflow', 'order-456');
|
|
312
310
|
|
|
@@ -331,14 +329,6 @@ There is no proprietary dashboard. Workflow state lives in Postgres, so use what
|
|
|
331
329
|
|
|
332
330
|
For a deep dive into the transactional execution model — how every step is crash-safe, how the monotonic collation ledger guarantees exactly-once delivery, and how cycles and retries remain correct under arbitrary failure — see the [Collation Design Document](https://github.com/hotmeshio/sdk-typescript/blob/main/services/collator/README.md). The symbolic system (how to design workflows) and lifecycle details (how to deploy workflows) are covered in the [Architectural Overview](https://zenodo.org/records/12168558).
|
|
333
331
|
|
|
334
|
-
## Familiar with Temporal?
|
|
335
|
-
|
|
336
|
-
Durable is designed as a drop-in-compatible alternative for common Temporal patterns.
|
|
337
|
-
|
|
338
|
-
**What's the same:** `Client`, `Worker`, `proxyActivities`, `sleepFor`, `startChild`/`execChild`, signals (`waitFor`/`signal`), retry policies, and the overall workflow-as-code programming model.
|
|
339
|
-
|
|
340
|
-
**What's different:** Postgres is the only infrastructure dependency — it stores state and coordinates workers.
|
|
341
|
-
|
|
342
332
|
## Running tests
|
|
343
333
|
|
|
344
334
|
Tests run inside Docker. Start the services and run the full suite:
|
|
@@ -351,8 +341,8 @@ docker compose exec hotmesh npm test
|
|
|
351
341
|
Run a specific test group:
|
|
352
342
|
|
|
353
343
|
```bash
|
|
354
|
-
docker compose exec hotmesh npm run test:durable # all Durable tests
|
|
355
|
-
docker compose exec hotmesh npm run test:durable:hello # single Durable test (hello world
|
|
344
|
+
docker compose exec hotmesh npm run test:durable # all Durable tests
|
|
345
|
+
docker compose exec hotmesh npm run test:durable:hello # single Durable test (hello world)
|
|
356
346
|
docker compose exec hotmesh npm run test:virtual # all Virtual network function (VNF) tests
|
|
357
347
|
```
|
|
358
348
|
|
package/build/package.json
CHANGED