You're reading from Mastering Apex Programming A developer's guide to learning advanced techniques and best practices for building robust Salesforce applications

Product type Paperback

Published in Nov 2020

Publisher Packt

ISBN-13 9781800200920

Length 368 pages

Edition 1st Edition

Languages

Apex

Tools

Salesforce

Concepts

Enterprise Resource Planning

Author (1):

Paul Battisson

View More author details

Table of Contents (21) Chapters

Preface

1. Section 1 – Triggers, Testing, and Security

2. Chapter 1: Common Apex Mistakes FREE CHAPTER

3. Chapter 2: Debugging Apex

4. Chapter 3: Triggers and Managing Trigger Execution

5. Chapter 4: Exceptions and Exception Handling

6. Chapter 5: Testing Apex Code

7. Chapter 6: Secure Apex Programming

8. Section 2 – Asynchronous Apex and Apex REST

9. Chapter 7: Utilizing Future Methods

10. Chapter 8: Working with Batch Apex

11. Chapter 9: Working with Queueable Apex

12. Chapter 10: Scheduling Apex Jobs

13. Chapter 11: Using Platform Events

14. Chapter 12: Apex REST and Custom Web Services

15. Section 3 – Apex Performance

16. Chapter 13: Performance and the Salesforce Governor Limits

17. Chapter 14: Performance Profiling

18. Chapter 15: Improving Apex Performance

19. Chapter 16: Performance and Application Architectures

20. Other Books You May Enjoy

Leave a review - let other readers know what you think

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...