Wiring Apex & LDS

A component is only useful when it works with real data, and LWC gives you two complementary ways to get it. The first is the Lightning Data Service (LDS), which reads and writes single records with no Apex at all and shares a client-side cache across the page. The second is wiring your own Apex methods for anything LDS cannot express — complex queries, multi-object logic, or aggregations.

LDS is the preferred default for single-record work because it is cached, keeps the whole page in sync, and respects field-level security automatically. You use base components like lightning-record-form or the wire adapters getRecord and updateRecord from the lightning/uiRecordApi module.

For custom server logic, expose an Apex method with @AuraEnabled(cacheable=true) and consume it with the @wire decorator, which is reactive: when a wired parameter changes, LWC re-invokes the method and re-renders.

public with sharing class ContactController {
    @AuraEnabled(cacheable=true)
    public static List<Contact> getContacts(Id accountId) {
        return [SELECT Id, Name, Email
                FROM Contact WHERE AccountId = :accountId];
    }
}

import { LightningElement, api, wire } from 'lwc';
import getContacts from '@salesforce/apex/ContactController.getContacts';

export default class ContactList extends LightningElement {
    @api recordId;                  // the current record's Id, set on a record page

    @wire(getContacts, { accountId: '$recordId' })   // '$' makes it reactive
    contacts;                        // { data, error } provisioned by the wire
}

Two rules matter. Mark cacheable Apex methods cacheable=true so @wire can cache them (such methods must not perform DML). And prefix a reactive parameter with $ ('$recordId') so the wire re-runs whenever it changes. For imperative calls — say, on a button click — import the same method and call it as a Promise instead of wiring it.

As an exercise, build a component that takes the record page's recordId and wires the Apex above to list an account's contacts. Prefer LDS when you are reading or editing one record, and reach for Apex when the logic is genuinely custom. With data flowing, the developer track's final section covers connecting Salesforce to the outside world.