*Movellas - Our [T5.4] Tapestry upgrade experiences* 5.4 is underway and think a lot of users are wondering if or when they can start using it for their applications. New or existing ones. We've upgraded ours to 5.4 and hope our experiences can be helpful for other and also help improving 5.4 towards a GA release.
Large site - tapestry from 2009/10 Initially 5.1.x line, but continuously upgraded up to 5.3.7 Movellas is today 150k registered users and about 1.5M visitors. And hope to grow much larger :-) As everywhere else in the industry - mobile traffic continues to grow. Website is not mobile optimized, but have a separate version for that. As well as a number of apps in the appstores. Creating a responsive/adaptive experience on website is something we wanted to get started, and after experimenting with 5.4.22 - we felt comfortable enough about upgrading to an alpha. Here are some of the experiences and challenges we’ve faced. General process: * Remove thirdparty modules incompatible or redundant for 5.4 * Set JQuery as infrastructure provider * Migrate all(still valid) prototype scripts to JQuery * Keep a checklist of pages and components to verify (can get from log or T5Dashboard) * On a page by page (and component) basis from checklist - update and verify all In general the migration took a lot of effort, but was not complicated. For javascript and RequireJS some difficulties occurred, especially with thirdparty js plugins/modules, but more on that below. Thirdparty tapestry modules - tapestry-jquery. Mostly for jquery and jqueryui support. Have made alternative versions of the components used from tapestry-jquery - t5conduit (less & coffeescript). Used tapestry-webresources. Mostly effortless - tapestry-yuicompressor -> tapestry-webresources RequireJs Never used that before, so was also a (good) learning experience. Dependency management and injection of modules is great. Combine files We do have a lot of scripts which we’ve previously combined in stacks - and cannot (easily) be done in 5.4.22. New in 5.4.24. Howard have just announced possibility to add modules to stacks - YAY. Contribute to configuration It is very common that thirdparty js modules also rely on RequireJs. Therefore a way to configure/contribute to requirejs config is needed in tapestry, especially paths. Would be great if it could be in stack/page/component level so that the config is not global. Have created a JIRA so please vote: https://issues.apache.org/jira/browse/TAP5-2196 Underway: Thiago are working on it so think we’ll have a solution soon. YAY. CDN / CloudFront As a worldwide service we want to serve the assets as quickly as possible. With AWS CloudFront we can configure the tapestry app as origin and the assets will be ‘lazily’ populated to the edges around the world. This is simple and effective and have served us well. To enable this we’ve made a AssetPathConverter service which prepend the CloudFront domain. In 5.4 a few things changed that made it more difficult to support, at least in our case - and have not yet been able to run reliably like in 5.3.x- Expanded URLS in css Now urls in css is expanded (which is good). However the AssetPathConverter is eventually invoked and the full url with scheme and domain is inserted. This is bad news for us for us as we do non atomic updates and rely on sticky sessions while upgrading. After that we re-enable cloudfront ‘on the fly’. This causes the checksums to mismatch and the site is broken. I’ve made a workable hack to set a thread/request attribute once a css is processed to avoid adding the full url and keep it relative to the css domain. (See JIRA for more details: https://issues.apache.org/jira/browse/TAP5-2201) I’d like to have another pipeline for resolving css resources or adding/knowing that it’s from inside a css so that we have better control. Asset and module versioning This have now been removed as it’s relying on checksums. However I do like the extra control of versioning so I can easily force renewal of all assets. Luckily it’s an easy way to bring this back by configuring the “Asset path Prefix”. Great. Module cache response headers Requirejs modules have the following response headers Cache-Control:max-age=0, must-revalidate I think this means that they have to be checked at origin for every request - and something I’d like to avoid as a global service. With module versioning back in place I’d like to cache these aggressively for a long period of time - just like the other assets. I’ve adviced ResourceStreamer in order to cache js modules. See JIRA if interested: https://issues.apache.org/jira/browse/TAP5-2201 Other challenges As js is loaded and executed later, quite a bit of ajax functionality might not have been bootstrapped and not working immediately on a rendered page. It’s not really tapestry related I suppose, but sideeffect of late (requirejs) execution. Tapestry could possibly have some helper callbacks, blocking mechanisms or just helpful tips and documentation. Conclusion (sort of) Overall I’m amazed of how stabile and great 5.4 is in current alpha and will only continue to improve towards GA release. Think Howard (and other committers) have done a tremendous job on 5.4 and will help keeping Tapestry relevant for new projects. There are gotchas, but can be picked up for production use now in my opinion and experience. My top wishlist: - Better control and flexibility of Requirejs configuration - Asset management (url generation and request handling). For CDN use it’s not yet reliable in our experience. Would like to see more configuration options and should be easier to override/decorate/advice in case you need to. We’re just getting started and have done just the initial migration and will continue to improve and optimize for bootstrap(responsive/adaptive) and requirejs. 5.4 definitely is a great leap forward and will help us providing modern responsive experiences for the web. Best Magnus
