anbaric 1.0.0 → 1.0.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 +98 -0
- package/package.json +1 -1
package/README.md
ADDED
|
@@ -0,0 +1,98 @@
|
|
|
1
|
+
# anbaric
|
|
2
|
+
|
|
3
|
+
Everything needed to write an Anbaric app, in one install. Re-exports the
|
|
4
|
+
full app-facing surface of [`anbaric-tsapi`](https://npmjs.com/package/anbaric-tsapi)
|
|
5
|
+
(contracts and value classes), [`anbaric-state-machine`](https://npmjs.com/package/anbaric-state-machine)
|
|
6
|
+
(the state machine and in-memory implementations),
|
|
7
|
+
[`anbaric-data-store`](https://npmjs.com/package/anbaric-data-store)
|
|
8
|
+
(document and secret stores) and [`anbaric-cloud`](https://npmjs.com/package/anbaric-cloud)
|
|
9
|
+
(the clients the factories switch to when deployed).
|
|
10
|
+
|
|
11
|
+
```bash
|
|
12
|
+
npm install anbaric
|
|
13
|
+
```
|
|
14
|
+
|
|
15
|
+
An Anbaric app is a plain Node/TypeScript ESM program. Requirements:
|
|
16
|
+
`"type": "module"` in package.json, `main` pointing at the TypeScript entry
|
|
17
|
+
file, run with `tsx`. Apps deployed to an Anbaric platform may currently only
|
|
18
|
+
depend on `anbaric-*` packages.
|
|
19
|
+
|
|
20
|
+
## The model
|
|
21
|
+
|
|
22
|
+
A **StateMachine** owns a workflow: named **States**, each with **Actions**
|
|
23
|
+
(work that runs when a job is processed in that state) and **Transitions**
|
|
24
|
+
(predicates deciding the next state). A **Job** moves through the machine
|
|
25
|
+
carrying a `Map` of properties validated against **PropertyDefinitions**.
|
|
26
|
+
Every Action declares an **Actor** (`Code`, `Human` or `Agent` — pure
|
|
27
|
+
identity objects with `type`, `id`, `role`); `Code` actions run
|
|
28
|
+
automatically, the other types are placeholders for human/agent work.
|
|
29
|
+
|
|
30
|
+
```ts
|
|
31
|
+
import {Action, Code, PropertyDefinition, State, StateMachine, Transition} from "anbaric";
|
|
32
|
+
|
|
33
|
+
const flag = new PropertyDefinition("welcomeSent");
|
|
34
|
+
flag.validation = (value) => typeof value === "boolean";
|
|
35
|
+
const email = new PropertyDefinition("email");
|
|
36
|
+
email.required = true;
|
|
37
|
+
|
|
38
|
+
const sendWelcome = new Action("Send welcome email", new Code("send-welcome"));
|
|
39
|
+
sendWelcome.run = async (job) => new Map([["welcomeSent", true]]);
|
|
40
|
+
|
|
41
|
+
const customers = new StateMachine(
|
|
42
|
+
"customer-onboarding",
|
|
43
|
+
[
|
|
44
|
+
new State("new", [sendWelcome],
|
|
45
|
+
[new Transition("active", job => job.properties.get("welcomeSent") === true)]),
|
|
46
|
+
new State("active"),
|
|
47
|
+
],
|
|
48
|
+
"new",
|
|
49
|
+
[email, flag],
|
|
50
|
+
);
|
|
51
|
+
|
|
52
|
+
const job = await customers.startJob(new Map([["email", "ada@example.com"]]));
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
Key rules an agent must respect:
|
|
56
|
+
|
|
57
|
+
- **Actions return properties, they do not mutate the job**: `run` returns a
|
|
58
|
+
`Promise<Map<string, any>>` of property changes. Every returned property
|
|
59
|
+
must exist in the machine's schema or the change is discarded.
|
|
60
|
+
- **Every property a job ever carries needs a `PropertyDefinition`** —
|
|
61
|
+
including ones actions set. Unknown properties make updates invalid.
|
|
62
|
+
- **Three ways to influence a job**: `updateJob(jobId, properties, actor)`
|
|
63
|
+
(explicit change, actor declared), `executeAction(jobId, action)` (run one
|
|
64
|
+
action now, actor embedded), or subscribing actions to states (automatic on
|
|
65
|
+
processing). All are schema-validated and audited.
|
|
66
|
+
- **Jobs carry history**: `startedAt`, `startedBy`, `lastUpdated`, and
|
|
67
|
+
`transitions` (`{from, to, actor}` for every state change).
|
|
68
|
+
|
|
69
|
+
## Local versus deployed
|
|
70
|
+
|
|
71
|
+
Persistence, queueing and consumers come from env-driven factories. With no
|
|
72
|
+
environment set, everything is in-memory and jobs progress automatically —
|
|
73
|
+
`npx tsx src/main.ts` is a complete local run. On an Anbaric platform the
|
|
74
|
+
same factories talk to the platform because it injects
|
|
75
|
+
`ANBARIC_JOB_PERSISTENCE_TYPE=cloud`, `ANBARIC_QUEUE_TYPE=cloud`,
|
|
76
|
+
`ANBARIC_JSON_STORE_TYPE=cloud`, `ANBARIC_SECRET_STORE_TYPE=cloud` and
|
|
77
|
+
`ANBARIC_CLOUD_URL`. Never set these by hand in app code.
|
|
78
|
+
|
|
79
|
+
Documents and secrets follow the same pattern:
|
|
80
|
+
|
|
81
|
+
```ts
|
|
82
|
+
import {JsonStoreFactory, SecretStoreFactory} from "anbaric";
|
|
83
|
+
|
|
84
|
+
const customers = JsonStoreFactory.instance("customers", {
|
|
85
|
+
type: "object",
|
|
86
|
+
required: ["name"],
|
|
87
|
+
properties: { name: { type: "string" } },
|
|
88
|
+
});
|
|
89
|
+
await customers.save("ada", { name: "Ada" });
|
|
90
|
+
|
|
91
|
+
const secrets = SecretStoreFactory.instance();
|
|
92
|
+
await secrets.save("api-key", "s3cr3t");
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
Per-package detail: [anbaric-tsapi](https://npmjs.com/package/anbaric-tsapi)
|
|
96
|
+
for every contract's exact shape, [anbaric-state-machine](https://npmjs.com/package/anbaric-state-machine)
|
|
97
|
+
for progression semantics, [anbaric-cli](https://npmjs.com/package/anbaric-cli)
|
|
98
|
+
for deployment.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "anbaric",
|
|
3
|
-
"version": "1.0.
|
|
3
|
+
"version": "1.0.1",
|
|
4
4
|
"description": "Everything needed to write an Anbaric app: state machines, jobs, document and secret stores, local in-memory implementations and the Anbaric Cloud clients",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"type": "module",
|