This presentation was given at Magnolia Conference 2013 by Thomas Körner, Senior IT Consultant at Kreuzwerker: http://www.kreuzwerker.de. Building a full featured web application raises an old question: implement or integrate features from existing software components. Starting a new project with a CMS involved raises an old question: What kind of data should be managed by a CMS and what should be handled elsewhere? To what degree should business logic reside inside the CMS? Editorial content belongs in the CMS, a Ruby on Rails application handles the rest. Our task was to replace a social community platform providing features like private messaging, friendships, uploading and organizing photos and videos, as well as public question and answer sections. The original implementation was based on an old version of Drupal without a chance to be extended. The customer, one of the biggest cruise lines in Germany, wanted to enrich the platform by serving community games and polls as well as all kind of marketing events. Moreover, there was a high demand on integrating the application into the company web publishing strategy. Based on the challenging customer requirements, our architecture was built on the following cornerstones: Magnolia CMS serving the static editorial content, a Ruby on Rails application managing all user interactions within the web page. Both software parts are coupled by using a Varnish reverse proxy aggregating page elements using Edge Side Includes (ESI). The talk will walk the auditorium through the technical solution of integrating Magnolia with Rails applications by focusing on how to separate editorial content from user generated content, rendering concerns, weaving CMS and Rails content and managing multiple admin interfaces. It will focus on how to deal with such an architecture from the developer's point of view by outlining pitfalls and benefits.

1. What shall be served by a
CMS ?
Just editorial content
Basel, September 2013
Thomas Körner
… experiences of a real project

2. Agenda
! Project Scope
! Objectives
! Technical Wrap Up
! Experiences
What shall be served by a CMS
kreuzwerker
2

3. Agenda
! Project Scope
! Objectives
! Technical Wrap Up
! Experiences
kreuzwerker
3What shall be served by a CMS

4. Social Community Platform of one of the biggest
cruise lines in Germany
! user generated content as travelogues, blogs,
photo galleries, video albums
! private messaging
! questions and answer module
! contests, polls and games
! commenting, likes
Project Scope
kreuzwerker
4What shall be served by a CMS

5. Technical Re-Invest
! tight coupling of CMS and community functions
prevented migration to new Drupal version
! CMS change according to the customers web
publishing strategy
! usage of a custom digital asset management
system
Project Scope
kreuzwerker
5What shall be served by a CMS

6. Agenda
! Project Scope
! Objectives
! Technical Wrap Up
! Experiences
kreuzwerker
6What shall be served by a CMS

7. Objectives
kreuzwerker
7
Customer‘s Main Objectives.
Experiencing a technical dead end in regard of CMS updates
due to heavy customization expandability as well as easy
updatability was in the customer’s focus.
High
Responsive
Easy to Extend
Easy to Update
Magnolia
Sync
of
user
content
Custom DAM
What shall be served by a CMS

8. Strategy
Magnolia
Ruby on
Rails
Widget
Approach
Varnish
! limit custom
code in the CMS
Updatability
! state of the art
web framework
to cover
business
requirements
Expandability
! fragment
caching of static
content.
Responsiveness
! Web Publishing
Strategy
3 2
1
kreuzwerker
8What shall be served by a CMS

9. CMS Functions
! Design & Branding
! navigation bar
! footer
! teaser
! Configuration
! polls
! games
! Editorial Content
! static pages (e.g. Impressum)
! information about cruises, staff, etc.
! Administration
! process based publication
CMS
kreuzwerker
9What shall be served by a CMS

10. Application Functions
! Asset Management
! photos / videos
! travelogues
! galleries
! Community Functions
! votes/likes
! private messaging
! friendships
Ruby on Rails
kreuzwerker
10
! Extensions
! map features
! poll/game logic
! User Management
! accounts
! personal spaces
What shall be served by a CMS

11. Agenda
! Project Scope
! Objectives
! Technical Wrap Up
! Experiences
kreuzwerker
11What shall be served by a CMS

12. Architectural Sketch
kreuzwerker
12
The production system is deployed on two
hosts routed by a load balancer. Each host
provides its own varnish, a public CMS
instance and a Rails application instance.
! Varnish
! routing by selecting the appropriate
backend
! ESI … Edge Side Includes
! Backends
! CMS
! Rails Application
What shall be served by a CMS

13. ! fixed page layout in
regard of branding
! application logic
dependent layout for
content area
! limited number of
AJAX calls
Rails Application
Rendering Master ?
Rails App was set to
be the rendering
master for all pages
focusing on user
generated content
CMS was set to be
the rendering master
for all static pages as
well as pages
requiring free editorial
layouts (e.g. polls,
games).
! embedding
application logic
as widget
requires heavy
use of AJAX
! limited editorial
freedom
regarding
application pages
CMS
kreuzwerker
13What shall be served by a CMS

