Pull or Push, What do you like?
Posted by Vikas Hazrati on Thursday, June 4, 2009
There is enough confusion and debate about what is the best model for publishing from a CMS based system. Some advocate the pull model and others the push model based on the ability to scale and be more reliable.
Let us see the pros and cons of these
Pull
- Suited for highly dynamic content
- Suitable for situations in which you want to feed content based on personlization.
- Pull CMS must be used with caching for ensuring faster reads and content independence.
- Can feed data on demand and does not need time based or trigger based push mechanism
Push
- Content Independence – if the CMS engine or database is unavailable the site could be down but with push, users would not know
- Pull CMS with it’s server side scripting language and database requirements could place a higher load on a server than a Push CMS, at least during heavy usage hence Push would be useful for static content with a lot of reads.
- Is server independent, it can push a set of HTML files in a web server independent format for consumption
- Should have a schedule based or trigger based push mechanism
Theoretically, one can achieve push benefits by using pull+caching and hence all the benefits and dynamicity of pull come along with it.
Any page with the need of frequent updates such as real time statistics, user comments, automated relevant links and a host of other things would become stale pictures of the “baking” moment in a push environment such as described.
Joe said
Even though we’re internally dependent on a push CMS, we’re starting the transition to a pull CMS.
For the most part, most CMS needs are about providing standard web-browser content (be it dynamic or static) and an interactive user experience. This can be done with either a push or pull CMS. But the old arguments for a push CMS (wanting to place the burden of transform on the CMS server so it is done once) is not as big of a deal now that caching technology is so much farther along. Also people are less interested in XML and transforms than they once were, and more interested in a dynamic web where things can change quickly. This is less well-suited for a push CMS.
I think that the push CMS concept will not go away anytime soon (there will still be a need for years to come), but I believe that a dynamic pull-CMS and similar technologies (wikis, etc.) are taking over for content and taking the place formerly occupied by custom web applications.
john said
interesting discussion. major issues for me is that batch or statically published sites suit existing content delivery mechanisms well. they can scale well and make very good use of caching. dynamically published sites are much more taxing in terms of infrastructure (both web/app layer and db layer). though caching can alleviate this, it remains heavier than batch published sites. also most applications dont require dynamic publication (eg. infrequently changing content served for many users). dynamic is good, as stated above, for personalisation, where client side scripting isnt an option, or where presentation is based on a number of filtering or other parameters that they client passes to the webserver in the URL. BUT I see these issues being resolved by having a good static publishing system predominantly with dynamic publishing for certain site aspects like comments or for views on data that need to be served dynamically. javascript or ajax can do this. overall, I think there is business confusion about dynamic versus static publishing with the latter considered to give an inferior experience to the end user. this is untrue but an unfortunate consequence of the labels for these alternative publishing mechanisms.