Scale Salesforce Apps Using Microservices on Heroku
This is the eighth article documenting what I’ve learned from a series of 13 Trailhead Live video sessions on Modern App Development on Salesforce and Heroku. In these articles, we’re focusing on how to combine Salesforce with Heroku to build an “eCars” app—a sales and service application for a fictitious electric car company (“Pulsar”) that allows users to customize and buy cars, service techs to view live diagnostic info from the car, and more. In case you missed my previous article, you can find the link here.
Just as a quick reminder: I’ve been following this Trailhead Live video series to brush up and stay current on the latest app development trends on these platforms that are key for my career and business. I’ll be sharing each step for building the app, what I’ve learned, and my thoughts from each session. These series reviews are both for my own edification as well as for others who might benefit from this content.
The Trailhead Live sessions and schedule can be found here:
The Trailhead Live sessions I’m writing about can also be found at the links below:
Last time we explored ways to automate back-end processes on Salesforce using Flows and APEX and created several automations for our eCars app using Record-Triggered Flows and an APEX trigger. This time we are focusing entirely on how Heroku apps and microservices can help our Salesforce app scale for high-volume use cases.
Setting Up the App and Scratch Org via Github
The eCars app Salesforce and Heroku code are available on Github at the following URL:
Go to the apps->ecars-services directory for the specific Heroku services code for this session. The readme section in the directory contains useful information for deploying to Heroku.
To get things set up we’ll need to deploy the Salesforce application to a Salesforce scratch org as well as the Heroku apps to the Heroku platform. If you are jumping into the middle of this series and have not yet set up your scratch org, it would be a good idea to go back to the first article in this series to review how to set up scratch orgs and your Salesforce dev hub as well as sign up for a free developer account on Heroku.
To get a high-level idea of the architecture of the app, the following slide details how Sales Cloud and the Car Order Configurator will be interacting with the Heroku app and its microservices.
For deployment, we get two different methods on how to manage this (1) Automated and (2) Manual.
To start, let’s review the steps for Automated Deployment as also listed on the readme section in the Github repo. Julian has created a script (a Node.js program that will make this process easier) to get this up and running in the Salesforce and Heroku platforms. All of the installation pre-reqs, keys, and steps to configure your operating system before we move forward with deployment can be found here.
The automated deployment instructions reminds us of a few things: You must be authenticated in DevHub using the SF CLI and Heroku CLI, and you must have access to the repository in order to clone it:
The output of the script final steps of instructions
The goal of this is to simplify the process for you as much as possible. The final items are “post-deployment steps” to perform after completing the automated deployment. For extra credit, check out the Manual Deployment for further understanding and learning (as well as a place to check out more detailed information should you run into errors during auto-deploy).
Deep Dive into the Node.js code and useful functions/scripts
Exporting the functions as JSON
Requiring them in the ecarsDeploy.js file
We continue to break down the modules and the code that starts the deployment process by function.
Example use of a Promise
Another useful tool is the sed (“stream editor”) Linux command that allows you to replace strings in a file. Our app uses the sed command to access a template and substitute the correct URLs.
This command is extremely powerful because it gives you the ability to use the sed command to quickly modify metadata before pushing it into Salesforce.
The PDF Creation Microservice
A common request for applications like the eCars app would be to generate a PDF document from data collected in the system. In this case, we are going to create a PDF of a car configuration that can then be printed by the sales user for the customer. Creating PDFs is actually a high-cost CPU operation, relatively speaking, so we are going to leverage a Heroku microservice to offload this from Salesforce to Heroku.
Architecture and components between SF and Heroku for PDF generation process
Here’s what we will expect to happen once this is implemented. A potential customer builds a car on the eCars app and submits a request for it. This creates a lead in Salesforce. In Salesforce, on the lead record, we can then access the Web Push Notification (another Heroku microservice) telling the lead their car is ready.
Now let’s say your lead is at the dealership and building a different version of the car. In the Car Configurator, a sales user can walk through the steps of model, color, and interior and can then attach the lead in Salesforce and generate a PDF with the car’s details.
This PDF will be generated in Heroku and come over as an attachment on the files related list on the Lead record in Salesforce:
So how do we do this? First, the configuration information data gets sent from Salesforce to the Heroku microservice. Heroku is using Node.js and a few libraries/modules to achieve this—specifically, Fastify, PDFmake, and JSforce. One of the beauties of Heroku is the ability to combine all of these libraries to build powerful applications for a variety of use cases. Now some descriptions of each library:
Diving first into Fastify, we are using Piscina to help offset the load on the Heroku service as generating PDFs can be an intensive CPU operation. Piscina is a library to help manage something called the “workerThread” to generate the PDF and “downlog” the main thread of the application. This is implemented as a POST route, so we can have an APEX class in Salesforce that makes a callout to that endpoint via a POST method.
Then we have a
PDFGenerator class in the PDFMake library to be able to generate the PDF. This includes the
savePDFtoLead custom function that saves the PDF to the Salesforce lead.
To handle the PDF generated by the PDFMake library, we are receiving our PDF as a buffer and writing it back to Salesforce as a ContentVersion record (basically Salesforce Files) to the Lead record we retrieved in our previous query.
You can move a lot of this around and re-architect it as you see fit. This is one of the powerful things about microservices. Mohith mentions that devs overwhelmingly agree that “services should be as dumb as possible” to avoid creating any dependencies and can exist as the simplest and most atomized version of the service. This allows you to scaffold things up with multiple services and extend things more easily.
For some homework, you’ll want to check out the car-configurator LWC and explore the front end of the eCars app as well as the PDFCreateService APEX class to see how it is implemented to work with the microservice.
And don’t forget to explore the sample app gallery on Github.
In several of my clients’ projects, I was brought in because the internal admin or a previous developer got “stuck” trying to implement a particular requirement that was seemingly impossible to do with Salesforce because there was no declarative solution or way to do something in APEX code. Often in these cases, an external microservice solved the problem.
Once you realize that Salesforce has the capability to make web service callouts to external services, really the sky’s the limit for what can be implemented when you combine Salesforce with microservices. It’s also important to remember that not only can Salesforce make callouts to external services, but external applications can make callouts to a number of Salesforce APIs to allow for bi-directional interactivity between Salesforce and third-party or homegrown applications.
Salesforce has so many APIs, it’s sometimes easy to forget what’s possible
In the next article, we’re going to do some additional work with Salesforce and Heroku microservices in a second part for this topic. Yes, there was too much good stuff to fit into one episode!
If you haven’t already joined the official Chatter group for this series, I certainly recommend you do so. This will give you the full value of the experience and also pose questions and start discussions with the group. Oftentimes, there are valuable discussions and additional references available there such as the slides from the presentation and links to other resources and references.
About me: I’m an 11x certified Salesforce professional who’s been running my own Salesforce consultancy for several years. If you’re curious about my backstory on accidentally turning into a developer and even competing on stage on a quiz show at one of the Salesforce conventions, you can read this article I wrote for the Salesforce blog a few years ago.
Thanks to Jason Sun for his kind permission to publish this article.
Credit: Source link