inngest-cli 0.10.0 → 0.12.0
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 +47 -30
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -5,12 +5,10 @@
|
|
|
5
5
|
|
|
6
6
|
|
|
7
7
|
|
|
8
|
-
Run reliable serverless functions in the background.
|
|
9
|
-
|
|
8
|
+
Run reliable serverless functions in the background. Inngest allows you to schedule, enqueue, and run serverless functions in the background reliably with retries on any platform, with zero infrastructure, fully locally testable. Learn more: https://www.inngest.com.
|
|
10
9
|
|
|
11
10
|
<br />
|
|
12
11
|
|
|
13
|
-
|
|
14
12
|
- [Overview](#overview)
|
|
15
13
|
- [Quick Start](#quick-start)
|
|
16
14
|
- [Project Architecture](#project-architecture)
|
|
@@ -26,12 +24,12 @@ The local development UI:
|
|
|
26
24
|
|
|
27
25
|
## Overview
|
|
28
26
|
|
|
29
|
-
Inngest makes it simple for you to write delayed or background jobs by triggering functions from events — decoupling your code
|
|
27
|
+
Inngest makes it simple for you to write delayed or background jobs by triggering functions from events — decoupling your code within your application.
|
|
30
28
|
|
|
31
|
-
- You send events from your application via
|
|
29
|
+
- You send events from your application via our SDK (or with a Webhook)
|
|
32
30
|
- Inngest runs your serverless functions that are configured to be triggered by those events, either immediately, or delayed.
|
|
33
31
|
|
|
34
|
-
Inngest abstracts the complex parts of building a robust, reliable, and scalable architecture away from you so you can focus on writing amazing code and building applications for your users.
|
|
32
|
+
Inngest abstracts the complex parts of building a robust, reliable, and scalable architecture away from you, so you can focus on writing amazing code and building applications for your users.
|
|
35
33
|
|
|
36
34
|
We created Inngest to bring the benefits of event-driven systems to all developers, without having to write any code themselves. We believe that:
|
|
37
35
|
|
|
@@ -46,38 +44,52 @@ We created Inngest to bring the benefits of event-driven systems to all develope
|
|
|
46
44
|
|
|
47
45
|
## Quick Start
|
|
48
46
|
|
|
47
|
+
👉 [Read the full quick start guide here](https://www.inngest.com/docs/quick-start?ref=github-inngest-readme)
|
|
48
|
+
|
|
49
49
|
1. [NPM install our SDK for your typescript project](https://github.com/inngest/inngest-js): `npm install inngest`
|
|
50
|
-
2. Run the Inngest dev server: `npx inngest@latest dev
|
|
51
|
-
3. [Integrate Inngest with your framework in one line](https://www.inngest.com/docs/
|
|
52
|
-
4. [Write and run functions in your existing framework or project](https://www.inngest.com/docs/functions)
|
|
50
|
+
2. Run the Inngest dev server: `npx inngest@latest dev` (This repo's CLI)
|
|
51
|
+
3. [Integrate Inngest with your framework in one line](https://www.inngest.com/docs/sdk/serve?ref=github-inngest-readme) via the `serve()` handler
|
|
52
|
+
4. [Write and run functions in your existing framework or project](https://www.inngest.com/docs/functions?ref=github-inngest-readme)
|
|
53
53
|
|
|
54
54
|
Here's an example:
|
|
55
55
|
|
|
56
|
-
```
|
|
57
|
-
import {
|
|
56
|
+
```ts
|
|
57
|
+
import { Inngest } from "inngest";
|
|
58
58
|
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
59
|
+
const inngest = new Inngest({ name: "My App" });
|
|
60
|
+
|
|
61
|
+
// This function will be invoked by Inngest via HTTP any time the "app/user.signup"
|
|
62
|
+
// event is sent to to Inngest
|
|
63
|
+
export default inngest.createFunction(
|
|
64
|
+
{ name: "User onboarding communication" },
|
|
65
|
+
{ event: "app/user.signup" },
|
|
66
|
+
async ({ event, step }) => {
|
|
67
|
+
await step.run("Send welcome email", async () => {
|
|
65
68
|
await sendEmail({
|
|
66
|
-
email: event.
|
|
69
|
+
email: event.data.email,
|
|
67
70
|
template: "welcome",
|
|
68
|
-
})
|
|
69
|
-
|
|
70
|
-
}
|
|
71
|
+
});
|
|
72
|
+
});
|
|
73
|
+
}
|
|
74
|
+
);
|
|
75
|
+
|
|
76
|
+
// Elsewhere in your code (e.g. in your sign up handler):
|
|
77
|
+
|
|
78
|
+
inngest.send({
|
|
79
|
+
name: "app/user.signup",
|
|
80
|
+
data: {
|
|
81
|
+
email: "test@example.com",
|
|
82
|
+
},
|
|
83
|
+
});
|
|
71
84
|
```
|
|
72
85
|
|
|
73
|
-
|
|
74
86
|
That's it - your function is set up!
|
|
75
87
|
|
|
76
88
|
<br />
|
|
77
89
|
|
|
78
90
|
## Project Architecture
|
|
79
91
|
|
|
80
|
-
Fundamentally, there are two core pieces to Inngest: _events_ and _functions_. Functions have several
|
|
92
|
+
Fundamentally, there are two core pieces to Inngest: _events_ and _functions_. Functions have several subcomponents for managing complex functionality (eg. steps, edges, triggers), but high level an event triggers a function, much like you schedule a job via an RPC call to a queue. Except, in Inngest, **functions are declarative**. They specify which events they react to, their schedules and delays, and the steps in their sequence.
|
|
81
93
|
|
|
82
94
|
<br />
|
|
83
95
|
|
|
@@ -85,20 +97,20 @@ Fundamentally, there are two core pieces to Inngest: _events_ and _functions_. F
|
|
|
85
97
|
<img src=".github/assets/architecture-0.5.0.png" alt="Open Source Architecture" width="660" />
|
|
86
98
|
</p>
|
|
87
99
|
|
|
88
|
-
Inngest
|
|
100
|
+
Inngest’s architecture is made up of 6 core components:
|
|
89
101
|
|
|
90
102
|
- **Event API** receives events from clients through a simple POST request, pushing them to the **message queue**.
|
|
91
103
|
- **Event Stream** acts as a buffer between the **API** and the **Runner**, buffering incoming messages to ensure QoS before passing messages to be executed.<br />
|
|
92
104
|
- A **Runner** coordinates the execution of functions and a specific run’s **State**. When a new function execution is required, this schedules running the function’s steps from the trigger via the **executor.** Upon each step’s completion, this schedules execution of subsequent steps via iterating through the function’s **Edges.**
|
|
93
105
|
- **Executor** manages executing the individual steps of a function, via _drivers_ for each step’s runtime. It loads the specific code to execute via the **DataStore.** It also interfaces over the **State** store to save action data as each finishes or fails.
|
|
94
|
-
- **Drivers** run the specific action code for a step,
|
|
106
|
+
- **Drivers** run the specific action code for a step, e.g. within Docker or WASM. This allows us to support a variety of runtimes.
|
|
95
107
|
- **State** stores data about events and given function runs, including the outputs and errors of individual actions, and what’s enqueued for the future.
|
|
96
108
|
- **DataStore** stores persisted system data including Functions and Actions version metadata.
|
|
97
|
-
- **Core API** is the main interface for writing to the DataStore. The CLI uses this to deploy new
|
|
109
|
+
- **Core API** is the main interface for writing to the DataStore. The CLI uses this to deploy new functions and manage other key resources.
|
|
98
110
|
|
|
99
111
|
And, in this CLI:
|
|
100
112
|
|
|
101
|
-
- The **DevServer** combines all
|
|
113
|
+
- The **DevServer** combines all the components and basic drivers for each into a single system which loads all functions on disk, handles incoming events via the API and executes functions, all returning a readable output to the developer. (_Note - the DevServer does not run a Core API as functions are loaded directly from disk_)
|
|
102
114
|
|
|
103
115
|
For specific information on how the DevServer works and how it compares to production [read this doc](/docs/DEVSERVER_ARCHITECTURE.md).
|
|
104
116
|
|
|
@@ -107,12 +119,17 @@ For specific information on how the DevServer works and how it compares to produ
|
|
|
107
119
|
## Community
|
|
108
120
|
|
|
109
121
|
- [**Join our online community for support, to give us feedback, or chat with us**](https://www.inngest.com/discord).
|
|
110
|
-
- [Post a question or idea to our
|
|
111
|
-
- [Read the documentation](https://www.inngest.com/docs)
|
|
122
|
+
- [Post a question or idea to our GitHub discussion board](https://github.com/orgs/inngest/discussions)
|
|
123
|
+
- [Read the documentation](https://www.inngest.com/docs?ref=github-inngest-readme)
|
|
112
124
|
- [Explore our public roadmap](https://github.com/orgs/inngest/projects/1/)
|
|
113
125
|
- [Follow us on Twitter](https://twitter.com/inngest)
|
|
114
126
|
- [Join our mailing list](https://www.inngest.com/mailing-list) for release notes and project updates
|
|
115
127
|
|
|
116
128
|
## Contributing
|
|
117
129
|
|
|
118
|
-
We’re excited to embrace the community! We’re happy for any and all contributions, whether they’re
|
|
130
|
+
We’re excited to embrace the community! We’re happy for any and all contributions, whether they’re
|
|
131
|
+
feature requests, ideas, bug reports, or PRs. While we’re open source, we don’t have expectations
|
|
132
|
+
that people do our work for us — so any contributions are indeed very much appreciated. Feel free to
|
|
133
|
+
hack on anything and submit a PR.
|
|
134
|
+
|
|
135
|
+
Check out our [contributing guide](/docs/CONTRIBUTING.md) to get started.
|