Disadvantages of the Force.com platform [closed]

Answer 1

I guess they are trying to address these issues. At dreamforce they mentioned they we're trying to drop the Governor limits to only 4. I'm not sure what the details are. They have a REST API for early access, and they bought heroku which is a ruby development in the cloud. They split out the database, with database.com so you can do all your web development on and your db calls using database.com.

I guess they are trying to make it as agnostic as possible. But right about now these are all announcements and early access so like their Safe Harbor statements don't purchase on what they say, only on what they currently have.

Answer 2

Here are a few things I can give you after spending a fair bit of time developing on the platform in the last fortnight or so:

1. There's no RESTful API. They have a soap based API that you can call, but there is no way of making true restful calls

2. There's no simple way to take their SObjects and convert them to JSON objects.

3. The visual force pages are ok until you want to customize them and then it's a whole world of pain.

4. Visual force pages need to be bound to SObjects otherwise there's no way to get the standard input fields like the datepicker or select list to work.

5. The eclipse plugin is ok if you want to work by yourself, but if you want to work in a large team with the eclipse plugin forget it. It doesn't handle synchronizing to and from the server, it crashes and it isn't really helpful at all.

6. THERE IS NO DEBUGGER! If you want to debug, it's literally debugged by system.debug statements. This is probably the biggest problem I've found

7. Their "MVC" model isn't really MVC. It's a lot closer to ASP.NET Webforms. Your views are tightly coupled to not only the models but the controllers as well.

8. Storing a large number of documents is not feasible. We need to store over 100gb's of documents and we were quoted some ridiculous figure. We've decided to implement our document storage on amazons S3 infrastructure

9. Even tho the language is java based, it's not java. You can't import any external packages or libraries. Also, the base libraries that are available are severely limited so we've found ourselves implementing a bunch of stuff externally and then exposing those bits as services that are called by force.com

10. You can call external SOAP or REST based services but the message body is limited to 100kb's so it's very restrictive in what you can call.

In all honesty, whilst there are potential benefits to developing on something like the force.com platform, for me, you couldn't use the force.com platform for true enterprise level apps. At best you could write some basic crud style applications but once you move into anything remotely complicated I'd be avoiding it like the plague.

Answer 3

The security model is also very very restrictive... but this isn't the worst part. You can't currently assert whether a user has the ability to perform a particular action.

You can check to see what their role is, but you can't check if that role has permissions to perform the current action.

Even worse is the response from tech support to "try the action and if there's an exception, catch it"