Book Image

Mastering Apex Programming

By : Paul Battisson
5 (1)
Book Image

Mastering Apex Programming

5 (1)
By: Paul Battisson

Overview of this book

As applications built on the Salesforce platform are now a key part of many organizations, developers are shifting focus to Apex, Salesforce’s proprietary programming language. As a Salesforce developer, it is important to understand the range of tools at your disposal, how and when to use them, and best practices for working with Apex. Mastering Apex Programming will help you explore the advanced features of Apex programming and guide you in delivering robust solutions that scale. This book starts by taking you through common Apex mistakes, debugging, exception handling, and testing. You'll then discover different asynchronous Apex programming options and develop custom Apex REST web services. The book shows you how to define and utilize Batch Apex, Queueable Apex, and Scheduled Apex using common scenarios before teaching you how to define, publish, and consume platform events and RESTful endpoints with Apex. Finally, you'll learn how to profile and improve the performance of your Apex application, including architecture trade-offs. With code examples used to facilitate discussion throughout, by the end of the book, you'll have developed the skills needed to build robust and scalable applications in Apex.
Table of Contents (21 chapters)
1
Section 1 – Triggers, Testing, and Security
8
Section 2 – Asynchronous Apex and Apex REST
15
Section 3 – Apex Performance

Understanding when to make some of these improvements

It should be fairly obvious from reading through this chapter that for every improvement we make for one governor-constrained resource, we negatively impact another governor restrained resource. A prime example is that without for loops, we were able to dramatically improve CPU time usage, but also increased our heap size usage. So when should we make these improvements and implement some of the items we have seen?

The short answer is it depends. I would strongly suggest you avoid blanket implementation of all these improvements as they often clash and it will not typically lead to an optimal solution. The correct thing to do is to write your code with these options in mind and implement these improvements as necessary after testing or during development when it is obvious.

Using the for loops as an example, when coding day to day, I tend to use standard SOQL for loops as they are more readable and it is a nice piece of syntactical...