What is the planned Background operations module designed to do?
A lot of app behavior happens when nobody is looking at the screen. A reminder goes out at 7 in the morning. A trial expires. A generated image finishes after thirty seconds. The planned background operations module covers scheduled tasks, durable event reactions, background jobs, retry handling, time-based expiration, controlled calls to external services, and execution history and diagnostics.
Developers should configure the behavior they want rather than implement and host their own job workers. That is the intent: no queue to run, no cron host to keep alive, no worker code to deploy.
How does the Background operations module connect to other modules?
Background jobs are planned as the engine that other modules lean on for time and durability.
- Background jobs + Push notifications. A scheduled reminder is designed as a job that sends a template. Per-user timezones are meant to be handled by the schedule.
- Background jobs + AI gateway. Slow provider calls are designed to run as jobs that survive a client disconnect, so the result can be stored and the user told when it is ready.
- Background jobs + Database. Jobs are designed to read and update records, for example to expire old invitations or archive finished items.
- Background jobs + Business logic. A rule can enqueue work, such as recalculating a leaderboard, and the job layer is designed to run it with retries.
- Authentication + Database + Background jobs. Together they are designed to support per-user recurring work, such as a weekly summary built from one user’s records.
Because jobs are durable, the intent is that a restart does not lose work that was already accepted.
What would you configure in the Background operations module?
You declare schedules or the events that start a job, the action it runs, its retry and backoff settings, and how long history is kept. For time-based expiration, you set the rule on the record, such as an invitation that ends after a set period.
The configuration on this page is illustrative. The syntax is not final.
What stays your own code with the Background operations module?
Custom processing that is unique to your product, such as a proprietary scoring routine, is still your logic to define. Edict is designed to run declared actions reliably. It is not meant to host arbitrary long-running programs. You also decide what is worth running in the background and what a failure should mean for your users.
Is the Background operations module available yet?
Planned. Edict is in development, and this module is not available. Production deployment, performance, and scale are not claimed until they are built and measured.
Join the beta waitlist to follow progress.