As a Developer Evangelist for Salesforce.com, I've seen an ever-widening demand for the exact kind of material that Andrew brings to the table with this book. While I often get the joy of showing developers new features that are rolling out on Force.com, I am often also asked questions about daily challenges when it comes to leveraging those features and implementing solutions within the ecosystem required by enterprise developer teams. This book will go a long way in providing new reference material specifically for those concerns.
In 2007, I started developing at Salesforce.com, and the landscape looked quite different than it is today. There was no Visualforce. Apex had just launched and lacked many of the interfaces it enjoys now, such as batchable and schedulable. Most custom interfaces were accomplished through extensive amounts of JavaScript embedded in S-Controls, which is a portion of the platform that is no longer supported. Communicating back to the platform could be done via the SOAP API using the AJAX toolkit. If you wanted truly fine-tuned business logic on the server side, you exposed it via a custom SOAP endpoint in Apex.
In 2014, the capabilities of the platform completely eclipse those days. With Standard Controllers, Visualforce provides basic business logic out of the box, without additional code required. For custom processing, a developer is not limited to just a single option, but various routes ranging from extending Visualforce's components library to exposing Apex methods directly to JavaScript—providing the flexibility from the old AJAX toolkit without ever needing to access the scope of the platform APIs. Apex can be scheduled, it can churn through records in the background, and it can be used to create completely custom REST endpoints. Developers now have access to powerful new APIs such as Streaming and Analytics as well as industrial strength identity services.
The platform continues to evolve. At Dreamforce, each year, we announce new tools, features, and functionality to the platform. Last year was Salesforce1 with a new mobile application that would make deploying interfaces to smartphones a simple and integrated process. This coming October, we will deliver new industry-changing innovations.
This pace of technical evolution combined with an ever increasing adoption of Force.com for enterprise applications poses a specific challenge for developers: to continually think of the platform not as just a solution for various use cases, but as a complete ecosystem that uses the platform efficiently. It is no longer sufficient to consider that a given application simply works on the platform; developers need to consider whether their applications are being designed in a way that leverages the correct features and that will co-exist efficiently and well. It takes the ability to view how the platform is being limited from a high level and with a clear direction.
I knew Andrew was the kind of architect with such an ability when we started discussing a new set of articles he was writing based on Martin Fowler's Separation of Concerns and how such design patterns could be used to develop Apex for enterprise solutions. Seven years ago, thinking about Apex in such layers of abstraction was certainly possible—it just wasn't really necessary. With all the potential tools and features in the hands of a Force.com developer now, not considering such concepts is begging for maintenance debt down the road.
Andrew being in a position to write this book should be a surprise to nobody familiar with his company's work. FinancialForce.com has created some of the most robust applications I've seen on Force.com, and as Chief Technical Officer, Andrew has been at the forefront of making them successful.
Hence, I'm delighted to see Andrew writing this book, and that at its core, we can see an expanded version of his previous design pattern articles. Actually, simply a printed copy of those articles would not be a bad addition to an architect's library, but here, we also see a more complete vision of what a developer should know before building applications on the platform that levels off from higher order considerations like interfacing Apex classes together down to the concrete tasks of properly leveraging Source Control software for Force.com.
I'm excited to see this book on my shelf, and hopefully yours—it will help you map out not only this generation of Force.com applications, but to move forward with future ones as well.
Joshua Birk
Salesforce Developer Evangelist
