A Tale of Two Layers to Reduce Front-End Churn

On a recent internal mailing list, a debate occurred on the merits of various MVC frameworks, such as AngularJS and Ember. While I have an opinion on the matter, the debate is indicative that there is (and will be) a high degree of churn in the technologies used to render an application’s user interface, or presentation, layer. This is because the platforms that deliver applications to end-users constantly evolve to improve their capabilities as platforms. That improvement then spurs more change! While connected mobile devices have been on the market for about 15 years, it’s only in the last 7 years (and really in the last 5) that these devices have become serious platforms for enterprise applications. Long gone are days where an application has a 25-year lifespan in largely the same configuration in which it was first developed. That said, MarkLogic is a strategic choice that may insulate you from a large part of this churn by providing a layer upon which to build data services or interfaces – -while leaving the service layer untouched.

MarkLogic’s deep support for REST, which can be thought of as an HTTP-based service layer, allows you to split the application into two pieces. One piece is a service that leverages the scalability of the web (HTTP, clustering, caching, etc.) and provides access to resources or operations on your data. The second piece is the UI through which users experience the application. On many platforms the service providing the data and the representation of the data are often co-located in the same application, leading to tight coupling of the UI and the related components. A change to the UI often requires a change to the whole application and can be costly. Although the UI and services are related, the data and its presentation are more loosely coupled when separating them into distinct concerns. This isn’t just a short-term tactical decision to deliver a single application; this is a strategic decision that can have a positive impact on IT infrastructure over long-time spans. This will reduce some impacts of the technology churn and therefore reduce long-term costs.

Create Reusable Components

Let’s take a traditional JEE (Java enterprise) application, the bread and butter of bespoke enterprise applications, and see how this strategic choice plays out. Legacy JEE applications normally adopt JSP or JSF as front-end layers that directly access components or modules (beans) within those applications. An update to an interface requires updating the JSP or JSF that generates the UI on the server side. It’s only natural, because the beans and presentation are co-located, that they become tightly coupled. Pieces that are tightly coupled tend not to be re-usable; changes to one part tend to ripple through the entire application. Moreover, there will come a time when the standards used to develop the application become so dated that updating the look and feel of the application may require a re-write of the whole application (both UI and business logic), because of this tight coupling. Or even worse, a new technology is introduced and suddenly your entire application needs to be re-written to take advantage of that new platform.

Separate Front-End From Business Logic

In contrast, MarkLogic helps create a strong separation between the front-end and the business logic through actual separation instead of a logical separation that is subject to the vagrancies of developer will. The service with the business logic can be better isolated from changes in the user interface. Some roll their eyes and think of costly SOA and WS-* deployments that failed to live up to the hype. In my humble opinion, WS-* is an example of standards-creep to the point that the implementations crumbled under their own weight. But the principles of SOA as an approach still hold and are borne out by the number of IaaS offerings from companies such as Amazon. Building a world of composable, re-usable services will make you more agile and drive down long-term costs. And MarkLogic is an excellent platform for building REST services. For the foreseeable future, any new platform or technology will be able to leverage REST and HTTP. While SOA was heavy weight, REST is light-weight and used by countless application frameworks and (as importantly) directly accessible from the browser.

MarkLogic provides a comprehensive, high performance REST services layer in the application server itself. It covers not only data access but a variety of management tasks as well. It can be easily extended through custom end points. On many other platforms there are no ‘built in’ services and instead all services are custom. Even if the code is trivial, it is still code you need to write and maintain. Without writing any custom services (although that is simple enough), it is possible to build a very complete application using just the MarkLogic provided services. Combined with MarkLogic’s strong roll based security, it is easier to open these services directly to different front ends (a rich web application, a native Android application, a WPF application, etc.) without the need to build and deploy an application layer between the user interface and the MarkLogic servers.

I don’t profess to know what front-end technologies will drive innovation in the years to come. I do expect to re-tool my skills every couple of years because of the intense rate of change. Maybe thick clients will make a comeback, as most successful mobile applications are “native” as opposed to browser-based applications. Or maybe the mobile web will become capable enough to entirely displace “native” applications. What I do expect is that the underlying infrastructure for REST will be there for the foreseeable future. And from that standpoint, a platform that has adopted REST as intimately as MarkLogic, is a sound platform for IT infrastructure that will survive the churn.