Comments on “Life above the Service Tier”

I have read Life above the Service Tier a few times now. Its a very good paper, one that really changes your perspective, but I wish it was better. If you work on web applications and you haven’t read this paper I recommend that you go read it now — but do come back.

I agree with the overall reasoning and the conclusion.

So one obvious way to correct the thin client architecture is to implement a true MVC framework on the client side… That means that all “Presentation Flows” must occur within the currently ­loaded web page… So one workable model is the Single Page Application (SPA).

First let me get some minor complaints out of the way.

The paper tries to be fair to REST but it gets some things wrong. The mapping of CRUD verbs on to HTTP methods is as follows:

  • Create is done with PUT or POST depending on the relation between the entity to create and the URI.
  • Retrieve as well as search and find is done with GET. Search should not be done with POST.
  • Update is done with PUT
  • Delete is done with DELETE

It has a definite bias against JSON based on it not having a schema. But there is a proposed JSON Schema and the author seems to have updated his view on this matter. It seems contradictory to me to say REST is valid but XML is the only representation that is acceptable. What would be wrong with microformats in HTML or CSV for example? Any well defined format should be OK — thats the whole point of constrained content types. Using the X in AJAX as justification for using XML shows outdated thinking. Current usage of ajax is not as an acronym but a term referring to an architectural style for web apps leveraging a wide range of technologies.

The description of the POST-Redirect-GET pattern is very good but I don’t agree with the conclusion: “Although ingenious, the POSTRedirectGET pattern is mere bandaid over the fractured web architecture.” I consider the POST-Redirect-GET pattern (I call it redirect after post) to be the way the web is intended to work and I’m still baffled that its use is not wide spread.

The superficial differences between thin and rich clients should be updated. The offline distinction of rich clients starts to go away thanks to Gears and related features of HTML5. The footprint of thin clients is going up as they use more and more JavaScript libraries.

I think the claim that Front Controller is an anti-pattern should be backed up. Give more background on what Front Controller and MVC patterns are and justify why Front Controller is an anti-pattern. Not having this rigor makes it harder to believe the conclusions. The Design Patterns book does not list MVC as a pattern but does note that it is made up of other patterns including Observer, Composite, and Strategy. I think the most important part of MVC is the decoupling of the model and view. The main pattern involved in this separation is Observer. But the Observer pattern, where views get notifications when the data changes, doesn’t work well across the web. So there must be some other benefit to the separation of model and view. This paper describes the benefits in terms of Presentation Flow and Data Interchange separation. Laying the blame on Front Controller doesn’t seem fair. As far as I know Front Controller doesn’t say anything about the combination or separation of model and view. It is simply about combining common precessing in one place and dispatching to command processors for specific processing. It made sense given the state of web app architecture at the time. Perhaps Front Control means Model 2 in the context of this paper. I never did understand how server side framework’s, such as Struts, can claim to be an MVC architecture or more generally I don’t agree that Model 2 is MVC.

The two more fundamental issues I have with the paper are:

  • The insistence on a schema for the model.
  • Too many implementation issues left unanswered.

I’ll discuss these in order.

My background and experience is in creating web applications. Functionality, usability and performance are the most important factors (along with time to market) driving the design. I have not had any direct experience with SOA. One aspect of SOA is loose coupling between systems. The loose coupling motivates a strong contract. In my experience the presentation layer (a.k.a UI) of an application has tight coupling with its model. For this reason I don’t have a problem with the data that flows between the UI and model not having a schema. At some point the underlying data will likely have a schema or some formal description, for example a database schema. Way back when I worked on desktop apps there was the notion of an intermediate model between the view and the underlying data store. Now this intermediate model is delivered as a REST resource and it is in direct support of the presentation layer. It satisfies the needs of the presentation layer — not the other way around. A simple change to the UI can result in a need to rewrite the contract with the data model. The overhead in maintaining the contract must be considered.

So I could be all wrong about this. My experience could be too limited and there are cases where you want a firm contract between the presentation and the data. If so then SOA makes a lot of sense. I’m not trying to say anything negative about SOA. It seems to me that the insistence on schema is more a motivation for SOA than anything else. Without it I would still draw the same conclusion, as others have done, that a single page app (i.e. move the controller to the client) is a good idea. Is the principal of statelessness from REST enough motivation in itself to draw the conclusion that the controller needs to move to the browser?

