inngest-cli 1.0.2 → 1.0.4
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 +86 -123
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -1,166 +1,122 @@
|
|
|
1
|
-
# [](https://www.inngest.com)
|
|
2
2
|
|
|
3
3
|
[](https://github.com/inngest/inngest/releases)
|
|
4
4
|
[](https://github.com/inngest/inngest/actions?query=branch%3Amain)
|
|
5
5
|
[](https://www.inngest.com/discord)
|
|
6
6
|
[](https://twitter.com/inngest)
|
|
7
7
|
|
|
8
|
-
[Inngest](https://www.inngest.com)
|
|
8
|
+
[Inngest](https://www.inngest.com/?ref=github-inngest-readme)'s durable functions replace queues, state management, and scheduling to enable any developer to write reliable step functions faster without touching infrastructure.
|
|
9
9
|
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
10
|
+
1. Write durable functions using any of [**our language SDKs**](#sdks)
|
|
11
|
+
2. Run the [**Inngest Dev Server**](#getting-started) for a complete local development experience, with production parity.
|
|
12
|
+
3. Deploy your functions to your own infrastructure
|
|
13
|
+
4. Sync your application's functions with the [**Inngest Platform**](https://www.inngest.com/?ref=github-inngest-readme) or a [self-hosted Inngest server](#self-hosting).
|
|
14
|
+
5. Inngest invokes your functions securely via HTTPS whenever triggering events are received.
|
|
14
15
|
|
|
15
|
-
|
|
16
|
-
AI & LLM Chaining
|
|
17
|
-
</a> |
|
|
16
|
+
### An example durable function
|
|
18
17
|
|
|
19
|
-
|
|
20
|
-
Serverless Queues
|
|
21
|
-
</a> |
|
|
18
|
+
Inngest Functions enable developers to run reliable background logic, from background jobs to complex workflows. An Inngest Function is composed of three key parts that provide robust support for retrying, scheduling, and coordinating complex sequences of operations:
|
|
22
19
|
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
</div>
|
|
27
|
-
<br/>
|
|
20
|
+
- [**Triggers**](https://www.inngest.com/docs/features/events-triggers?ref=github-inngest-readme) - Events, Cron schedules or webhook events that trigger the function.
|
|
21
|
+
- [**Flow Control**](https://www.inngest.com/docs/guides/flow-control?ref=github-inngest-readme) - Configure how the function runs are enqueued and executed including concurrency, throttling, debouncing, rate limiting, and prioritization.
|
|
22
|
+
- [**Steps**](/docs/features/inngest-functions/steps-workflows?ref=github-inngest-readme) - Steps are fundamental building blocks of Inngest, turning your Inngest Functions into reliable workflows that can runs for months and recover from failures.
|
|
28
23
|
|
|
29
|
-
|
|
24
|
+
Here is an example function that limits concurrency for each unique user id and performs two steps that will be retried on error:
|
|
30
25
|
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
26
|
+
```typescript
|
|
27
|
+
export default inngest.createFunction(
|
|
28
|
+
{
|
|
29
|
+
id: "import-product-images",
|
|
30
|
+
concurrency: {
|
|
31
|
+
key: "event.data.userId",
|
|
32
|
+
limit: 10
|
|
33
|
+
}
|
|
34
|
+
},
|
|
35
|
+
{ event: "shop/product.imported" },
|
|
36
|
+
async ({ event, step }) => {
|
|
37
|
+
// Here goes the business logic
|
|
38
|
+
// By wrapping code in steps, each will be retried automatically on failure
|
|
39
|
+
const s3Urls = await step.run("copy-images-to-s3", async () => {
|
|
40
|
+
return copyAllImagesToS3(event.data.imageURLs);
|
|
41
|
+
});
|
|
42
|
+
// You can include numerous steps in your function
|
|
43
|
+
await step.run("resize-images", async () => {
|
|
44
|
+
await resizer.bulk({ urls: s3Urls, quality: 0.9, maxWidth: 1024 });
|
|
45
|
+
})
|
|
46
|
+
};
|
|
47
|
+
);
|
|
34
48
|
|
|
35
|
-
|
|
49
|
+
// Elsewhere in your code (e.g. in your API endpoint):
|
|
50
|
+
await inngest.send({
|
|
51
|
+
name: "shop/product.imported",
|
|
52
|
+
data: {
|
|
53
|
+
userId: "01J8G44701QYGE0DH65PZM8DPM",
|
|
54
|
+
imageURLs: [
|
|
55
|
+
"https://useruploads.acme.com/q2345678/1094.jpg",
|
|
56
|
+
"https://useruploads.acme.com/q2345678/1095.jpg"
|
|
57
|
+
],
|
|
58
|
+
},
|
|
59
|
+
});
|
|
60
|
+
```
|
|
36
61
|
|
|
37
|
-
|
|
62
|
+
## Learn more
|
|
38
63
|
|
|
39
|
-
- [Overview](#overview)
|
|
40
|
-
- [SDKs](#sdks)
|
|
41
64
|
- [Getting started](#getting-started)
|
|
65
|
+
- [SDKs](#sdks)
|
|
42
66
|
- [Project Architecture](#project-architecture)
|
|
67
|
+
- [Self-hosting](#self-hosting)
|
|
43
68
|
- [Community](#community)
|
|
44
69
|
|
|
45
|
-
|
|
70
|
+
## Getting started
|
|
46
71
|
|
|
47
|
-
|
|
72
|
+
Run the Inngest Dev Server using our CLI:
|
|
48
73
|
|
|
49
74
|
```
|
|
50
75
|
npx inngest-cli@latest dev
|
|
51
76
|
```
|
|
52
77
|
|
|
53
|
-
|
|
78
|
+
Open the Inngest Dev Server dashboard at http://localhost:8288:
|
|
54
79
|
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
## Overview
|
|
58
|
-
|
|
59
|
-
Inngest makes it easy to develop durable functions and workflows in your existing codebase, without any new infrastructure. Inngest Functions are triggered via events — decoupling your code within your application.
|
|
60
|
-
|
|
61
|
-
1. You define your Inngest functions using the [Inngest SDK](#sdks) and serve them through a [simple API endpoint](https://www.inngest.com/docs/sdk/serve?ref=github-inngest-readme).
|
|
62
|
-
2. Inngest automatically invokes your functions via HTTPS whenever you send events from your application.
|
|
63
|
-
|
|
64
|
-
Inngest abstracts the complex parts of building a robust, reliable, and scalable architecture away from you, so you can focus on building applications for your users.
|
|
65
|
-
|
|
66
|
-
- **Run your code anywhere** - We call you via HTTPS so you can deploy your code to serverless, servers or the edge.
|
|
67
|
-
- **Zero-infrastructure required** - No queues or workers to configure or manage — just write code and Inngest does the rest.
|
|
68
|
-
- **Build complex workflows with simple primitives** - Our [SDKs](#sdks) provides easy to learn `step` tools like [`run`](https://www.inngest.com/docs/reference/functions/step-run?ref=github-inngest-readme), [`sleep`](https://www.inngest.com/docs/reference/functions/step-sleep?ref=github-inngest-readme), [`sleepUntil`](https://www.inngest.com/docs/reference/functions/step-sleep-until?ref=github-inngest-readme), and [`waitForEvent`](https://www.inngest.com/docs/reference/functions/step-wait-for-event?ref=github-inngest-readme) that you can combine using code and patterns that you're used to create complex and robust workflows.
|
|
69
|
-
|
|
70
|
-
[Read more about our vision and why Inngest exists](https://www.inngest.com/blog/inngest-add-super-powers-to-serverless-functions)
|
|
80
|
+
|
|
71
81
|
|
|
72
|
-
|
|
82
|
+
Follow our [Next.js](https://www.inngest.com/docs/getting-started/nextjs-quick-start?ref=github-inngest-readme) or [Python](https://www.inngest.com/docs/getting-started/python-quick-start?ref=github-inngest-readme) quick start guides.
|
|
73
83
|
|
|
74
84
|
## SDKs
|
|
75
85
|
|
|
76
|
-
- **TypeScript / JavaScript** ([inngest-js](
|
|
77
|
-
- **Python** ([inngest-py](https://github.com/inngest/inngest-py)) - [Reference](https://www.inngest.com/docs/reference/python)
|
|
86
|
+
- **TypeScript / JavaScript** ([inngest-js](https://github.com/inngest/inngest-js)) - [Reference](https://www.inngest.com/docs/reference/typescript?ref=github-inngest-readme)
|
|
87
|
+
- **Python** ([inngest-py](https://github.com/inngest/inngest-py)) - [Reference](https://www.inngest.com/docs/reference/python?ref=github-inngest-readme)
|
|
78
88
|
- **Go** ([inngestgo](https://github.com/inngest/inngestgo)) - [Reference](https://pkg.go.dev/github.com/inngest/inngestgo)
|
|
79
|
-
|
|
80
|
-
## Getting started
|
|
81
|
-
|
|
82
|
-
👉 [**Follow the full quick start guide here**](https://www.inngest.com/docs/quick-start?ref=github-inngest-readme)
|
|
83
|
-
|
|
84
|
-
### A brief example
|
|
85
|
-
|
|
86
|
-
Here is an example of an Inngest function that sends a welcome email when a user signs up to an application. The function sleeps for 4 days and sends a second product tips email:
|
|
87
|
-
|
|
88
|
-
```ts
|
|
89
|
-
import { Inngest } from 'inngest';
|
|
90
|
-
|
|
91
|
-
const inngest = new Inngest({ id: 'my-app' });
|
|
92
|
-
|
|
93
|
-
// This function will be invoked by Inngest via HTTP any time
|
|
94
|
-
// the "app/user.signup" event is sent to to Inngest
|
|
95
|
-
export default inngest.createFunction(
|
|
96
|
-
{ id: 'user-onboarding-emails' },
|
|
97
|
-
{ event: 'app/user.signup' },
|
|
98
|
-
async ({ event, step }) => {
|
|
99
|
-
await step.run('send-welcome-email', async () => {
|
|
100
|
-
await sendEmail({ email: event.data.email, template: 'welcome' });
|
|
101
|
-
});
|
|
102
|
-
|
|
103
|
-
await step.sleep('delay-follow-up-email', '7 days');
|
|
104
|
-
|
|
105
|
-
await step.run('send-tips-email', async () => {
|
|
106
|
-
await sendEmail({ email: event.data.email, template: 'product-tips' });
|
|
107
|
-
});
|
|
108
|
-
}
|
|
109
|
-
);
|
|
110
|
-
|
|
111
|
-
// Elsewhere in your code (e.g. in your sign up handler):
|
|
112
|
-
await inngest.send({
|
|
113
|
-
name: 'app/user.signup',
|
|
114
|
-
data: {
|
|
115
|
-
email: 'test@example.com',
|
|
116
|
-
},
|
|
117
|
-
});
|
|
118
|
-
```
|
|
119
|
-
|
|
120
|
-
Some things to highlight about the above code:
|
|
121
|
-
|
|
122
|
-
- Code within each `step.run` is automatically retried on error.
|
|
123
|
-
- Each `step.run` is individually executed via HTTPS ensuring errors do not result in lost work from previous steps.
|
|
124
|
-
- State from previous steps is memoized so code within steps is not re-executed on retries.
|
|
125
|
-
- Functions can `sleep` for hours, days, or months. Inngest stops execution and continues at the exactly the right time.
|
|
126
|
-
- Events can trigger one or more functions via [fan-out](https://www.inngest.com/docs/guides/fan-out-jobs)
|
|
127
|
-
|
|
128
|
-
Learn more about writing Inngest functions in [our documentation](https://www.inngest.com/docs).
|
|
129
|
-
|
|
130
|
-
<br />
|
|
89
|
+
- **Kotlin / Java** ([inngest-kt](https://github.com/inngest/inngest-kt))
|
|
131
90
|
|
|
132
91
|
## Project Architecture
|
|
133
92
|
|
|
134
|
-
|
|
93
|
+
To understand how self-hosting works, it's valuable to understand the architecture and system components at a high level. We'll take a look at a simplified architecture diagram and walk through the system.
|
|
135
94
|
|
|
136
95
|
<br />
|
|
137
96
|
|
|
138
97
|
<p align="center">
|
|
139
|
-
<img src=".github/assets/architecture-
|
|
98
|
+
<img src=".github/assets/architecture-2024-09-23.png" alt="System Architecture" width="660" />
|
|
140
99
|
</p>
|
|
141
100
|
|
|
142
|
-
|
|
143
|
-
|
|
144
|
-
- **
|
|
145
|
-
-
|
|
146
|
-
-
|
|
147
|
-
-
|
|
148
|
-
-
|
|
149
|
-
- **
|
|
150
|
-
- **
|
|
151
|
-
- **
|
|
152
|
-
|
|
153
|
-
|
|
154
|
-
|
|
155
|
-
- The **DevServer** combines all the components and basic drivers for each into a single system which reads all functions from your application running on your machine, handles incoming events via the API and executes functions, all returning a readable output to the developer.
|
|
156
|
-
|
|
157
|
-
For specific information on how the DevServer works and how it compares to production [read this doc](/docs/DEVSERVER_ARCHITECTURE.md).
|
|
101
|
+
- **Event API** - Receives events from SDKs via HTTP requests. Authenticates client requests via [Event Keys](https://www.inngest.com/docs/events/creating-an-event-key?ref=github-inngest-readme). The Event API publishes event payloads to an internal event stream.
|
|
102
|
+
- **Event stream** - Acts as buffer between the _Event API_ and the _Runner_.
|
|
103
|
+
- **Runner** - Consumes incoming events and performs several actions:
|
|
104
|
+
- Scheduling of new “function runs” (aka jobs) given the event type, creating initial run state in the _State store_ database. Runs are added to queues given the function's flow control configuration.
|
|
105
|
+
- Resume functions paused via [`waitForEvent`](https://www.inngest.com/docs/features/inngest-functions/steps-workflows/wait-for-event?ref=github-inngest-readme) with matching expressions.
|
|
106
|
+
- Cancels running functions with matching [`cancelOn`](https://www.inngest.com/docs/features/inngest-functions/cancellation/cancel-on-events?ref=github-inngest-readme) expressions
|
|
107
|
+
- Writes ingested events to a database for historical record and future replay.
|
|
108
|
+
- **Queue** - A multi-tenant aware, multi-tier queue designed for fairness and various [flow control](https://www.inngest.com/docs/guides/flow-control?ref=github-inngest-readme) methods (concurrency, throttling, prioritization, debouncing, rate limiting) and [batching](https://www.inngest.com/docs/guides/batching?ref=github-inngest-readme).
|
|
109
|
+
- **Executor** - Responsible for executing functions, from initial execution, step execution, writing incremental function run state to the _State store_, and retries after failures.
|
|
110
|
+
- **State store (database)** - Persists data for pending and ongoing function runs. Data includes initial triggering event(s), step output and step errors.
|
|
111
|
+
- **Database** - Persists system data and history including Apps, Functions, Events, Function run results.
|
|
112
|
+
- **API** - GraphQL and REST APIs for programmatic access and management of system resources.
|
|
113
|
+
- **Dashboard UI** - The UI to manage apps, functions and view function run history.
|
|
158
114
|
|
|
159
115
|
<br />
|
|
160
116
|
|
|
161
117
|
## Community
|
|
162
118
|
|
|
163
|
-
- [**Join our
|
|
119
|
+
- [**Join our Discord community for support, to give us feedback, or chat with us**](https://www.inngest.com/discord).
|
|
164
120
|
- [Post a question or idea to our GitHub discussion board](https://github.com/orgs/inngest/discussions)
|
|
165
121
|
- [Read the documentation](https://www.inngest.com/docs?ref=github-inngest-readme)
|
|
166
122
|
- [Explore our public roadmap](http://roadmap.inngest.com/)
|
|
@@ -169,9 +125,16 @@ For specific information on how the DevServer works and how it compares to produ
|
|
|
169
125
|
|
|
170
126
|
## Contributing
|
|
171
127
|
|
|
172
|
-
We
|
|
173
|
-
|
|
174
|
-
|
|
175
|
-
|
|
128
|
+
We embrace contributions in many forms, including documentation, typos, bug reports or fixes. Check out our [contributing guide](/docs/CONTRIBUTING.md) to get started. Each of our open source [SDKs](#sdks) are open to contributions as well.
|
|
129
|
+
|
|
130
|
+
Additionally, Inngest's website documentation is available for contribution in [the `inngest/website` repo](https://github.com/inngest/website).
|
|
131
|
+
|
|
132
|
+
## Self-hosting
|
|
133
|
+
|
|
134
|
+
Self-hosting the Inngest server is possible and easy to get started with. Learn more about self-hosting Inngest in [our docs guide](https://www.inngest.com/docs/self-hosting?ref=github-inngest-readme).
|
|
135
|
+
|
|
136
|
+
## License
|
|
137
|
+
|
|
138
|
+
The Inngest server and CLI are available under the Server Side Public License and delayed open source publication (DOSP) under Apache 2.0. [View the license here](/LICENSE.md).
|
|
176
139
|
|
|
177
|
-
|
|
140
|
+
All Inngest [SDKs](#sdks) are all available under the Apache 2.0 license.
|