The Serious Stack Behind Salesforce Developers — Part 2

What Is a Salesforce Application Developer?

In my prior post, I raised the question of why traditional developers should consider Salesforce Developer as a career. I also reviewed some aspects of how Salesforce has evolved over the years into a deeply technical developer platform that requires a community of serious developers.

In this post, I’ll focus on what it means to be a Salesforce Business App Developer and look at the capabilities of the platform that require sophisticated development skills to achieve success  with an architecture that is both declarative and programmatic.  

In short, I'll look at why you as a serious developer will thrive as a Salesforce business app developer, whether you focus on frontend, backend, full-stack, web, mobile, or database technology.  You'll find plenty of opportunities, whether your experience is with object-oriented languages such as Java or C#, or if you have a preference for working with JavaScript and web technologies such as NodeJS and web component frameworks like React or Angular.

Traditional Custom Development Is Hard — Don't Make It Even Harder

Complex business systems contain many moving parts. Whether they are designed to run in a browser, on the desktop, or in a mobile device, nearly all apps require a data store, a user interface, navigation, and actions to invoke behind-the-scenes logic. More complex business systems require reporting and analytics, and global enterprise customers need localization. 

Don't forget security, as all those custom pages and their logic must enforce the rules around who should see what and who should be allowed to interact with which data and processes. You’ll also need some back-office functionality to manage all those security settings.

Business Application Architecture - courtesy of Oracle Inc.

The unfortunate truth is that because many of these elements are ubiquitous to any sophisticated business application, you often end up building them again and again for each project. The customizations specific to your business are where the greatest value resides, and typically where the greatest development effort is required. It's a lot to build and a lot of effort to maintain and enhance going forward.

What if you could leverage a platform that allowed configuration of these common elements—let’s say 80% or more of a system—rapidly, easily, and without any code? What if you could leverage a platform that would allow you to focus your development skills on the more complex and distinct aspects of your application, a platform that even provides the majority of these elements ready to go, right out of the box? Why wouldn’t you? It's important to remember that successful application development is about more than just being successful as a coder, or throwing code at a problem.

Salesforce Is a Platform that Takes Care of the Boring Pieces for You

That's what Salesforce is: a no-code/low-code platform that takes care of those repeatable pieces for you, while still allowing you to customize your application as needed, both declaratively and programmatically. 

How Does the Platform Work?

Let's look at how the key pieces of the Salesforce stack work together for a business app developer. It all begins when a customer is provisioned with an Org (a Salesforce customer instance), which is essentially a dedicated space in the Salesforce cloud. Users with administrator permissions use a browser-based developer environment, known as the Setup area, to configure all facets of their application and its security.

Point and Click Data and Automation 

All database tables in Salesforce (referred to as Salesforce objects) belong to an Org and are automatically provisioned with a basic user interface. Functionality such as navigation, menus, search dialogs, page layouts, list views, detail views, and edit and data entry forms are all automatically created for each entity. In addition, standard data management CRUD (create, read, update, delete) actions and any additional processing logic specific to each entity are also created.

All of this is provided out of the box for a huge collection of pre-existing tables (Salesforce Standard Objects) that typically support the core CRM features such as Account, Contact and Opportunity. Custom tables (Salesforce Custom Objects) can also be created to represent any business entity. Entity schema, data relationships, custom validation rules, and user interface security rules—and much more—are all configured rather than coded.

Lightning Schema Builder

The newer generation of declarative logic tools, Lightning Process Builder and Lightning Flow, allow for extremely sophisticated automation processing and can include the materialization of a built-in user interface or provide the ability to add a custom user interface. Lightning Flow emulates structured programming, albeit with a visual metaphor in its builder.

Lightning Flow Builder : flow example courtesy of Jennifer Lee - Salesforce MVP - https://jenwlee.com

The platform also provides a scalable message bus (Platform Events) that promotes an event-driven architectural model, and it supports both the declarative processing tools as well as programmatic logic.

It is typically when customer functionality exceeds the capabilities of the declarative tools that programming a custom user interface or coding automation logic is needed. A Salesforce developer must know when to step beyond the declarative tools, as well as how to properly design and implement their Apex, Lightning Web Components, or Visualforce pages. Their goal is to effectively and efficiently interface with the declarative metadata driven functionality. Here is where solid development skills, if properly honed, will find high demand.

Beyond Point and Click - Logic

The Apex programming language has been around for well over a decade. While similar in appearance and syntax to Java and C#, it has significant differences. It’s primarily designed first and foremost to process Salesforce data on the Salesforce cloud platform. It is aware of all of your Org's metadata, all of its declarative elements and processes, and all of its data entities.

Apex binds to all data objects and can manage object-, field-, and record-level security. Additionally, it can process inbound email and send outbound email, perform outbound web service calls, and process inbound web service requests from external applications. Apex is able to run asynchronous jobs, be scheduled to run high volume batch data processes, be invoked as a low-code service from a declarative process, and much more.

