Heroku1 was announced a couple of weeks ago at Dreamforce but was overshadowed by the Salesforce1 fanfare. Salesforce1 is awesome but, I think Heroku1 is just as important, if not more, as it will open the platform up to new developers and new ways to develop apps for Force.com.
Let me start out by saying we love Heroku at CloudSpokes and Appirio. We were the first platinum partner, built our entire CloudSpokes platform on it (Heroku case study) and are currently hosting over 160+ apps on it. A majority of the applications built for CloudSpokes challenges are done on Heroku not be cause we mandate it but because developers absolutely love the ease, power and flexibility of the platform. So to say the least, we were excited when they announced Heroku1.
Heroku announced Force.com client libraries for Ruby and Node.js, force.rb and force.js respectively. There's an interesting backstory to these two libraries as they were both started by the community. The Ruby restforce gem was forked and became force.rb and the Node.js nforce package was forked and became force.js.
When Salesforce purchased Heroku a couple of years ago they engaged PivotalLabs (now Pivotal) to build the databasedtocom Ruby gem as part of their community outreach. The gem had some serious limitations so, being community driven, people submitted issues and pull requests. Shortly after the gem's release, PivotalLabs was purchased by EMC and the main developer, Danny Burkes, went MIA. Ruby developers were becoming quite irritated and this didn't look good for Heroku (it's part of their repo!) as it looked like they were ignoring the library. No issues were getting fixed and pull requests were hanging in limbo. We ran some challenges at CloudSpokes to fix issues but realized that the problems were too numerous. About a year later, one of the committers, Eric Holmes, started working on a new restforce gem as "...a lighter weight alternative to the databasedotcom gem that offers greater flexibility and more advanced functionality." We quickly switched to the new restforce gem and use it in many production applications. Eric is very responsive and has added some great functionality. We are extremely happy with it.
Force.js is a much easier story as it was born out of Kevin O'Hara's love of Salesforce and everything JavaScript. I've committed a little to the library (a tiny bit) and we have a number of production applications running with it at CloudSpokes and Appirio. Saying that we are very happy with the library is an understatement. This is our go-to library.
What makes the announcement of these libraries so important is that Jesper Jorgensen stood on the stage during the Developer Keynote and stated that Salesforce would officially support these libraries. This should give the developer community the confidence that, unlike the databasedotcom gem, Heroku will put some development resources into the libraries. I do have a couple of concerns as they haven't stated how they will support these libraries and if the will only be supporting their forks. Will their changes also be submitted to the upstream nforce and restforce libraries or will they develop their forks independently? The latter would severely tarnish the community spirit in which these libraries were developed and all the hard work that's been done so far.
Heroku also released a command line tool called the Force.com CLI for those of us that prefer the command prompt to a browser. I actually got a sneak peek at this a couple of months ago from Quinton Wall and if you are a subscriber to my Force.com Weekly newsletter, you would have seen a sneak peak back in November.
Wade Wegner has an awesome overview but the scripting possibilities are virtually endless. Imagine being able to cURL a REST URL for an Account record, use jq to interrogate the returned JSON and then create an Opportunity for that Account. All without opening a browser! Brilliant!
So I left the cornerstone of Heroku1 for last: Heroku Connect. First of all, what is Heroku Connect? In a nutshell, it is a service that syncs data from Salesforce into Heroku Postgres (or MySQL on Amazon) automatically, handling many of the common issues of using an API such as local caching and conflict resolution. Why is this so important? Since many of the development languages that run on Heroku are heavily optimized for SQL databases, working with the Salesforce APIs can be somewhat of a challenge even when using restforce and nforce. Using Heroku Connect, developers can used their familiar workflows. Their reads and writes are straight to the database using Mongoose or ActiveRecord, they can write mocha and rspec tests using the same patterns they are used to and leverage all the #awesomesause of Postgres (fork, follow, share). These changes are propagated to Salesforce in the background and the developer really doesn't need to know much about the details.
The CloudSpokes team got a demo of Heroku Connect (originally Cloudconnect) at Dreamforce 2012 by Adam Gross and started piloting the service last summer. We've been using it in production for nearly 6 months now are are really happy with it. It makes building an API with Force.com on Heroku sooo much easier. Since the entire Cloudconnect team is moving to Heroku, we are excited to see how the service evolves. I'm sure they have a lot of backlog ideas, but a couple of things I would like to see is perhaps the use of the Force.com Streaming API and some object level security implementations. Currently the service polls Salesforce for changes to records. Not sure if it's possible, but it may be nice to speed up this process by using PushTopics to notify the services of new or modified records. Also, an issue we faced was due to the sharing model we always read from Salesforce for objects that have a private sharing model to determine if a user has access. It would be nice to bake this into the services somehow. My $.02.
I think Heroku1 is off to a good start with these new features but I'd still love to see some tighter integration between Heroku and Force.com.
