Force.com vs OS - Complexity of Web App Platforms

I’ve been working with the Force.com platform for quite a while now. I’ve been working on the platform for so long that it seems I’ve forgotten about the state of app development before Force.com. However, since I’ve shifted gears and taken some responsibility for maintaining some of our Java web apps, the world of traditional web app development, and all the responsibilities and details that accompany it, have landed on my plate. Due to this change, I’ve reached a viewpoint from which I can see some of the benefits of working on a platform like Force.com.

The first difference between traditional web app development and Force.com development is the web app server layer. When developing Force.com applications, I never had to worry about setting up a web app server managing environment settings. I never had to debug connection problems with an http server, servlet container, or frameworks and database persistence layers. Using an OS as a web app platform can be quite complex because you are responsible for the http server layer. I have to say that it is quite nice to be free to have a copy of the entire web app software stack locally for your own testing and development purposes. Having your own copy gives you a stable environment in which to code, so you don’t have to worry about other people changing your app’s environment. This capability has its downsides, however, since you are also responsible for maintaining and debugging this web app server and ensuring its configuration. Many hours hours are spent to install the software, configure it, and learn its nuances when it requires debugging.

Another major difference between traditional web app development and Force.com development is the database layer. Force.com has an Apex class for each database object, a standard, simple persistence framework. Other persistence frameworks offer a varying degree of simplicity, which is nice, but you may still be responsible for its configuration and updating objects mappings when the database schema changes. I’ve never had to think about a persistence layer when working on the Force.com platform, which, in hindsight, is pretty amazing.

One final difference that I’d like to reflect on is the database schema. Creating copies of a Force.com database is pretty simple if you are just creating sandboxes for development. You simply push the ‘make a sandbox’ button. Creating copies of a traditional SQL database schema, however, requires a bit more work. Setting up a traditional SQL database requires you to create and maintain a “migration” file, which is used to recreate the production database from scratch. Another “migration step” must be added to this migration file each time the production database schema is modified. While not terribly difficult, it is an extra step that is liable for bugs due to human error.

To finish this reflection, while OS-level web applications are certainly more powerful and flexible than Force.com applications, they are a bit more difficult to setup, write, and maintain. Why are they more difficult to maintain? Complexity. OS-level web apps are complex. Simplicity is a component of maintainability, and OS-level web applications are just not simple. They are complex because they are composed of more parts. Often, these parts have a steep learning curve due to the various languages and architectures they utilize, and a part-time developer may not be able to efficiently maintain them.

Posted in: Salesforce, Software Maintenance

Similar Posts

6 Ways to Make the Most of Salesforce Marketing Cloud

Lindsay Satrom

5 Reasons to Get Excited for Dreamforce 2015

Heidi Haaven

What’s Coming Next with Machine Data

Nazia Zaman