Apex Recipes by Salesforce
I am excited about the recent announcement of Apex recipes by Salesforce. Apex is every developer’s tool to create magic with Salesforce for a long time now. Despite the many features introduced in it’s “no code” counterparts incl. Flows, Workflows, et al., Apex continues to reign supreme when it comes to implementing features of a modern app.
While Apex is all powerful and useful, it had humble origins. This at least partly should explain why a few design decisions do not make sense in today’s ecosystem.
- Apex allows the creation of more than one trigger on an object
- Bulkification is an essential part to optimise resource consumption, but it isn’t quite built into how anything is written
- Tooling was not quite up to modern standards until recent versions of sfdx
Things have drastically improved in the way salesforce.com is developed and deployed over the last five years. Apex has seen many benefits during that period.
- Consultants and companies are more cognizant of how Apex is created for triggers and reusable classes
- Bulkification is “first-class” citizen in any Apex code 🙂
- Tooling incl. VS Code, linting, static code analysis, and the use of deployment-time tools have “left-shifted” many types of errors
- .. and so on
Of course, there are always room for more improvement. Mainly, more standardisation (& the accompanying commoditisation) of the ways in which Apex is written.
Introduction of Apex recipes is certainly a right step in that direction.
Salesforce.com has been in the enterprise space for decades now and the experience level of teams developing and supporting salesforce.com has greatly varied. The tremendous growth of the last decade also meant thousands of developers jumping on to the salesforce bandwagon, who many times bring their own opinions and understanding/perception of how a piece of functionality should be implemented. The introduction of Apex recipes in the org provides that gold standard of what salesforce.com and the general community view as good implementation practices.
Let me elaborate a bit with an example.
The Trigger Example #
Development teams have evolved how triggers are written over years. Looking back, I call myself a novice on scripting over many months until I decided to “really” study Advanced Apex Programming by Dan Appleman.
Previously, writing better triggers meant -
- Following one object one trigger pattern
- Writing reusable classes
- Developing empathy for teams that used FFLIB
Being lazy in learning professional object oriented programming, I was rather poor in how concepts are mapped to practical code. That, and the fact that Siebel scripting spoilt me to a great degree.
As our salesforce.com projects grew in number, it did not take an expert to view different patterns and how they harmed our overall efficiency. I have seen organisations follow their own standards including the way static analysis rules are written, review guidelines - but none that found universal acceptance.
Now, we can put that debate somewhat on a backburner, install the Apex recipes, and organise our efforts around what the recipes say are the best practices.
- Follow an efficient one-object-one-trigger policy
- Create “all-in-one” trigger class that extends a standard template. Implement all methods or choose to ignore them based on your need
This way of writing code may not be the only way to do things under all circumstances, but do take the argument out of “general purpose” salesforce implementations.
What to do next? #
- See Apex Recipes on Github and get started by installing the recipes in your own org
- See more samples created by Salesforce
Should we stop here? #
Certainly not.
I would love to see -
- The perceived complexity of triggers being removed altogether. It will be great to have the one trigger approach being the standard in new salesforce.com implementations
- Using sfdx to create a standard template for a given object when creating triggers. This is a common pattern in many web development frameworks incl. ASP.NET, NodeJS frameworks like NestJS.
- Remove the need for developer-controlled “bulkification” in triggers - make any DB operations automatically apply those rules 🙂
Or better yet, just have a configurable way of doing everything with a few clicks but without losing development and execution efficiency!