Beyond Code

On Frontend Design

The typical web-application (and probably many other server-side applications), naturally divides into a frontend, and a backend. The backend talks to the DB and really only should provide CRUD functionality: Create, Read, Update, Delete. Then there is a frontend, which implements the business rules: it navigates the miscellaneous steps one has to go through to create an order, and so on. All of this is fully server-side code. Quite separate from all this is the actual view-layer, which handles input validation, output formatting, page creation, etc. The view layer will be closely tied to the frontend, but is still conceptually quite separate from it. In particular, there should be no code in the presentation templates.

This is the ideal, which works quite well. There are several related "AntiPatterns", if you will.

One common such antipattern is the failure to distinguish properly between frontend and backend. There is a set phrase that "business logic belongs into the backend". With this in mind, some teams architect a server app which has a view layer and a "backend" - but now the backend no longer just does persistent storage, but also has to provide the code that pulls it all together (business logic). A clear separation of responsibilites works better. Business rules are fluid, therefore frontend code is often so much "glue code", whereas the requirements for backend code (persistent storage) tend to be rock solid. Mixing business logic into the persistent storage access layer also tends to bring formatting issues into the backend: very bad idea!

It's all the old MVC problem all over again. The backend/storage is the M, the presentation layer is the V, but there still needs to be a C, which is the "frontend".

A sub-antipattern of the one above is to identify the user's browser with the "client", or "view". This is wrong. Since there is no behaviour on the browser, it is not really part of the system. Once the response has left the server, it is gone - therefore the entire "View" implementation is server-side. It is surprising, how many project teams have a hard time accepting this.

Another antipattern in this arena has to do with package management. The "backend" (DB access) naturally divides vertically: one module/package for subscriber related stuff, one for orders, one for accounting, ... The frontend, however, is cross-cutting all of these things, it brings them together. Therefore it makes sense to put all the frontend stuff into one horizontal module/package.

Sometimes it is attempted to do vertical package management all the way through. Although in some ways this appears to be a very "clean" design, it provides the wrong kind of bundling: one has (say) subscriber-related DB stuff and subscriber-related JSP (or other view-component) stuff in one package. Furthermore, the frontend is no longer separate from the rest of the project, and it is therefore even harder to replace it, should one switch view layer toolkits. Finally, it is inconvenient during development to have the code separated into so many individual packages.