Governor Limits and Bulkification from LWC

Governor limits (per-transaction caps on SOQL queries, DML statements, and callouts) are usually taught as a purely Apex concern — but a component's calling pattern can trigger them just as easily. Calling an Apex method once per row inside a loop creates one full transaction per call, each with its own limits, quickly compounding into real problems at scale.

// Avoid: one Apex call per row
for (const account of this.selectedAccounts) {
    await updateAccountStatus({ accountId: account.id, status: 'Active' });
}

Ten selected rows means ten separate Apex transactions — ten times the SOQL/DML overhead, and ten times slower for the user.

// Prefer: one Apex call for the whole batch
const accountIds = this.selectedAccounts.map(account => account.id);
await updateAccountStatuses({ accountIds, status: 'Active' });

@AuraEnabled
public static void updateAccountStatuses(List<Id> accountIds, String status) {
    List<Account> accounts = [SELECT Id, Status__c FROM Account WHERE Id IN :accountIds WITH SECURITY_ENFORCED];
    for (Account acc : accounts) {
        acc.Status__c = status;
    }
    update accounts;
}

One Apex call carrying a list of IDs, and one bulk update inside it — a single transaction handling every selected record, exactly the bulkification discipline Apex development already requires, applied at the calling boundary too.

This is one of the most common real-world performance bugs in LWC/Apex integrations — a component that works fine in testing with 2-3 rows selected, then times out or hits limits in production when a user selects 200.