npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

inngest-cli

v0.28.0

Published

The event-driven queue for any language.

Downloads

50,780

Readme

Inngest

Latest release Test Status Discord Twitter Follow

Inngest is a developer platform that combines event streams, queues, and durable execution into a single reliability layer.

Build and ship durable functions and workflows in your current codebase without any additional infrastructure. Using Inngest, your entire team can ship reliable products.

  • Write durable functions in your existing codebase using an Inngest SDK
  • Run the open source Inngest Dev Server for a complete local development experience, with production parity.
  • The Inngest Platform invokes your code wherever you host it, via HTTPS. Deploy to your existing setup, and deliver products faster without managing infrastructure.

SDKs: TypeScript/JavaScriptPythonGo


The Inngest Dev Server

npx inngest-cli@latest dev

Inngest Dev Server screenshot

Overview

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.

  1. You define your Inngest functions using the Inngest SDK and serve them through a simple API endpoint.
  2. Inngest automatically invokes your functions via HTTPS whenever you send events from your application.

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.

  • Run your code anywhere - We call you via HTTPS so you can deploy your code to serverless, servers or the edge.
  • Zero-infrastructure required - No queues or workers to configure or manage — just write code and Inngest does the rest.
  • Build complex workflows with simple primitives - Our SDKs provides easy to learn step tools like run, sleep, sleepUntil, and waitForEvent that you can combine using code and patterns that you're used to create complex and robust workflows.

Read more about our vision and why Inngest exists


SDKs

Getting started

👉 Follow the full quick start guide here

A brief example

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:

import { Inngest } from 'inngest';

const inngest = new Inngest({ id: 'my-app' });

// This function will be invoked by Inngest via HTTP any time
// the "app/user.signup" event is sent to to Inngest
export default inngest.createFunction(
  { id: 'user-onboarding-emails' },
  { event: 'app/user.signup' },
  async ({ event, step }) => {
    await step.run('send-welcome-email', async () => {
      await sendEmail({ email: event.data.email, template: 'welcome' });
    });

    await step.sleep('delay-follow-up-email', '7 days');

    await step.run('send-tips-email', async () => {
      await sendEmail({ email: event.data.email, template: 'product-tips' });
    });
  }
);

// Elsewhere in your code (e.g. in your sign up handler):
await inngest.send({
  name: 'app/user.signup',
  data: {
    email: '[email protected]',
  },
});

Some things to highlight about the above code:

  • Code within each step.run is automatically retried on error.
  • Each step.run is individually executed via HTTPS ensuring errors do not result in lost work from previous steps.
  • State from previous steps is memoized so code within steps is not re-executed on retries.
  • Functions can sleep for hours, days, or months. Inngest stops execution and continues at the exactly the right time.
  • Events can trigger one or more functions via fan-out

Learn more about writing Inngest functions in our documentation.

Project Architecture

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.

Inngest’s architecture is made up of 6 core components:

  • Event API receives events from clients through a simple POST request, pushing them to the message queue.
  • Event Stream acts as a buffer between the API and the Runner, buffering incoming messages to ensure QoS before passing messages to be executed.
  • 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.
  • 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.
    • Drivers run the specific action code for a step, e.g. within Docker or WASM. This allows us to support a variety of runtimes.
  • State stores data about events and given function runs, including the outputs and errors of individual actions, and what’s enqueued for the future.
  • DataStore stores persisted system data including Functions and Actions version metadata.
  • Core API is the main interface for writing to the DataStore. The CLI uses this to deploy new functions and manage other key resources.

And, in this CLI:

  • 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.

For specific information on how the DevServer works and how it compares to production read this doc.

Community

Contributing

We’re excited to embrace the community! We’re happy for any and all contributions, whether they’re feature requests, ideas, bug reports, or PRs. While we’re open source, we don’t have expectations that people do our work for us — so any contributions are indeed very much appreciated. Feel free to hack on anything and submit a PR.

Check out our contributing guide to get started.