LifeinTECH

I have spent the last few years designing and building applications on the Salesforce.com App Cloud.

This has been an interesting journey, which started with full-stack MVC Force.com applications, built using Visualforce, Apex and Declarative capabilities. In recent years, the Lighting Component Architecture has gained momentum, however for companies with “legacy” Force.com applications, the migration path can be challenging.

Alongside these challenges, I have always feared the risk of lock-in with Force.com development (we’ve all seen it before with SharePoint, Lotus Notes, etc.) The Lightning Component Architecture makes this slightly less concerning, thanks to the use of the open-source Aura framework, but unfortunately it has gained little traction outside of the Salesforce.com eco-system.

As a result, I have been using the release of Lightning as an opportunity to re-think the architecture of applications built on the App Cloud, with the goal to take greater advantage of Heroku and open community languages / frameworks.

Although Heroku is owned by Salesforce.com, it is a very different platform to Force.com. Thanks to the use of Linux Containers, it provides a far more flexible and portable development environment. In fact, applications built on Heroku can be easily re-deployed to other open platforms (such as Cloud Foundry and/or OpenShift) and now that Heroku natively supports Docker, this process has become even simpler.

With this in mind, I have been evaluating hybrid applications, which aim to combine the best parts of Heroku and Force.com. The hybrid application architecture can be described in three parts:

1. The front-end and application logic are built using open-community languages / frameworks, running in containers on Heroku.

2. Force.com will be utilized (where required) for specific services such as Identity, Data Modelling, Business Process, Workflow, Approvals and Commercial Capabilities (Sales, Service, etc.)

3. Integrations between Heroku and Force.com will occur via RESTful API’s or in specific scenarios via Heroku Connect.

Outlined below are two high-level application patterns, both of which I have built and deployed. The specific use cases are not overly relevant, as the goal is to highlight the hybrid nature of the architecture.

The first pattern is very simple, supporting a generic web application, with content management, identity, persistent storage and a custom workflow (approvals, e-mail, etc.)

The second pattern is more complex, with additional application logic defined as microservices. These services all run on Heroku, leveraging AMQP as a messaging queue. In this scenario, Force.com is also used to enable Service Cloud capabilities.

In both patterns, the front-end and application logic are highly portable, leveraging React and Node.js (JavaScript). As proof, I deployed both patterns to Cloud Foundry and OpenShift, without needing to make any code modifications (I simply updated the environment variables that connect the RESTful endpoints).

Static web assets (text, images, videos) are managed via an API CMS, such as Contentful or Prismic. This enables a truly decoupled architecture, as well as a clear separation of concerns for content authors.

Finally, Force.com is still an important part of both patterns, but positioned as a backing service and only for the things it does best (implemented using declarative development).

Advantages

1. Decoupled Architecture: Ensuring a clear separation of concerns, providing maximum agility when supporting and adding new features.

2. Reduced Lock-in: The use of open-community languages / frameworks running in containers provides maximum portability. The Force.com services are still “sticky”, but only support specific capabilities as part of the overall architecture (instead of the full-stack). This approach dramatically improves my comfort level regarding lock-in, especially if the Force.com services favour declarative development, therefore being fast and simple to setup (or throw away).

3. Scale: Heroku applications can be automatically scaled in real-time, based on the application load. I have personally tested scaling an application on Heroku to eight million users over a 24hour period (which is far beyond any production need that I would have).

4. Developer Talent: As development on Heroku can take advantage of industry trends and standards, such as Node.js and Twelve-Factor App, it will likely be easier to find, attract and retain top developer talent. This is supported by the 2017 Stack Overflow Developer Survey.

5. API-First: This architecture is not dependent on pre-provisioned Force.com user licenses. Instead, users interact via the front-end built on Heroku, with Force.com access happening via the API.

Disadvantages

1. Force.com Prioritization: In my experience, Salesforce.com continue to prioritize full-stack development on Force.com. This is hardly a surprise, as Force.com offers a more compelling commercial model (for Salesforce.com), as well as includes a large existing customer-base with Sales and Service Cloud. They are also still eager to chase the “admin / citizen developers”, however I feel this will become increasingly difficult as they look to embrace true development practices such as Continuous Integration, etc.

2. Technical Limitations: Although Salesforce.com do not inherently discourage or limit a hybrid architecture, they also don’t offer many accelerators (outside of Heroku Connect). My hope is that Salesforce.com invest in an event-driven architecture (EDA) and maybe an API Gateway, which I believe would fully unlock the hybrid architecture, allowing developers to easily take advantage of the business rules, triggers and procedures defined in Force.com.

3. Commercial Model: Salesforce.com continue to favour a user license model for Force.com development. This makes perfect sense for Sales and Service, but is completely useless for application development (where the user base can vary widely per application). API usage limits are also tied to the user license, which could be a deal breaker for a hybrid architecture. I hope Salesforce.com rethink their license model for application development (e.g. App Cloud), offering a consumption model based on Object and/or API usage.

So where does this leave the Lightning Component Architecture?

I am a big advocate of component-based architecture, as well as JavaScript. Therefore, I’m certainly pleased to see Salesforce.com embrace the Lightning Component Architecture. I would always recommend that anyone planning to build full-stack on Force.com should start by looking at Lightning.

However, with the previously defined hybrid architecture, you can still achieve all the advantages of components using something like React, whilst also gaining a lot of flexibility thanks to the rapidly growing open eco-system.

Salesforce.com would likely argue that Lightning has unique advantages, such as tight integration with the broader Salesforce.com eco-system, which would streamline development. Although likely true, I believe that in most cases these advantages can be easily mitigated via the API, with the added benefit of no lock-in.