News for hackers. Stuff that matters.
Re:Launch HN: Defer (YC W23) – Zero-infrastructure backgroun... by johtso on Friday March 10, 2023 @12:44PM (#35098036)
Often you want to specify your own unique id based on some property of the job, like a transaction reference, or just a unique combination of parameters. This means you can later refer to it without having to store the reference somewhere. Is this possible?
Re:Launch HN: Defer (YC W23) – Zero-infrastructure backgroun... by gearnode on Friday March 10, 2023 @12:54PM (#35098184)
We specify our unique ID based on KSUID specifications. In addition, we are soon releasing the tag feature, which will enable you to store your references on your Defer executions to identify them your way.
Re:Launch HN: Defer (YC W23) – Zero-infrastructure backgroun... by johtso on Friday March 10, 2023 @01:25PM (#35098685)
Just ideally the dev experience should be `result = await somethingThatMayHaveBeenCalledBefore(id=txnref, params)`

You shouldn't need to first do a check to see if the task already exists using a different api, and then choose whether or not to run a new task.

At least this is my preference.. a-la Durable Objects.

If you don't specify a custom unique id when calling the task it would then be treated as a task that can (and would make sense to be) run multiple times (i.e. not idempotent).

Re:Launch HN: Defer (YC W23) – Zero-infrastructure backgroun... by gearnode on Friday March 10, 2023 @02:06PM (#35099350)
Completely agree with you on the importance of idempotency. We will release our implementation shortly with a pattern close to the following:

``` const somethingThatMayHaveBeenCalledBefore = idempotent(myFunc, txnref); const result = await somethingThatMayHaveBeenCalledBefore(params); ```