Both sophisticated and complex, Apex has evolved from a simple stored procedure-like scripting model (Triggers) to a fully object-oriented and rich programming language with classes, inheritance, interfaces, properties, and exception handling. It provides special data types, operators, and built-in system classes that promote efficiently-written code that can safely execute and share scaled resources in a multi-tenant environment. 

While multi-tenant processing constraints (Governor Limits) on Apex have been relaxed significantly over the last few years, the currently evolving serverless runtime container (Salesforce Functions now in beta) will allow developers to write granular microservices in Node.js, Java and other languages. These are expected to allow elastic flow of low or high compute processes in the language of your choice, fully context-aware of your Salesforce Org, with the goal of true elasticity and scalability, simple to invoke from declarative automation.

Beyond Point and Click - User Experience

The Salesforce user interface, whether Classic or Lightning, is also automatically materialized at runtime by the platform architecture.

The original page-centric web application architecture (Salesforce Classic) that still allows for custom pages built with a proprietary markup language (Visualforce) has been augmented with a standards-based, open source, HTML/CSS, and modular Javascript (ES7) web component framework model (Lightning Web Components).  

The architecture continues to materialize a broad set of standard components as before, but now developers can augment pages with custom-configured or custom-created components, using the same web component framework that supports the platform (Salesforce Lightning.)  Developers can also augment built-in object or global level actions, and can configure them to invoke custom Lightning Components supporting Apex and JavaScript client-side custom functionality.

Everything a customer configures for their org’s UI that presents in a desktop web browser is also automatically configured at a baseline-level to render in the Salesforce mobile app that runs on mobile devices of all form factors. Additional no-code configuration can customize both appearance and behavior, and alternative responsive UI and functionality can be added by coding Lightning Web Components which are based on modern web standards and modular JavaScript. 

Your custom components can tap into the powerful standard component library and leverage all of the same secure data services. They can also be added to any Lightning application or record page, following a similar low-code development pattern to build a powerful user experience. You can even build applications off-platform using the open source version of the Lightning Web Component framework, whether or not they integrate with any Salesforce data or logic.

Developer Experience - Tools and Process 

Even teams of just one or two developers need tooling and support for robust development and Application Lifecycle Management (ALM). In the early days, building Apex, Visualforce, or any other metadata components required the use of the popular and openly available Eclipse IDE. Salesforce provided a free plugin (the Force.com IDE), allowing a developer to create, modify, and deploy their metadata files using the Salesforce Metadata API. As Salesforce built out their APIs to better support developer tooling, other third-party IDE products also evolved. While functional, the early Salesforce developer experience was on the whole...well, let's just say...suboptimal compared to more traditional developer practices. 

Fast forward to 2020, and the newer Salesforce Developer Experience (SFDX) is now a collection of modern tools and standard practices supporting both development and DevOps. There are tons of built-in options, all managed with an extensible Command Line Interface (CLI) and a variety of Git-enabled free and third-party IDEs providing developers with lots of tooling choices. The currently recommended IDE is the free and lightweight Visual Studio Code from Microsoft, along with an ever-growing collection of supporting extensions. Many are built by Salesforce, others by community. You can build them, too, with TypeScript (a superset of JavaScript.)  

The platform has always provided isolated sandbox environments. Additionally, they've recently introduced ephemeral development environments (Scratch Orgs) that can be spun up rapidly and easily loaded with metadata and mock data content. The flexibility and programmability of the SFDX model has greatly enhanced the Salesforce developer experience and clearly accelerates the development effort.

These same tools support and promote Unit Testing, both server-side for Apex and client-side JEST for Lightning Web Components. They also increase the performance of the deployment and retrieval of metadata, an integral part of the migration process required for programmatic development on the platform.

The Salesforce developer experience only gets better and better, and its speed of evolution has been truly remarkable over the last few years. The downside has primarily become the challenge of keeping up with its rapid changes and enhancements.

Beyond Application Development

Of course, while you can certainly try to restrict your development activities on the platform to coding, Salesforce developers achieve the greatest success by mastering the platform's declarative capabilities. The more skill and expertise gained on how to best integrate programmatic and declarative capabilities, the more valuable you’ll be in the ever expanding Salesforce ecosystem. 

Believe it or not, AppDev is just the beginning. While the platform has so many strengths, no platform should be a closed island, and the Salesforce Platform is no exception. Things get really interesting when Salesforce applications need to integrate beyond the system boundary within a broad enterprise system landscape.

What’s Next?

In my next post, I'll provide a high-level overview of the many tools and mechanisms that Salesforce provides to leverage their open architecture in an integrated enterprise system landscape. I’ll show that while many of these mechanisms are indeed configurable without code, the role of a Salesforce Integration Architect greatly benefits from deep knowledge of the general declarative platform, the programmatic platform, open standards around identity and security, plus technical experience within the various domains needing to be integrated. I hope you’ll continue to join me on this Salesforce Developer Journey. 

Published with permission from Don Robins.