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.
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.
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?
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?