Why is using Async LWC component for Batch updates against best Practice?

Question

Sometimes companies need to make bulk updates to all data so they can fill in object fields following a service call to an external platform that is communicating with their Salesforce org following an update to said object. So for this example we will say the object is Reward__c and they want to fill that new field on the Reward__c object called External_Image_Url__c. This field would be populated on an after update trigger call to the external system which would come back and update the Reward__c on its response with the proper External_Image_Url__c value. In this scenario this callout would be in queueable context to avoid governor limits. The company wants to update every Reward in their org with the new value. We will say 60,000 Reward__c records.

What reason is there that says creating a System administrator only async LWC to execute the updates on all 60k records, 50+ at a time, until all records have the desired field is not a good solution to assigning the field after hitting the already implemented service on the after update trigger of the Reward__c object?

In my opinion for this the solution would slowly assign all values to the Reward__c records without having to run a script manually over an over.

To prevent records from erroring over an over from being queried by the LWC you could have error flag set if that record came back from the service with an error the previous attempt that would need to be resolved before being attempted again by the service and even an error cause field for solutioning is needed.

This question is mostly about Best practice and why a script or a different update method is preferred over a LWC that wouldn't have to be closely monitored following initial execution provided the solution has already been tested in a lower environment with similar data.

Answer 1

It's kind of been done before, such as in HyperBatch (but uses Visualforce instead of LWC). There are a number of concerns with this approach, however.

First, remember that you're limited to how many concurrent callouts you can have to a given domain--across your entire org. Similarly, long running transactions may be cancelled if there are too many, so some careful design consideration is needed, and admins may need to coordinate between themselves if they plan on using it regularly.

Aside from the org-wide limits, though, client-side batching can be incredibly effective. With a proper design, you can potentially achieve 1,000+% faster updates than server-side processing alone. Just keep in mind that some configuration and hardware requirements might become necessary on the admin computers, such as turning off sleep/power saving modes, ensuring they have enough memory installed and available, and so on.

I have also used a similar design to, for example, scan every object key prefix to find any hidden sObject types that are in an org (e.g. because of features that are not enabled, etc). I've also used this trick to build an import wizard to upload records quickly from a CSV. It has a lot of practical uses that shouldn't be overlooked. As long as you remember to test things like concurrency, database contention, and so on, there's no reason why you shouldn't use this concept if it makes sense.