Bill Appleton - October 18, 2013

There are a number of software systems for generating HTML pages on the server side, including Websphere, Weblogic, JSP, PHP, Python, and Ruby.

But the increasing prevalence of mobile devices has started to chip away at the usefulness of this strategy. The “click, get a page” model works well enough on a desktop browser with a dedicated connection, but on a tablet or phone this is a cumbersome and heavyweight solution. Each page is likely to carry graphics, page layout, scripts, and other elements along with the actual data. This is a lot of content to download for just another screen update, especially with an expensive data plan. Intermittent connectivity is also an issue as mobile applications move between zones or into areas without coverage altogether.

The rich client model has been around a long time, I’ve been working in this area since the late 1990’s, but the mobile revolution has brought this idea into the mainstream of application development. The rise of the native application model on iOS further demonstrated the advantages of being rich. The development of HTML5 was the browser’s way of supporting this model, and as the number of different mobile devices increase the popularity of this approach will grow, especially for enterprise applications.

This big change at the client suggests the need for some corresponding big changes on the server, but where are the ideal platforms for rich client development?

This is exactly the motivation for the DreamFactory Services Platform. A service platform can conduct compressed document exchange transactions with a mobile client and achieve very large reductions in network bandwidth.

Since the services are atomistic and under client control, occasionally connected applications are also possible. Because the interfaces are standards based, many different client environments are supported, including HTML5, native application, and server to server communication.

In the old model all the graphics, logic, and user interface must be generated on the server side. But when we move to a rich client model, there is an opportunity to replace all of that infrastructure with a pre-built and standards-based service platform. Based on our experience building rich client applications, we know that the right palette of services will support a very large number of application scenarios.

Since the services interface talks directly to the database, the speed and performance of the system is maximized. And because there is no need for user experience or graphics generation on the server, this model is much less expensive to deploy on a pay per use cloud server. But the most significant cost savings are in time to market and reduced software development. More about that in the next post.