When Apex Is Required
By the end of this lesson, you'll be able to:
- Recognize the boundary between what Lightning Data Service can do and what genuinely requires Apex
- Identify concrete signals that a task needs custom server-side logic
- Avoid reaching for Apex when LDS alone would do the job
Prerequisites: Module 6: "Project: Account/Contact Management Without Apex"
The Boundary Between LDS and Apex
Module 6 closed with a note that LDS handles straightforward record CRUD well, but isn't a replacement for complex business logic or aggregation across many records. This module explores that boundary in depth — and how to cross it properly when the task genuinely requires it.
Signals That You Need Apex
- Aggregation or complex queries — totals, counts, or joins across multiple related objects that a single record read can't express.
- Complex business validation — rules that depend on data from several objects or external systems at once.
- Callouts to external systems — LWC cannot call an external HTTP API directly; only Apex can perform callouts.
- Bulk operations beyond simple CRUD — processing many records with conditional logic in a single transaction.
- Bypassing default record access — rare, and done deliberately and carefully (
without sharing), never as a shortcut.
Anti-Pattern: Reaching for Apex Too Early
Writing a full Apex controller — plus its mandatory test class, plus its deployment and maintenance burden — just to fetch a single record's single field is unnecessary overhead. If Module 6's @wire(getRecord, ...) already does the job with zero custom code, that's the right tool. Apex should be reached for because the task needs it, not out of habit.
A Decision Checklist
Before writing an Apex controller for a component, ask:
- Can
getRecord/getFieldValueor a base record component already do this? - Does this genuinely need data from more than one unrelated query, or business logic LDS can't express?
- Does it need a callout, or logic no declarative/LDS tool provides?
If the answer to (1) is yes, stop — LDS already solves it. Only questions (2) and (3) are real Apex triggers.
Exercise
A component needs to show the total value of all closed-won Opportunities for the current Account. Explain, as a comment, why this needs Apex rather than LDS alone.
Show hint
Think about what a single wire read can and can't express.
Exercise
Challenge: a developer writes an Apex controller purely to fetch one Contact's Email field, with a full test class alongside it. Explain, as a comment, what the simpler alternative is.
Show hint
Recall what Module 6 already covers for this exact case.
When Apex Is Required Quiz
My Notes
Log in to keep private notes on this lesson.
Questions about this lesson
No questions yet — be the first to ask.
Log in to ask a question about this lesson.
Summary
Apex earns its complexity when the task genuinely needs it — multi-object aggregation, complex validation, external callouts — not as a default first choice over Lightning Data Service.