Apex Foundations for LWC Developers

Every JavaScript example so far in this course — the LWC components themselves — runs client-side: in the user's own browser, on their own device. Apex is Salesforce's own programming language, and it runs server-side: on Salesforce's servers, before any result is sent back to the browser.

This distinction is exactly why Module 6 (Lightning Data Service) could do so much without Apex at all — reading and writing simple records doesn't need custom server-side code. The next lesson, "When Apex Is Required," covers precisely when that stops being true. This lesson's job is narrower: making sure the Apex code shown from here on is actually readable, syntax by syntax.

public class AccountController {
    public static String getWelcomeMessage() {
        return 'Hello from Apex';
    }
}

This is the same class / method shape Module 3 taught for JavaScript — a class groups related methods together. The differences that stand out immediately, both covered next: public appears before class and before the method, and the method declares its return type (String) explicitly, right in the signature — Apex requires this; JavaScript never did.

• public — this class or method can be accessed from outside the class. private — the opposite: only usable from inside the same class. Apex methods that LWC needs to call are always public (in fact, @AuraEnabled methods must be public static, covered later in this lesson).
• static — the method belongs to the class itself, not to a specific instance of it. You call it directly on the class name (AccountController.getWelcomeMessage()), without first needing to create an object from that class, similar in spirit to how you've been calling plain JavaScript functions rather than object methods.

Unlike JavaScript, Apex requires every variable's type to be declared up front — Apex is a strongly typed language:

String companyName = 'Acme Corp';
Boolean isActive = true;
Id accountId = '001XXXXXXXXXXXXXXX';
Integer recordCount = 42;

String (text), Boolean (true/false — the exact same concept Module 3 taught, just capitalized here per Apex's naming convention), and Integer (a whole number) map directly onto the string/boolean/number value types already familiar from JavaScript. Id is new: a special Apex type specifically for a Salesforce record's unique identifier — every record of every object has one.

public static List<Account> getAccounts()

Breaking this apart piece by piece:

• public — callable from outside this class (explained above).
• static — called on the class itself, no instance needed (explained above).
• List<Account> — the return type: this method gives back a List (Apex's ordered, resizable collection — conceptually the same job a JavaScript array does) specifically of Account records. <Account> is a type parameter, saying exactly what kind of item the list holds.
• getAccounts — the method's name, chosen by the developer, exactly like naming a JavaScript function.
• () — the parameter list. Empty here means this method needs no input to run; a method needing input would declare typed parameters here, e.g. (String searchTerm).

Every Apex method signature in the rest of this module follows this exact reading order: access modifiers, then return type, then name, then parameters.

Account in the example above is an sObject type — Apex's built-in representation of a Salesforce record. Account, Contact, and Case are all standard sObject types, each with fields matching that object's real fields in Salesforce (Account.Name, Contact.Email, and so on). A List<T> is Apex's core collection type — an ordered, resizable list of items of a specific type, filling the same role a JavaScript array does, just with its item type declared explicitly (List<Account>, List<String>, List<Id>).

List<Account> accounts = [SELECT Id, Name FROM Account WHERE Industry = 'Banking'];

SOQL (Salesforce Object Query Language) is how Apex reads records — a SELECT statement, written directly inside square brackets, embedded right in the Apex code. DML (Data Manipulation Language) is the small set of keywords — insert, update, delete — that write changes back to the database:

Account newAccount = new Account(Name = 'New Company');
insert newAccount;

Both are covered in real depth as this module continues — this is only enough to recognize them by sight in upcoming examples.

Apex has try/catch too, working the same way Module 3 taught it for JavaScript: an exception is an error that stops normal execution unless it's caught. A later lesson in this module covers AuraHandledException specifically — the deliberate exception type used to send a safe, custom error message back to LWC.

Three pieces of syntax will appear on nearly every Apex class and method LWC calls, starting with the very next lesson — enough to use them safely now, with Module 12 providing the complete picture once the rest of this module's data/Apex foundations are in place:

• public with sharing class ... — makes the class respect the running user's normal record-level access (which records they're allowed to see), a safe default for a class LWC calls into.
• @AuraEnabled — the annotation that exposes an Apex method to Lightning components at all; without it, LWC cannot call the method.
• cacheable=true — marks a method as read-only, required for it to be used with @wire (Module 6).

Seeing all three together on a method — @AuraEnabled(cacheable=true) above a public with sharing class's method — is the standard, safe shape for a simple Apex method LWC will read data from.