What Even Is Apex?
Now that you’ve got your own free org from the last episode, let’s talk about the language you’re going to be writing in.
Let me start by reading you Salesforce’s own definition, straight from the official docs:
“Apex is a strongly typed, object-oriented programming language that allows developers to execute flow and transaction control statements on the Lightning Platform server in conjunction with calls to the Lightning Platform API… Apex enables developers to add business logic to most system events, including button clicks…”
Cool. Very helpful. If you already know what all those words mean, you didn’t need the definition. If you don’t, that paragraph raised about six new questions. What’s a strongly typed language? What’s object-oriented? What are transaction control statements? What are database stored procedures?
So let’s do this in plain English instead.
The Plain English Version
Apex is a programming language Salesforce built for its own platform. It only runs on Salesforce, and it exists so you can build functionality that the out of the box point and click tools can’t handle.
That’s really it. That’s the whole thing.
It looks and behaves a lot like Java (not JavaScript, those are two completely different languages and confusing them will cause you pain), and it borrows a fair bit from C# as well. If you’ve written either of those, Apex is going to feel familiar within about an hour.
What makes Apex special isn’t the syntax, it’s that the database is built right into the language. In most languages, talking to a database means pulling in a library, opening a connection, and writing query strings. In Apex you just… write the query, inline, and the compiler checks it for you. We’ll get deep into that later in the series.
What “Object Oriented” Means
Let’s use an example. Say I’ve got an Apex class called OpportunityCalculator. Think about a physical calculator for a second. It’s a thing, and that thing can do stuff: add, subtract, multiply, divide.
Object oriented programming is basically that. You create a representation of some thing in code, and you give it the behaviours that thing should have.
public class OpportunityCalculator
{
public Integer addValues(Integer valueOne, Integer valueTwo)
{
return valueOne + valueTwo;
}
public Integer subtractValues(Integer valueOne, Integer valueTwo)
{
return valueOne - valueTwo;
}
}That’s an object (the calculator) and its methods (the things it can do). At a high level, that’s object oriented programming.
Now, there’s a lot more to it than that. The four pillars you’ll eventually need to properly understand are encapsulation, abstraction, inheritance and polymorphism. We are absolutely going to cover all four in this series, and I’ve also got a whole Design Patterns series that digs into them properly. But you don’t need them today. Today, “an object with methods on it” is enough.
What “Strongly Typed” Means
This one’s simpler, but it’s easier to understand if you’ve seen a language that isn’t strongly typed.
In Apex, every time you create a variable, you have to tell the compiler what kind of value it’s going to hold. Every time you write a method, you have to tell the compiler what kind of value it’s going to hand back.
//This works. We told Apex it's an Integer.
Integer numberValue = 1;
String optyName = 'Cool Opportunity';
//This does NOT work.
numberValue = 1;That second one won’t save. Apex throws an “unexpected token” error at you, which is a spectacularly unhelpful message when you’re new. All it actually means is “you forgot to tell me what type this is.”
Same deal with methods. Look back at the calculator above, at public Integer addValues(...). That Integer sitting before the method name is a promise: when this method finishes, it is handing you back an Integer. Not a String, not a Date, an Integer.
Compare that to JavaScript, which you’d use in a Lightning Web Component. Over there you’d just write let numberValue = 1; and move on. No type, no declared return value, JavaScript figures it out at runtime.
Now, having to declare everything feels like extra typing when you’re starting out. It isn’t busywork. It means the compiler catches a whole category of mistakes before your code ever runs, instead of blowing up in production at 4pm on a Friday. You’ll come to appreciate it.
When Should You Actually Use Apex?
This is the question that actually matters, and it’s part judgement call, part hard rule.
There are basically two situations that justify writing Apex:
1. The point and click tools genuinely can’t do it. You’ve looked at Flow, at validation rules, at formula fields, at everything declarative, and none of it supports what your users actually need. Fine. Write code.
2. Your org has scaled past what declarative tools handle gracefully. My rough rule of thumb is somewhere around the 500 user mark. Past that, the sheer transaction volume can start causing problems that Apex handles far better.
Notice what’s not on that list: “because writing code is more fun than building a Flow.” Every line of Apex you write is a line somebody has to test, maintain, and eventually understand at 2am during an incident. Declarative solutions don’t need test coverage. Code does.
Which leads to something important: you need to know the admin side of the platform properly. Objects, fields, validation rules, Flow, permission sets, all of it. Not because you’ll build everything with clicks, but because you can’t make a good call about when to use code if you don’t know what clicks are capable of. The best Salesforce developers I know are all excellent admins first.
What’s Next
So: Apex is a Java-flavoured language that only runs on Salesforce, it makes you declare your types, it’s built around objects and methods, and you reach for it when clicks run out of road.
One quick note before you go. In the video I used the Developer Console to show these examples, purely because it’s already sitting there in your org. I would not suggest actually developing in it. In the next episode we’ll cover what an IDE is and why you want one, and then we’ll get yours set up.
See you next time!
Get Coding With The Force Merch!!
We now have a redbubble store setup so you can buy cool Coding With The Force merchandise! Please check it out! Every purchase goes to supporting the blog and YouTube channel.
Get Shirts Here!
Get Cups, Artwork, Coffee Cups, Bags, Masks and more here!
Check Out More Coding With The Force Stuff!
If you liked this post make sure to follow us on all our social media outlets to stay as up to date as possible with everything!
Youtube
Patreon
Github
Facebook
Twitter
Instagram
Salesforce Development Books I Recommend
Advanced Apex Programming
Salesforce Lightning Platform Enterprise Architecture
Mastering Salesforce DevOps
Good Non-SF Specific Development Books:
Clean Code
Clean Architecture
