Automation Without Magic
OpenStock’s background workflows answer a different question from its pages: what should happen after the user leaves the screen? A sign-up event can start a welcome message, a weekly schedule can turn market news into a broadcast, an alert check can revisit stored price rules, and an inactivity schedule can look for users who have not returned. The useful way to judge these features is to trace each job from trigger to side effect and separate the failures that fallback can absorb from the failures that still reach delivery or operations.
Why work moves out of the page request
A page request has a short, user-visible lifetime. It should obtain enough information to render a response without waiting for every long-running or failure-prone activity to finish. OpenStock’s workflows move several kinds of work outside that path through Inngest. The application exposes an event-driven welcome function, a weekly-news function that can also be triggered by an event, a recurring stock-alert check, and a daily inactive-user check.
Each trigger represents a different relationship with time. The welcome workflow begins when an account is created. It does not require the person to keep the sign-up page open while personalized content is generated and emailed. The weekly-news workflow runs on a schedule or explicit event rather than on every dashboard visit. The alert workflow revisits stored rules at regular intervals. The inactive-user workflow asks a daily question about a user’s past activity. Inngest gives these jobs a place to run when no browser request is waiting for them.
This arrangement also makes the application’s state transitions explicit. The alert job reads active rules and may mark one triggered. The inactive-user job reads activity fields and may update a re-engagement timestamp. The welcome job consumes an event containing onboarding information and produces a message. A scheduled workflow is not an invisible extension of a page; it is a separate actor with its own trigger, input, steps, and side effects.
Moving work out of the request path does not make it free or automatic. It introduces a new operational surface. A job needs a trigger to arrive, credentials to call its providers, a place to store or log its result, and a defined behavior when a downstream service fails. The benefit is that those concerns can be handled as workflow steps instead of being hidden inside a click handler. The cost is that the user may see the initiating action succeed before the later effect has succeeded.
Steps make a workflow inspectable
OpenStock divides its background functions into explicit step.run units. The welcome path separates AI generation from sending the welcome email. The weekly-news path separates fetching articles, generating the summary, and sending the Kit broadcast. The alert path separates reading active alerts, fetching prices, and processing triggered records. The inactive-user path separates finding candidates from processing their messages.
A step boundary is valuable because it names a unit of work with a distinct input and outcome. If the news fetch fails, that is a different problem from an AI response failing after the articles have been retrieved. If a threshold is detected but the database update fails, that is different from the quote request being unavailable. A workflow system can reason about those failures more clearly when they are not hidden inside one large function.
The boundaries also separate state reads from side effects.