Here's some good ol' hyperlinks:
[1]: https://www.inngest.com/docs/what-is-inngest
[2]: https://www.github.com/inngest/inngest-cli
[3]: https://www.inngest.com/docs/high-level-architecture
[4]: https://www.inngest.com/blog/open-source-event-driven-queue
[5]: https://github.com/inngest/demo-nextjs-full-stack","title":null,"type":"comment","url":null},{"author":"mdaniel","children":[{"author":"tonyhb","children":[],"created_at":"2022-06-28T18:54:36.000Z","created_at_i":1656442476,"id":31911589,"options":[],"parent_id":31911496,"points":null,"story_id":31910762,"text":"We have an issue to move code to GPL after some time: https://github.com/inngest/inngest-cli/issues/136.
It's a balance between "give it to everyone including AWS with zero limits" and have some form of limited, time-bound protection.
In short, we're not looking for free contributors by making this open source; we want people to be able to self host.","title":null,"type":"comment","url":null}],"created_at":"2022-06-28T18:49:09.000Z","created_at_i":1656442149,"id":31911496,"options":[],"parent_id":31910762,"points":null,"story_id":31910762,"text":"SSPL https://github.com/inngest/inngest-cli/blob/v0.3.0/LICENSE.m...","title":null,"type":"comment","url":null}],"created_at":"2022-06-28T17:49:12.000Z","created_at_i":1656438552,"id":31910762,"options":[],"parent_id":null,"points":19,"story_id":31910762,"text":"Hi HN! We\u2019re Tony and Dan, the founders of Inngest - https://www.inngest.com.
We\u2019re an event-driven queueing system. Existing queueing solutions have pretty terrible UX. We solve this by making it simple for you to write delayed or background jobs by triggering step functions from JSON-based events.
At a high level, Inngest does two things:
- Ingest events from your systems via HTTP (pun intended)
- Triggers serverless functions in response to specific events \u2014 async, either immediately or delayed.
This allows you to build out async functions (eg. background jobs, handling webhooks) much faster, without worrying about config, queues, scaffolding, boilerplate, or infra. Because of the decoupling, it also means cleaner code. We talk about the benefits here [1].
Previously, Tony ran engineering at https://www.uniformteeth.com/ and Dan was the CTO of https://buffer.com/. At both places, we had to build and manage a lot of complex async logic. You could say that Buffer is one big queue, and at Uniform we had lots of logic to run for compliance\u2026 managed via queues. So we're very familiar with the problem.
Technicals and how it\u2019s different:
Functions are declarative. They specify which events trigger them, with optional conditionals. This is great because you can then deploy functions independently from your core systems, and you get things like canary deploys, plus immediate rollbacks.
Each function can have many steps, represented as a DAG. Each step can be any code \u2014 an AWS function, custom code in a container, an HTTP call, etc. Edges of the DAG can also have conditions for traversal, and can \u201cpause\u201d until another event comes in, with TTLs and timeout (eg. after signup, run step 1, wait for a user to do something else, then run the next step).
Because the functions are event driven, we also statically type and version events for you. This lets you inspect and generate SDKs for events, or to fail early on invalid data. It also lets you replay functions, test with historical data, or deploy functions and re-run historical events.
Architecturally, we\u2019ve focused on simple standards that are easy to learn and adopt. Events are published via HTTP requests. Functions use args & stdout.
You can get started without knowing any implementation details. You only need to send events via POST requests and write functions that react to them \u2014 nothing else required.
What people use us for:
- A replacement for their current queueing infrastructure (eg. celery).
- Running functions after receiving webhooks
- Running business logic when users perform specific actions (eg. publishing things at a specific time)
- Handling coordinated logic (eg. when a user signs up, wait for a specific event to come in then run another step)
Where we\u2019re at:
We\u2019ve open sourced our core execution engine [2], which allows you to run an in-memory environment locally with a single command. We\u2019re working on opening more and more of the platform to allow you to self host \u2014 that\u2019s currently our main goal. Right now, you can use us \u201cserverless\u201d. Because we record function state, we charge per \u2018step\u2019 of a function invoked.
We\u2019ve documented our core OS architecture [3], and we\u2019ve also released the function spec and interfaces in our repo. We\u2019ve talked more about about goals, vision, and why in our open sourcing post [4]. There\u2019s also a minimal demo w/ a Next.js backend [5].
We know we\u2019re far from feature complete. There\u2019s so much more we can do. If there\u2019s things you\u2019d like to see, feedback, or improvements, please let us know \u2014 we\u2019d love to hear from you and make this better, and get your initial thoughts.
[1]: https://www.inngest.com/docs/what-is-inngest
[2]: https://www.github.com/inngest/inngest-cli
[3]: https://www.inngest.com/docs/high-level-architecture
[4]: https://www.inngest.com/blog/open-source-event-driven-queue
[5]: https://github.com/inngest/demo-nextjs-full-stack","title":"Show HN: Inngest \u2013 an open-source event-driven queue","type":"story","url":null}