Jumping into Heroku Development
In this second installment, learn how to combine Heroku and Salesforce to build an "eCars" app including setup, installation, and deployment.
Join the DZone community and get the full member experience.Join For Free
The purpose of this second article is to explain what I’ve learned from a series of 10 Trailhead Live video sessions on Modern App Development on Salesforce and Heroku. In these articles I’m walking you through 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.
As a quick reminder, I’ve been following this series to stay current on the latest app development trends on these platforms, which are key for my career and business. I’ll be sharing step-by-step building the app, what I’ve learned, some of the highlights, and my personal take on some of the content.
In the Last Article…
In the last article, we walked through an overview of the Salesforce and Heroku Platforms and how they can work together. We also did some pre-work to get set up for building the eCars app. So, if you are jumping in at this point, here are the following prerequisites you will need:
- Getting a free Salesforce dev org.
- Installing the Salesforce CLI.
- Installing Git (required for Heroku CLI): I also personally have Github Desktop.
- Installing the Heroku CLI.
- Installing VSCode: I recommend also getting the Salesforce Extension Pack after installing VSCode.)
- Cloning the eCars GitHub repo.
For this article, there is another free account to sign up to start exploring Heroku.
The only catch with the “Free Hobby” version of Heroku is that the dyno will automatically turn off when it’s not in use. There is also a limit of 500 hours of uptime per month on the free tier. It seems pretty fair to me, if they’re going to offer me some free compute resources, it’s only reasonable that they turn off the lights when I’m not actively using the resources.
Diving into Heroku
Let’s start with an introduction to Heroku, all the bells and whistles it comes with, and how to get quickly up to speed with deploying an app on the platform. If you’re not familiar with Heroku, it’s a PaaS solution for quickly creating and deploying apps. With Heroku, the idea is for developers to focus on building their app, and the platform takes care of the infrastructure stuff (DevOps, scaling, environments, and so on).
One of the handy things about Heroku is the Buildpacks you can select and launch right off the bat. I’ve played around with setting up an Amazon EC2 application server from scratch. I’m not afraid to admit that I spent a good two hours sorting through documentation and help articles just to install the right pre-requisites on the instance.
With Heroku, however, you can just pick your programming language and Heroku will quickly create a turnkey process with these Buildpacks to get going with a particular language.
Heroku has 8 main officially-supported languages: Node.js, Ruby, Python, Java, PHP, Go, Scala, and Clojure.
However, there are many community Buildpacks available for other languages and frameworks as well.
Going through the Buildpack for Node.js is super simple. The step-by-step instructions and links to required installed components are straightforward to follow, and I found myself up and running with Node.js in under 30 minutes.
You should also install the current Long-Term Support (LTS) version of Node.js. At the time of this writing, the LTS version is 14.15.1.
Turnkey process and instructions for getting started with Node.js on Heroku
VSCode CLI Exercises and Installing LWC
I mentioned earlier that Node.js would be good cross-training for Lightning Web Components (LWC). In fact, the next step is to actually install LWC using npm, which comes with Node.js installed earlier. Follow the code snippet below:
After following the instructions at the link above on the VSCode command line, and answering three questions about the type of app I wanted to create, npm was quickly on its way to installing all the dependencies for the LWC app. Although I don’t understand what all the installed dependencies mean, I can appreciate all the hard work that went into making the app easy to use.
After a few minutes of installation, the sample LWC app was up and running on my localhost machine on port 3001. At this point, one could continue building and testing the app locally until ready to deploy to Heroku.
Deploying the Local Sample LWC App to Heroku
Now let’s deploy to Heroku. Deploying the app to Heroku is a simple exercise. You only need to know several git commands with some Heroku flavor attached. Heroku is git-based so whatever you’re deploying needs to be under git source control. The commands to then deploy are simple and should be familiar to anyone who has used git commands on a command-line interface:
Create your Heroku app with the desired name.
heroku create [app name]
Commit Something to Git for Deployment
Push the Source to the Main Branch on Remote Heroku Git Server to Deploy
git push heroku main
There are some deeper level items on this topic, such as the Procfile and package.json. These files deal with the application’s dependencies and instruct Heroku on how to build and compile the application. For now, this is perfectly sufficient as I have moved a local application to the remote Heroku host URL to make it accessible on the web.
Dynos, Scaling, and Concluding Thoughts
The session on Heroku involved a deep dive into Heroku’s “dynos” or a unitized computing package required to run a particular app. Without knowing how this all works under the hood, what you need to understand is that Heroku has some easy-to-use scaling features that add scale and power to the application vertically and horizontally to guarantee a certain level of uptime even in the face of spikes in usage.
To scale horizontally, you add MORE dynos to your Heroku application. Doing so can let Heroku route incoming requests across more running instances of your web servers, which improves performance with high traffic situations. Adding more dynos also allows your app to process more tasks in parallel, and handle a higher volume of jobs. There are, however, some cases where scaling horizontally doesn’t help, such as bottlenecks on services and long-running requests. Usually, in these cases, the individual dynos are overloaded so parallel processing doesn’t help.
On the other hand, vertical scaling refers to making each dyno more powerful individually. Upgrading dynos to larger dyno types will provide your app with more memory and CPU resources so that the performance of the individual dynos are improved.
So if you imagine a factory with machines making trinkets, you can improve throughput by adding more machines (horizontal scaling) or by making each machine run faster (vertical scaling).
When I hear stories about a website or server crashing due to a sudden influx of visitors, I often wonder what kind of infrastructure those sites are running on and whether they would have crashed if they were using Heroku.
Ok, so now we’re all set up with Heroku, LWC is installed, and our deployment is ready. In the next article, we’re going to learn about data modeling in Salesforce, set up the data model, then explore the integration between the two platforms by connecting Heroku to the Salesforce data using Heroku Connect.
If you haven’t already, consider joining the official Chatter group for this series. It is a great opportunity to post questions and start discussions with the group.
About the Author
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.
Link to the on-demand session recording.
Thanks to Jason Sun for his kind permission to publish this article!
Published at DZone with permission of Michael Bogan. See the original article here.
Opinions expressed by DZone contributors are their own.