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.
Oh interesting! So say if you wanted to call 3rd party API in your function, with some exponential backoff retry, without blocking your concurrency allowance, would you model that as recursively calling the same function with an attempt argument?
Yeah, that will be the way to go.
This is actually how on of customers is achieving this behaviour for polling analytics.
Right now our Executions list is not ideal for such pattern but we will soon release filtering based on arguments which will help to get all the executions linked to a specific sequence.
Comments
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.
Oh interesting! So say if you wanted to call 3rd party API in your function, with some exponential backoff retry, without blocking your concurrency allowance, would you model that as recursively calling the same function with an attempt argument?
Does this look nice in the observability layer?
Yeah, that will be the way to go. This is actually how on of customers is achieving this behaviour for polling analytics.
Right now our Executions list is not ideal for such pattern but we will soon release filtering based on arguments which will help to get all the executions linked to a specific sequence.