Prisma1: Concurrency/Queuing options for subscriptions

[sorenbs]

Subscriptions (formerly serverside subscriptions) should gain three new nobs to manage concurrency:

maxConcurrency

How many function invocations can be running at the same time to handle subscription events.

Defaults to 100

maxBatchSize

How many subscription events should be delivered to a function per invocation. If this value is greater than one, then the input data is an array

Defaults to 1

maxBatchWait

The maximum time in seconds to wait for a batch to fill up. If this value is 0, the batch will contain multiple items only if there are already multiple items waiting to be processed.

Defaults to 0.

Use cases

A primary use case is to serialise function execution to avoid race conditions.

Considerations

It might be relevant to introduce a partition query that would allow you to configure concurrency for buckets of events. For example, if you are building a ticket reservation system, you might want to serialise all ticket reservations to make sure you don't sell more tickets than you have, but tickets for two different concerts can be processed at the same time by different queues without risk of a race condition.

[kbrandwijk]

Regarding maxBatchSize and maxBatchWait. I think batching should be explicit, so using a shouldBatch boolean, not derived from maxBatchSize == 1. Also, with maxBatchWait, or batchInterval like Apollo calls it, maxBatchSize should be optional. And lastly, I also see use cases for a minBatchSize, in which case maxBatchWait could be optional. So the combinations I see are:

• minBatchSize = 10. Wait until minBatchSize is reached, then send
• minBatchSize = 10 and maxBatchWait = 500. Wait until minBatchSize or maxBatchWait is reached, then send
• maxBatchSize = 10. This can't be used alone (at least I can't come up with what it means)
• maxBatchSize = 10 and maxBatchWait = 500. Wait until maxBatchWait is reached, unless maxBatchSize is reached sooner, then send

[kbrandwijk]

I just thought of a very cool, related requirement: a delay parameter, that delays execution of the subscription (and the actual query).

Use case: I have a client app, with a client side subscription. So when a user has my app open, the client side subscription will immediately trigger, and I will call an update mutation that the user has received the message.

Now, I want to add a SSS that runs after 10 seconds, and I have that received field as part of the subscription query. I can now assume in the SSS for my Message Type, that any User that hasn't set the received field to true for a certain Message, does not have the app open. I can now trigger a push notification to any user that hasn't received the message yet.

This might be stretching the limits of this FR, but I think it's a great usecase.

Another use case: I can trigger an action using a SSS with a certain delay to send a reminder for example.

Notice that for the first use case, using a delay inside the function wouldn't work, because I depend on the changed subscription query results. Therefore, it's not about delaying the function, but delaying the execution of the actual subscription query.

[kbrandwijk]

@sorenbs This is still a huge missing piece of functionality, also for other function types (resolvers and hooks). Any way we can get this moving to the next stage?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.