14. Rendering Master – Rails App’
kreuzwerker
14What shall be served by a CMS

15. Rendering Master – Rails App’
kreuzwerker
15
ESI
What shall be served by a CMS

16. Rendering Master – Rails App’
kreuzwerker
16
ESI
What shall be served by a CMS

17. Rendering Master – Rails App’
kreuzwerker
17
ESI
What shall be served by a CMS

18. Rendering Master – Rails App’
kreuzwerker
18
ESI
What shall be served by a CMS

19. Rendering Master – Rails App’
kreuzwerker
19
ESI
What shall be served by a CMS

20. Rendering Master – CMS
kreuzwerker
20What shall be served by a CMS

21. Rendering Master – CMS
kreuzwerker
21
ESI
ESI
What shall be served by a CMS

22. ! branding
! editorial content
! games
! polls
! moderation of comments
! company blogs (editorial
content)
! user generated content
! assessment of polls / games
Rails ApplicationCMS
Administration
SSO to ease the burden of two applications
kreuzwerker
22What shall be served by a CMS

23. SSO between CMS and Rails App
kreuzwerker
23
! missing company SSO
! external editors
Pre-Condition
CMS login authenticates user in the Rails Apps
What shall be served by a CMS

24. Key: Magnolia Filter Chain
… common servlet filter
… back door login/logout code encapsulated
… update compatible
Pitfalls:
! Cross Site Protection Mechanism of Rails
! X-CSRF Token
! Cookie
! Storage of Rails App Authentication Cookie
SSO between CMS and Rails App
kreuzwerker
24What shall be served by a CMS

25. Games & Polls
! game runtime resides in Rails
App via participation widgets,
which allow the user
interaction
! widget is embedded into the
game/poll CMS page via ESI
! game assessment is done via
admin interface (active admin)
Rails App
! game configuration is done in
the CMS
! start and end of participation
! number of participation
attempts
! intro texts, images etc.
! layout of pages
! winner announcement by
embedding announcement
widgets via ids
CMS
kreuzwerker
25What shall be served by a CMS

26. Games & Polls
Interaction CMS "# Rails (1/3)
kreuzwerker
26
Game Setup
game template
! supports game
container
including various
rails widgets,
common CMS
editorial content
paragraphs
Publish Game
game config
! hidden form
parameter
secured by
shared secret
! first request
creates game in
Rails DB
Game Runtime
game content
! assets and
users only
known to
Rails
! depiction on
CMS pages
via widgets
What shall be served by a CMS

27. Games & Polls
Interaction CMS "# Rails (2/3)
kreuzwerker
27
Game
Assessment
administration/
assessment
! Rails Active
Admin pages
Winner
Announcement
announcement
! CMS paragraph
configuration
via user and
asset ids known
only to rails
! widget
approach
Game
Removal
game container
deletion
! Rails backend
has to be
informed
about
container
removal
What shall be served by a CMS

28. Games & Polls
Removal of the Game
kreuzwerker
28
! a new version of a page is created when pushing
changes from author to public
! check predecessor version for game identifiers not
included in current page
! de-activate polls in rails via HTTP GET Request
(signature in header secures request)
! synchronous call
What shall be served by a CMS

29. Agenda
! Project Scope
! Objectives
! Technical Wrap Up
! Experiences
kreuzwerker
29What shall be served by a CMS

30. Experiences
! agile development
framework for application
logic
! complex development setup
Strengths
! easy adding of new features
without CMS know how
! re-use of once developed
modules
! abstraction level
! learning curve of
development team
Opportunities Threats
Weaknesses+
kreuzwerker
30
+
–
–
What shall be served by a CMS

31. kreuzwerker
31
Experiences
Development Setup
! automated setup of target platform via vagrant on
top of Virtual Box on each developer machine
! Mac OS vs. Linux machines
! provisioning of vagrant box via puppet
! automated deployment of Rails App via rake
! automated deployment of CMS via maven and
shell scripts
What shall be served by a CMS

32. kreuzwerker
32
Experiences
Development Setup
! prolonged development cycle due to deployment
overhead
! mocking of CMS in Rails part
! ignoring Rails calls in CMS
! additional time for integration tests
What shall be served by a CMS

33. ! setup of infrastructure with
small team before
development phase
! continuous monitoring of
setup
! re-use of technology in
staging and production area
! continuous mentoring of
development & test team
! continuous integration by
testing team
! independent development due
to sparse mocking
Continuous Education & QMRamp Up
additional operational costs covered by advantages in the
long term
kreuzwerker
33
Experiences
Development Setup
What shall be served by a CMS

34. Thomas Körner
Thanks, for your attention
mail:
thomas.koerner@kreuzwerker.de
website:
www.kreuzwerker.de
kreuzwerker
34What shall be served by a CMS