Late May we released our Force.com Sites application for one of our internal companies, Taylor and Francis. The Sites app is part of a larger Salesforce.com project that involves identfifying new book sales opportunities, sending professors inspection copies of requested books and obtaining feedback on what professors intended to do with the books. Professors typically either return the book, buy the book for their own use or (the preferred option) adopt it for their class. The feedback process was originally done via snail mail and could take anywhere from 6-8 weeks to enter the details into Salesforce.com.
When I saw Marc Benioff's announcement at Dreamforce regarding Force.com Sites, I immediately recognized it as the technology that could dramatically cut the feedback time and streamline our manual, paper-based processes. The automated process with Sites would enable the professor to update the same record in Salesforce.com that our internal resources would maintain. I pitched Sites to the business and they eagerly adopted it. In the end, we eliminated the manual entry and cut the feedback time to roughly 3 weeks.
Near the end of the Sites project I was working on the Google App Engine for Java Toolkit and was really starting to get into it. We decided that a good test would be to try and port the Force.com Site to GAE/J. Not only were we interested in the technology but we wanted to see if it would be a viable competitor. There are pros and cons to each technology and neither one is better than the other; just different. Salesforce.com states that the GAE/J is not a competitor to Force.com Sites but a complimentary product. The more talk there is about cloud computing in the industry the better for both Salesforce.com and Google.
Based upon our development, here are some of my observations on both technologies:
Google App Engine for Java
- Develop offline - this is a really nice feature that you miss when developing for Salesforce.com. The ability to be able to work in the car, on the train or in a cave makes GAE/J quite convenient. GAE/J does a nice job of simulating database calls and authentication.
- Compile locally - waiting for Salesforce.com to save my code to the server and compile it can sometimes be a time consuming process.
- Testng framework - one thing that really irks me is the lack of a testing framework with Salesforce.com . It's nice to be able to plug in JUnit to Eclipse for test driven development.
- Deployment - the deployment to Google is virtually a one-click process and is a little faster and smoother than Salesforce.com. One of the main reasons is that Salesforce.com runs your test cases as your code is being deployed while Google assumes that you have already tested locally and doesn't require testing.
- Object access - With Force.com Sites, Salesforce.com locks down access and functionality to some of the standard objects. Since GAE/J utilizes the Partner API you have access to all of the objects based upon your profile.
Force.com Sites
- Data model - With Sites I didn't have to create my own data model. It's easy enough to create POJOs and CRUD code with Java but this was a time saver initially and will be down the road for maintenance.
- Integration - Since we were using Sites natively on the Force.com platform, there was no need to write an integration layer for external access. We also didn't need to write any sort of scheduling framework to move data to and from GAE/J for replication.
- Authentication - Eventhough you can authenticate against Google's infrastructure, utilizing Customer Portal logins seems more straight forward for internal users as contacts are already in Salesforce.com. According to the Sites product manager, they have made the licensing extremely attractive.
- Centralized administration - Users seem to prefer having their applications in one centralized location as this minimizes confusion and training.
- Validation rules - IMHO, this is probably the most attractive feature of Force.com Sites. There are a number of Javascript frameworks that can implement form validation in GAE/J but it seems like double the work to me. When you modify your validation rules in Salesforce.com you need to remember to make those same changes in your GAE/J app and of course re-test. With Sites, the same validation rules fire for internal users and well as external ones.
In the end we came to the conclusion that Force.com Sites was a better fit for this project. However, there are plenty of use cases when we might use GAE/J over Force.com Sites. They are both great technologies but a little half-baked. GAE/J was a little more flexible but the integrated approach of Force.com Sites made for a shorter development cycle.
