wittydeveloper

Thank you, good question!

We want to enable developers working on a side project to build apps faster and new startups to have a faster time to market by avoiding spending time on infrastructure and building custom layers of API and dashboard.

We also want to help bigger companies to take back control of their custom background jobs stack and to be able to ship new features or sub-products quickly. Again for growing companies, we provide Custom Pricing which comes with degressive pricing with custom concurrency to support, for example, high throughput needs.

Thank you!

Right now, you will need to ensure that your background functions are idempotent but we plan to introduce an API for “retried execution” so you can clean up. Also, by default retry is an opt-in configuration option to avoid any unwanted side effects, the same goes with concurrency.

The Builder part is clearly a differentiator; however, background functions are different from Serverless functions on many points - on top of being natively integrated with our Scheduler.

First, they allow a maximum execution time comparable to “pure server” environments, instead of 15min.

Then, the code-first approach allows configuring the execution parameters (concurrency, retries, and more) from the function’s code and enables to write workflows by applying well-known code patterns such as recursion or map-reduce (calling child background functions is a workflow).

Finally, you can write a background function that requires any kind of dependencies, whether they be internal, external, or even native.