I’ve been bothered for awhile that when you search for advantages for developing on the Force.com Platform one of the first Google results is a thread on a forum listing many perceived disadvantages from a development perspective. Even worse, because of the rapid development of the platform many of the disadvantages listed are no longer correct. In this post I will discuss both advantages and disadvantages relating to development on the Force.com platform.
Advantages
(1) Quick access to Salesforce’s existing 82,400 company user base ( which has money to spend ) through the AppExchange (only a $300 listing fee).
(2) Piggy back off Salesforce’s powerful existing functionality, including:
- User management and authentication
- Administrative interface
- Reporting and analytics
- Dynamic API
- Toolkits and integrations for other languages and platforms(3) PaaS offering allows you not to worry about server maintenance or architecture
(4) Governor limits and test code coverage enforce some degree of best practice
(5) Security, both because of code review and because of high degree of control on the platform (see #2)
(6) Java-like syntax speeds learning curve for new developers
(7) Native “Visualforce” elements allow quick and easy information output
(8) Active community. Lots of information out there and active participation from Salesforce staff
(9) Object metadata can be leveraged for powerful functionality
(10) Actively under development (Big things underway with VMForce).
Disadvantages
(1) APEX is not a fully featured language
-Lots of things you might wish were there aren’t
- You will have to port them yourself or make outbound webservice calls(2) Hard to know if you will really make money
- Hard to impossible to find revenue numbers for the AppExchange
- Per-user licensing creates a pretty linear margin on license fees (as opposed to potentially exponential on a metered system like GAE or EC2).
- Data based pricing makes it pricy for folks with lots of data(3) Debugging can be extraordinarily slow:
- No real debugger
- Places where you don’t even have a debug log (not enabled, in a managed package, reached the limit, or weird errors that don’t leave an entry).
- Unfixed bugs or quirks on the platform that you wouldn’t expect (i.e. undocumented differences between commandLink and commandButton).(4) Ideaexchange and other reporting tools tend to be admin focused
and geared towards new features, not fixes or better developer tools(5) Governor limits sometimes make sense, but at other times they can be very difficult and prevent what would be best practice. Very easy to get in a place where you are trapped by a governor limit and very hard to know ahead of time whether or not any given practice you will take there (unless you already have a lot of time playing “dodge the governor limit” ). These are doubly a problem when it comes to test coverage.
(6) Developer tools continue to be somewhat lacking (even though the Force.com IDE runs in Eclipse you can’t use many of the Java focused extensions and build time is slow).
Incorrect Criticisms
(1) WRONG: There is no namespacing or packaging.
RIGHT: Namespace and packaging exist but are controlled via metadata (and unfortunately do not allow different folders in the Force.com IDE default view).
(2) WRONG: Security model is restrictive
RIGHT: A restrictive security model can be a robust security model. There are layers of complexity and in this case complexity equals customizability and power.
(3) WRONG: Difficult to convert SObjects to JSONObjects
RIGHT: JSONObject implementation makes this fairly simple.
(4) WRONG: Governor limits are terrible
RIGHT: Governor limits makes sense given the Force.com architecture (although they can be limiting and frustrating at times)
(5) WRONG: Support is poor
RIGHT: It is not realistic to expect excellent free developer support and if you want developer-focused support you should be willing to pay for the Premier offering.
My Recommendations
Do:
There may be some pain, but you should be okay developing small to mid-size apps on the Force.com platform, and you will do even better if you learn some Tips and Tricks and/or minimize coding in APEX (i.e. convert everything to JSON and do your processing in Javascript). I’d also recommend against trying to do anything too creative or with going in with expectations that are too high.
Don’t:
Don’t try to develop an enterprise app of significant size or scope on the platform. Even if the OEM pricing looks attractive, there is a good chance you will end up sinking ever deeper in a quagmire of multiplying unexplained buggy behavior and insurmountable governor limits (note: this recommendation may change with VMForce).
Takeaway
Part of the necessity here is understanding where PaaS is today, and the reality is that while PaaS as a service beyond IaaS, while developing rapidly, is not yet a platform ready for development of large enterprise ready apps. It is fine for extensions of existing technology, but be wary if you try for much more than this. This does not reflect poorly on Salesforce.com as they have been pushing the envelope on what is possible with all the force available to them. There are at the moment very many useful and potentially profitable things that can be done with the platform and if you have the time and resources, I strongly suggest doing them (or at least getting your feet wet while waiting for things to develop further).
Special thanks to Wes Nolte and Alex Sutherland for suggestions and corrections, as well as attendees at the Philadephia Dev Meetup (@botoscloud, @cashion, @matschaffer).
9 comments
Comments feed for this article
August 27, 2010 at 4:11 pm
Mat Schaffer
Nice post man. Thanks for the credit. But I’m gonna have to flag you once again on that JSONObject implementation. The quote() method is straight-up commented out. A malicious user could use this to circumvent security restrictions rather easily and hijack other accounts.
The safer approach seems to be use of JSENCODE in a VF page, but doing so can lead to duplication.
August 27, 2010 at 4:23 pm
d3developer
I think SOQL injection is a much larger concern from the client side than from internal processing, which is all I’m suggesting JSONObject be used for. First of all, in most implementations none the JSONified code is executed except client-side so how could you have a problem? Even if you could bungle the client-side output, I’m not sure how this creates a security risk back on the server-side.
That said, I have my own JsonUtils class which safely encodes everything and in my benchmarks is faster than JSONObject (and also doesn’t go over the script statements governor limit with large datasets). Most of that code is available on Snipplr.
August 30, 2010 at 3:04 pm
Richard
Just on the 2nd point of disadvantages. There is some flexibility on the licensing model as an ISV. Open up the discussion with Salesforce and you’ll find alternatives such as revenue sharing which scale much better. The more non-CRM orientated your product is the better – CRM extensions have less flexibility.
December 8, 2010 at 9:10 pm
Joel Mansford
Joel, excellent, balanced article. My experience of the Salesforce ecosystem is that is disproportionally positive about the platform. By that I mean that there isn’t much balanced criticism out there which unfortunately means that the majority of the platform development seems to be new-feature-marketing-led.
As an ISV governor limits can be extremely difficult to work around as you simply don’t know what the orgs might look like that you’re installing in to and there’s not much documentation (ISV-orientated) to explain it either.
December 10, 2010 at 3:22 am
Kenny McColl
Nice post. I was just about to comment that, while the JSONObject implementation is pretty straightforward, it is pretty slow… but you’ve already mentioned that in the first comment. I’m sure if they incorporated it natively they could tune the performance – the XMLStreamWriter is much faster, for example (in my own unscientific benchmarking)…
Anyway, interesting stuff – will be interesting to see how VMforce, database.com , and to an extent Heroku, change some of this
March 23, 2012 at 12:30 pm
Joel Dietz (@fractastical)
JSONObject is native now, btw. I haven’t done any benchmarking yet though.
December 8, 2011 at 3:47 pm
Understanding Visualforce « Tquila
[...] you are looking for a fuller treatment of the Force.com Platform, I suggest this longer post. Cheers! LD_AddCustomAttr("AdOpt", "1"); LD_AddCustomAttr("Origin", "other"); [...]
March 23, 2012 at 11:35 am
Shawn
Hi. Thanks for this post. I just came across it, but I realize it was written a while back. Do you feel that you’re comments on both sides about the Force still hold true?
We’re at a crossroads in determining what platform is best for a failry custom, enterprise level app. And it also would need to be accessible to our client-base, which could be thousands of users.
March 23, 2012 at 12:29 pm
Joel Dietz (@fractastical)
Yep, I’d say virtually everything still holds. The one thing that has changed and is changing (although many features are still in preview) is that it is increasingly possible to forgo the standard Visualforce/apex way of doing things and write your applications entirely in Javascript. Whether or not the Force.com platform meets your needs exactly (but I am available for consulting if you’d like some help determining).