When explaining Salesforce.com and the Force.com platform, I’m often asked the seemingly-simple question “what language do you code in”? Typically, my first response is “it depends”, which tends to garner confused looks from the audience. But, if you’re a developer working with Force.com, you know this question is not so straightforward, especially in the past year or so.
To elaborate on “it depends”, I think it’s best to explain the different ways a developer can interact with Force.com.
Option #1: External Apps: The Web Services API
The Force.com Web Services API is the longest-standing mechanism for writing code that interacts with a Salesforce org. A SOAP-based version of the API was its first manifestation and that continues to exist today. A REST-based version became available recently and is arguably more-efficient and easier to work with.
The API is intended for use in applications managed outside of a Salesforce org. This can include web, mobile, or desktop apps as well as lower-level services, scripts or batch jobs.
Because it’s consumable as SOAP or REST, you can use any programming language you want to build an app with the Force.com Web Services API. It’s very powerful and lets you access and interact with the platform at many layers, from basic data input and querying to reviewing and modifying the metadata (aka schema) of an org. If you need to build an app to solve a business problem, the API should suit you just fine.
Option #2: Native Apps: Apex and Visualforce
About four years ago (I think), Salesforce introduced Apex and Visualforce as part of their “development-as-a-service” initiative. Apex is Salesforce’s native programming language and Visualforce is Salesforce’s native component-based web page rendering engine. By “native”, I mean that Apex and Visualforce can be written and saved into a Salesforce org and the platform will execute the code and generate a web page based on the respective Apex and Visualforce that is saved, just like an Apache or IIS web server.
Apex is an object-oriented programming language. It looks a lot like C# or Java, but Apex is its own dialect (you can’t just copy-and-paste code from either of these languages and expect it to work). I often compare Apex to the System.Web and System.Net libraries of C# (or the correlating java libraries, which I have forgotten) – Apex is a somewhat stripped-down language when compared to C# or Java, which is intentional, as it focuses on querying and manipulating data in a Salesforce org
and making callouts to external services for data integration.
Apex supports everything you would expect in an object-oriented language, including classes, methods, interfaces, and inheritance. It supports all the data types you would expect (Strings, Integers, Arrays, Maps) and it helps speed up development by exposing any object in a Salesforce org as a bona fide class – if you add a new field to the Account object called “Favorite Color”, you automatically get a new “Favorite_Color__c” property on the the Apex Account class. Finally, Apex classes can be exposed to the standard Force.com API (think “webMethod” in .NET), allowing sophisticated processes to be exposed without having to replicate them with the more basic commands in the API.
Visualforce is similar to ASP.NET: it has components that are represented as tags in your markup. These components take parameters and ultimately render data. Visualforce pages can reference Apex classes as that page’s “controller”, allowing developers to create completely custom user interfaces and backend business processes.
Because Apex and Visualforce run natively on the Force.com platform, they have the benefit of not requiring any additional infrastructure to support them. Compare that to our Option #1 approaches of working with the API: any language that consumes the Force.com API needs a server or device to run on.
Which brings us to our final option…
Option #3: Heroku
Heroku is not a programming language. Heroku is an application delivery platform (and a company of the same name). Heroku was acquired by Salesforce.com about a year ago.
So what the heck does it have to do with programming languages?
Remember Option #1? All those external apps need a place to live in order to run (traditionally and typically, a web server). In “the old days”, this meant finding a reliable hosting provider, buying or leasing a server, configuration a slew of software to run on that server, installing your application on the server, then maintaining and upgrading that server into eternity.
Just like the Force.com platform, Heroku is a true cloud-based environment. The concept of a “server” is abstracted away from end users so there’s no need to worry about the administration drudgeries anymore. But unlike the Force.com platform, which can only run apps written in Apex and Visualforce, Heroku can run apps written any number of programming languages, including Java, Ruby, and Python (but not .NET, and probably never, ever, ever .NET). So, you can take that Ruby on Rails web app you just built that connects to Salesforce with the REST API, push it up to Heroku, click a few buttons (literally, it’s almost too simple) and have your web app running on Heroku. Backups are taken care of. On-demand application-scaling is another click or two away. And uptime is essentially gauranteed.
So, while Heroku itself is a platform rather than a programming language, I think it’s important to note as an option and to compare against Option #1 because of all the capability it brings with it to help companies essentially eliminate traditional server infrastructures.
In Conclusion: It Depends
As you can see, you can interact with the Force.com platform with just about any programming language. Apex and Visualforce are the platform’s native tools to add to your belt. As a web developer, I’ve run the gamut of languages, using PHP, .NET (web, desktop, and Windows Service), Java, Ruby, and Apex to build apps of all shapes and sizes. If you use Apex and Visualforce, your infrastructure is taken care of via the platform. For other languages, Heroku can help out in the same way – not having to deal with server infrastructure means I can focus on writing code to solve business problems.
If you’ve got specific questions around choosing a language or working with the Force.com platform or Heroku, please don’t hesitate to ask!
