Ruby on Rails 3 with Salesforce: Conclusion

Rails with Salesforce

Don’t do it.

If you even think about doing it, you’re nuts.

This summarises the conclusion of an article I wrote half a year ago about my attempt to use Salesforce as the primary database for Ruby on Rails.

In details, just before I wrote the previous article, our boss insisted that we use the information we store in a database at Salesforce to run our application made with Ruby on Rails.

I thought he wanted our application to connect to Salesforce only to get the data we need, or to sync a copy of the data present there with our database running on PostgreSQL. But no, he meant all the data should be readable and writable on, and only on, Salesforce.

This meant everything down to the user accounts and the sessions. At that point, we had to replace the entire database abstraction layer with something that would work with Salesforce.

Screenshot of Databasedotcom on GitHub.

We found the closest thing that met our need: the databasedotcom gem for Rails by Heroku. Since Heroku is now owned by Salesforce, they should have something that works seamlessly with their database API and Rails. Right?

I believed they did, but I was only desperate to find anything to help us. Sadly, the gem was poorly maintained and it did not even use the latest version of the API by Salesforce in the time. As I noticed some recent pull requests today, it seems the code is better maintained lately. Or maybe I’m just being hopeful again.

A few months of hard work later, on a separate branch of our application’s code, we came up with something that was workable, but far from being complete. Turns out Salesforce uses special column names and the Salesforce Object Query Language, or SOQL, is far from being on par with the SQL language of many other database systems out there.

As for testing, we did find the vcr gem to be of some use. It allowed us to record remote requests done via API and store their responses in files to commit in our repo. We can reuse them later, to replicate, or “replay”, those requests and responses, even when we don’t have a network connection. This greatly speeds up our tests when they involve remote traffic.

We showed our work, or rather patchwork… Actually, we showed our mess of support for Salesforce crammed into our Rails app to our boss. The application was slower than a snail sliding on glue and it made research papers written on typewriters and sent by mail more efficient.

Needless to say, that project was canned very quick after the presentation, and the boss no longer has any problem with our application using the databasedotcom gem to copy data between Salesforce and PostgreSQL.

In conclusion, to repeat myself, don’t do it.

Ruby on Rails 3 with Salesforce's Database.com

Rails with Salesforce

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.

Options?

Heroku officially supports a gem working with Database.coms API for Ruby on Rails 3.

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…

How To Add a Facebook App to a Facebook Page

Just before February 2012, Facebook removed about pages for Facebook apps in favour of creating “community pages” related to the app manually, from the app’s settings page adjusted by admins and developers.

This also means that Facebook “forgot” to add a link to let you add Facebook apps to Facebook pages.

To do so, you can go to a URL based on your app’s API key:

https://www.facebook.com/add.php?api_key=[api_key]&pages

Otherwise, you can try this tool made by @bryngfors on Twitter:

http://stickybeat.se/addapp/