The paper ends with a list of principals for the SOFEA model and an example but a number of tough issues and details are left out. Some of these issues apply to ajax techniques in general. In the traditional web app architecture you can always choose not to use a particular ajax technique if it causes a problem but when your application architecture requires ajax at a fundamental level these issues must be addressed.

The first two issues are about accessibility. A single page app (SPA) relies on JavaScript. What about users who disable JavaScript or browsers that don’t provide JavaScript. Is it reasonable in this day and age for web apps to require JavaScript or should you try to make your app accessible to as many user agents as possible? What about the principals of unobtrusive JavaScript (UJS), is it easier to apply when the app uses multiple pages (traditional server controlled presentation flow) rather than a single page.

A SPA also makes dynamic changes to the DOM which causes trouble for assistive technologies. Is it a matter of assistive technologies needing to catch up? Do we wait for WAI-ARIA to come to the rescue? If you are designing for the future or your users are on the cutting edge (or you don’t have users with disabilities) then this may be a non issue. If your app has strong accessibility requirements including legacy software support then a SPA is out of the question.

Is this architecture appropriate for all kinds of web apps or not? In which cases does it apply? For example does it apply to web sites. This brings up the old debate about the distinction between web apps and web sites.

Does putting a controller inside a web page break the way the web is supposed to work. There are issues with bookmarking, and the back button that must be addressed.

What if the app is too big to fit in a single page? Sure you can grab bits of the HTML structure as needed but how will this impact search engine spiders?

There are many implementation details to solve in creating a MVC framework in the browser. The paper bemoans the proliferation of web frameworks but this architecture and ajax in general have enough challenges to ensure that there will be an equal or greater number of client side frameworks. How do we keep from making the same mistakes that were made server side? For example some client side libraries for templating are sprouting up and they seem to be making the same lack of model view separation mistake that server side template engines made. In a previous post I asked “Is there a need for a JavaScript implementation of StringTemplate?” I think the answer is a clear yes. However, templating is just one way to get the data back into the view. Another option is directly injecting each data value into the DOM. What are the pros and cons of each method?

Is SPA the only way to move the controller and state to the client? The paper also mentions frames as a potential solution. Would local storage such as Gears work with multiple pages each making a separate request for its data satisfy the principals of SOFEA? The conversational state is kept in local storage. Separating the data from the view and having multiple pages has the disadvantage of increasing the number of requests at least until the view pages get cached. This means it is even more important to give the static view pages a far future expiration date.

Another issue is localization of text strings. In traditional web apps this was done as part of the same templating that merged the data in with the markup. This seemed reasonable at the time but text translation is very different from data access. The application data is likely to change frequently whereas the text translations rarely ever change. Would the principals of SOFEA recommend that text localization be done on the client side as well? As far as I can tell it makes no recommendation in this area. As long as the data and view are separate it shouldn’t care if the translation is done on the server. But running the otherwise static view markup through a template engine just to do text localization seems silly. Why not pre-translate the view and store it on the server?

I’ll stop now before I ware out my question mark key. Wait, one more: How are you solving these issues?

5 thoughts on “Comments on “Life above the Service Tier”

  1. John, saw your comment on the SOFEA email list. I agree that an instance on a specific purpose misses the point of what thin server architecture is trying to accomplish.

    Have you checked out JavaScriptMVC? I’ve solved many of the problems you’ve addressed.

    Kris Zyp recently talked about using rhino as a surrogate browser to provide non-js clients accessibility.

    I’d really like to know what you think about JavaScriptMVC.

    I think there is/should be a difference between web apps and web sites. Web apps are rarely searchable and you can pretty easily demand JS.

  2. Hi! you seems to want to make application such as http://gifteer.com : everything is rendered by the browser, only the dynamic data part is sent from the server in json, localisation too.

    It has been build on top of Archetype (http://archetypejs.org), which is designed for this kind of development (well it’s design for generic browser strcutured js development, but with a particular emphasis on building “one page site”)

  3. Hi John,

    Thanks for your very insightful comments. I would like to discuss these with you further. Could you please email me?

    Regards,
    Ganesh

Comments are closed.