This article is the first part of two: read the conclusion.
During my many years as a Web developer, I’ve worked with a variety of different technologies, languages, applications, and backends, all stacked in many different ways. There are stacks that are similar to each other, and some that are custom made for a certain application. The later is always a challenge, as rarely any other one walked down the same path and reported their findings.
My boss at work loves Salesforce. He wants Salesforce to provide data storage and access for anything he makes people work on. So, to no surprise, he would like our company’s most important project, a Web application built using Ruby on Rails, to use Salesforce’s Database.com for the data. In fact, he would like nothing less than to get rid of the model layer in Ruby on Rails and have it entirely replaced by something that exclusively uses Database.com. At the moment, we’re merely exporting reports from our data on Salesforce into CSV files to importing them after into our application’s PostgreSQL database. He doesn’t like that. I’d settle for syncing via API, but he doesn’t like that either.
So, this is my challenge at this time.
Salesforce vs. Database.com
As a beginner to Salesforce’s systems, it was hard for me to grasp the difference between Salesforce and Database.com. My data input colleagues are entering all the data on Salesforce, which is entirely accessible via API.
Sounds the same than Database.com to me! Or at least, it did. Here are the key differences I’ve grasped so far:
- Salesforce.com provides an easy way for users to create tables, with a Web application to let them input data and generate reports.
- Force.com provides a way for developers to build cloud-based applications written in Apex on top of their systems, with custom forms.
- Database.com lets developers use any service and any language to access and validate data stored at Salesforce via API.
I found a few options to facilitate the interaction between Ruby on Rails 3 and Salesforce’s Database.com:
- On GitHub, there is activerecord-activesalesforce-adapter gem made for Rails 2, and someone forked it and updated it for Rails 3. The gem plugs into Rails to work on top of ActiveRecord, letting developers use all the resources available in the model layer of Rails, but its support is fragmented and uncertain.
- Heroku, a hosting company owned by Salesforce, has an officially-supported gem available, databasedotcom. It replaces ActiveRecord instead of working on top of it, requiring developers to use Database.com not only for data storage and access, but also for validation and model logic. Code will likely need to be rewritten from Ruby to Apex in this case.
- A foreign-data wrapper for PostgreSQL, allowing applications connecting to the database to appear like a normal PostgreSQL, while the data is actually accessed and stored remotely at Salesforce. I am not certain if performing the move from local database to a remote one should be done at the database layer or if it’s best to do it at the application layer. As I’m more versed in application development with Rails than database administration, I chose to do it in the later.
Although each solution has different strong pros and cons, I thought it was best to go with the databasedotcom gem, since it’s the only one officially supported by one of the companies owned by Salesforce.
The adventure begins…
While working on a proof concept to see if switching from ActiveRecord to Database.com can be done, I stumbled upon problems, yet there are some times I found it more advantageous to use Database.com’s API, especially when it comes to searching.
I asked for advice on Metafilter, but there were no replies. After detailing my problem on Salesforce’s forum for developers (free Salesforce account required to access the page), I obtained a few answers. Something tells me this can get tough.
Details to come as I walk up the road. To be continued…