Friday, October 5, 2012

The front-end Moves to the Front Seat

Sometimes the new is old. Back in the 'client-server' days (yes, I'm that old) the main development cost was on the client side. Using the likes of Powerbuilder, Visual Basic or other tools, developers would spend fantastic amounts of time on the front end connecting directly to a database, embedding sql (or proprietary data access api) and creating interactive screens and windows to present and manage data. A three tiered architecture would enhance the database operations with procedures or tirggers to enable server side processing. A brave few created purpose built server API's in C to support a true middle tier between the client and the database. And transaction managers and message oriented middleware were engaged to connect everything together. But even then, the main application logic would fall on the front end.

The web moved us back to a more 'time share' IBM 360/CICS/3270 kind of model (no, I'm not that old) where the client took a back seat and the application logic was all rendered on the server. The browser was the new 'terminal' displaying html pages with form fields and submitting requests to the almighty server to dice up a screen for the response. Though the back end divided into multiple tiers separating application front-end logic (typically a markup language) from business logic (e.g. EJB) from the database and other resources (n-tier), the client (browser) was still basically a dumb terminal. There were some spikes to make the client smarter: applets, flash, etc. and some javascript to enhance the experience with more sophisticated controls. But the browser was still a speed bump to drive processing to the front end.

Today the client is taking the front seat again. JavaScript, HTML5 and powerful and fast browsers have allowed much more sophisticated processing running on the client. New frameworks such as backbone js are allowing developers to build entire applications with a single page html dynamically rendered by javascript where the only interactions to the back end are to manipulate the data not render the screen. The client development is reminiscent of small talk, relying on Model View Controller (MVC) architecture to separate the display from the data and the control. The back end remains basically stateless providing a thin logical access to CRUD operations on data, and implementing business logic to shape, compute or aggregate data and coordinate functionality with other resources and tiers.

No comments: