Inngest has recently extended support for Astro!
If you’re new to either technology, read on to learn how Inngest can help Astro developers to build reliable workflows, background jobs, and long-running processes.
What’s so special about Astro?
Astro’s most common use cases include blogs, marketing sites, and SaaS websites. To see what's possible, visit the rich collection of themes (templates) on their website.
Using API endpoints in Astro
Astro is perhaps best known for building blogs and marketing pages. Because of this, a common misconception about Astro is that it is primarily a static site generator. This, however, couldn’t be further from the truth.
Although Astro defaults to a static rendering mode, you can opt in to a server-rendered mode, or even a hybrid mode combining the two. Most Astro elements (pages, routes, and API endpoints) can be either pre-rendered at build time or rendered on the server at request time/on demand.
Astro also supports custom API endpoints, which become available as API routes under your site. You can use them for tasks like accessing a database, authentication, or supercharging your website with more a complex functionality.
Custom API Endpoint use cases
Static pages are specifically well-suited for sites where content changes infrequently. They can be generated and deployed quickly, such as simple blogs, portfolios, e-commerce landing pages, or documentation.
However, there are benefits to adding your API routes into your Astro codebase, such as:
- It co-locates the frontend code with the serverless functions and processes, reducing context-switching.
- The product team can manage the E2E experience instead of having to rely on cross-team collaboration.
Endpoints are an easy way to add synchronous backend functionality to your website, but what about asynchronous long-running processes and background jobs?
Adding long-running processes into an Astro app
In addition to building websites, product teams commonly own other customer touchpoints such as:
- drip marketing campaigns,
- email notifications systems,
- payment workflows (processing payments, saving information, sending an email to the user, updating the stock, sending a shipment order)
Moreover, product engineers are often responsible for long-running tasks that may require scheduling, queuing, retries, and monitoring:
- scheduling posts to be published,
- chaining LLM interactions,
- responding to a webhook from an external system when a new user signs up,
- orchestrating backend tasks (for example, triggering a queue of tasks whenever a new user is created).
But imagine that an individual product engineer could own the user flow end to end, and implement the entire functionality as part of the same codebase. In most cases, this means a lot of communication between the frontend and backend components, which, in turn, translates into: “as an engineer, you will be endlessly context-switching between different codebases.”
This is where Inngest comes in handy. Inngest takes care of making complex workflows easy to build, manage, and scale.
Inngest is the reliability layer for modern applications. Inngest combines durable execution, events, and queues into a zero-infra platform with built-in observability.
In other words, Inngest makes it easy to build, manage, and execute reliable workflows and background jobs. “Reliable” in this context means that if a task fails, it will not only automatically retry but also provide you with all the information you need to debug it safely on the Inngest platform
How to build complex workflows with Inngest in Astro
Imagine you’d like to send an email notification to users whenever a certain event happens. Without a tool like Inngest, you'd be responsible for task scheduling, execution, and handling retries when the task failed for whatever reason, likely requiring a team of specialists and significant resources.
Instead, a single engineer, product manager, or even indie hacker can use Inngest to handle the execution but also see the error logs, have the failed tasks be automatically retried, and obtain useful metadata.
All of this is done right from your own codebase — you own the code. Here’s how it’s done:
- You implement the business logic in your Astro endpoint.
- The endpoint is exposed to Inngest.
- The Inngest platform will call the endpoint to execute the logic you defined at the right moments. In this case, Inngest will call your function which then sends the email from your server.
- If for some reason the function fails, Inngest will retry as many times as you’ve specified.
- The Inngest dashboard will provide you with helpful information and tools (such as logs and manual function retrying).
Adding background jobs to static Astro sites
But Inngest is not just for Astro developers. Sometimes, some of your business workflows might exist outside of your Astro codebase (sadly).
Being language and framework agnostic, Inngest works across your entire system. You can host different parts of your workflows in different codebases and they can still communicate and invoke with each other via Inngest, without the usual mess of distributed systems (service discoverability, orchestration, retries, monitoring).
You can also send an event from an Astro site that triggers an Inngest function in another codebase.
Get started now
Or, jump right in and explore the code yourself by starting a new Astro and Inngest starter project with a single command:
bashnpm create astro@latest -- --template inngest/inngest-js/examples/framework-astro inngest-astro
Then, open the Astro development server at http://localhost:3000 in your browser and follow the instructions on the landing page 💜
Help shape the future of Inngest
Ask questions, give feedback, and share feature requestsJoin our Discord!