@emmvish/stable-request 1.2.2 → 1.2.3

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.
Files changed (2) hide show
  1. package/README.md +85 -13
  2. package/package.json +1 -1
package/README.md CHANGED
@@ -1,21 +1,93 @@
1
- ## stable-request
1
+ # stable-request
2
2
 
3
- `stable-request` is a TypeScript-first HTTP reliability toolkit for workflow-driven API integrations, that goes beyond status-code retries by validating response content, handling eventual consistency, coordinating batch workflows with intelligent grouping, and providing deep observability into every request attempt.
3
+ **stable-request** is a TypeScript-first **HTTP workflow execution engine** for real-world distributed systems where HTTP `200 OK` does **not** guarantee business success.
4
4
 
5
- It is designed for real-world distributed systems where HTTP success (200) does not guarantee business success.
5
+ It enables **content-aware retries**, **hierarchical configuration**, **batch orchestration**, and **multi-phase workflows** with deep observability all built on top of standard HTTP calls.
6
6
 
7
- ## Why stable-request?
7
+ > If you’ve ever retried an API call that “succeeded” but returned the *wrong* data — this library is for you.
8
8
 
9
- Most HTTP client libraries only retry on network failures or specific HTTP status codes. **stable-request** goes further by providing:
9
+ ---
10
+
11
+ ## Why stable-request exists
12
+
13
+ Modern systems fail in subtle and dangerous ways:
14
+
15
+ - APIs return `200` but the resource isn’t ready
16
+ - Databases are eventually consistent
17
+ - Downstream services partially fail
18
+ - Some requests are critical, others are optional
19
+ - Blind retries amplify failures
20
+ - Workflows fail midway and leave systems inconsistent
21
+
22
+ Most HTTP clients answer only one question:
23
+
24
+ > “Did the request fail at the network or HTTP layer?”
25
+
26
+ **stable-request answers a different one:**
27
+
28
+ > “Is the system state actually correct yet?”
29
+
30
+ ---
31
+
32
+ ## What stable-request gives you
33
+
34
+ ### Core capabilities
35
+
36
+ ✅ **Content-aware retries**
37
+ Retry based on response validation, not just status codes
38
+
39
+ 🔄 **Deterministic execution semantics**
40
+ Fixed, linear, or exponential retry strategies with hard limits
41
+
42
+ 🧠 **Graceful failure handling**
43
+ Suppress non-critical failures without crashing workflows
44
+
45
+ 🧪 **Trial mode / chaos testing**
46
+ Simulate failures without depending on real outages
47
+
48
+ 📊 **First-class observability hooks**
49
+ Inspect every failed and successful attempt
50
+
51
+ ---
10
52
 
11
- - **Content-aware Retries** - Validate response content and retry even on successful HTTP responses
12
- - 🔄 **Multi-Phase Workflows** - Orchestrate complex workflows with sequential phases and mixed phase execution modes (concurrent & sequential)
13
- - 🚀 **Batch Processing** - Execute multiple requests with hierarchical configuration (global → group → request)
14
- - 🎯 **Request Groups** - Organize related requests with shared settings and logical boundaries
15
- - 🧪 **Trial Mode** - Simulate failures to test your retry logic without depending on real network instability
16
- - 📊 **Granular Observability** - Monitor every attempt with detailed hooks
17
- - **Multiple Retry Strategies** - Fixed, linear, or exponential backoff
18
- - 🔧 **Flexible Error Handling** - Custom error analysis and graceful degradation
53
+ ### Scaling beyond single requests
54
+
55
+ 🚀 **Batch execution (`stableApiGateway`)**
56
+ Run many requests concurrently or sequentially with shared configuration
57
+
58
+ 🎯 **Request groups**
59
+ Apply different reliability rules to critical, standard, and optional services
60
+
61
+ 🧱 **Hierarchical configuration**
62
+ Workflow → Phase → Group → Request (predictable overrides)
63
+
64
+ ---
65
+
66
+ ### Full workflow orchestration
67
+
68
+ 🧩 **Multi-phase workflows (`stableWorkflow`)**
69
+
70
+ 🔀 **Mix concurrent and sequential execution**
71
+
72
+ 🛑 **Stop early or degrade gracefully**
73
+
74
+ 📈 **Phase-level metrics and hooks**
75
+
76
+ 🧭 **Deterministic, observable execution paths**
77
+
78
+ ---
79
+
80
+ ## Choose your entry point
81
+
82
+ | Need | Use |
83
+ |-----|-----|
84
+ | Reliable single API call | `stableRequest` |
85
+ | Batch or fan-out requests | `stableApiGateway` |
86
+ | Multi-step orchestration | `stableWorkflow` |
87
+
88
+ Start small and scale **without changing mental models**.
89
+
90
+ ---
19
91
 
20
92
  ## Installation
21
93
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@emmvish/stable-request",
3
- "version": "1.2.2",
3
+ "version": "1.2.3",
4
4
  "description": "stable-request is a TypeScript-first HTTP reliability toolkit for workflow-driven API integrations, that goes beyond status-code retries by validating response content, handling eventual consistency, coordinating batch workflows with intelligent grouping, and providing deep observability into every request attempt. It is designed for real-world distributed systems where HTTP success does not guarantee business success. It also provides extensive support for managing multiple requests so as to achieve workflow automation.",
5
5
  "type": "module",
6
6
  "main": "dist/index.js",