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

Thinking about performance

For Salesforce developers, there are therefore two ways in which we can think about performance:

  • Ensuring that we stay within the governor limits
  • Improving application responsiveness and resource usage

It is important to understand the difference between these two ways of thinking when we deal with performance. In the first instance, our focus is solely on ensuring that we have tested the application to ensure that resources throttled by governor limits are not exceeded so that the application can proceed. This would be the default view for testing when developing a trigger on an object that is primarily created record by record in the user interface, for example. We want to ensure that our trigger can handle bulk instances such as when a data load occurs, but our predominant use case is for single record execution. We want to test that we are not going to exceed governor limits in that bulk case, but it is not to enhance the overall solution...