The document discusses the evolution of a Catalyst application to use lighter weight components including removing the model layer and using Redis for sessions and RabbitMQ for the backend. It started as a standard Catalyst app and was stripped down over time, moving content to CouchDB, sessions to Redis, and the backend to RabbitMQ. Lessons learned included using plugins, choosing technologies like Redis, CouchDB and RabbitMQ, and getting a minimum viable product out quickly before refactoring.
4. pure NoSQL
no relational DB left in the entire stack
Tuesday, 12 July 2011
5. iwmn in 5
• as lightweight as one gets a catalyst app
• custom authentication architecture
• Redis based session handling
• RabbitMQ driven backend
• multi language/domain/currency/anything
Tuesday, 12 July 2011
7. lightweight
• stripped out the model handling entirely
• stripped out the authentication handling
• many custom plugins (core and contrib)
Tuesday, 12 July 2011
8. authentication
architecture
• multi platform handling (including different
session cookie domains)
• CouchDB based storage
• OAuth
• API login (release pending)
Tuesday, 12 July 2011
9. session handling
• started with Postgres and the standard
session handler
• moved to CouchDB for multi domain
handling
• moved to Redis for speed
Tuesday, 12 July 2011
10. backend
• all business logic in the backend
• clusters of perl/erlang daemons
• reading off RabbitMQ
• answers cached in Redis
Tuesday, 12 July 2011
11. multi anything
• multi domain support
• different platforms in one daemon
• i18n + multi currency
• separate template trees
Tuesday, 12 July 2011
14. content
• pages in CouchDB
• pages rendered with information out of
CouchDB
• page skeletons entirely i18n
• template branches in git repository per
platform/language
Tuesday, 12 July 2011
15. backend
request handling
• Catalyst pushes request to RabbitMQ
• backend daemons read off queue
• push response to Redis
• Catalyst reads off Redis (direct or through
Ajax)
Tuesday, 12 July 2011
17. backend in detail
• Dæmonise daemons
• plugin based daemon framework
• dungenkeeper maintaining population
• git://github.com/ideegeo/Daemonise.git
Tuesday, 12 July 2011
18. workflow engine
• CouchDB based workflows
• RabbitMQ based processing
• perl based daemons
• talked about it before: http://lnz.me/cVcW
Tuesday, 12 July 2011
19. evolution
• out of the box Catalyst app (mid 2008)
• home grown message queue for backend
• split out template tree
• moved more content to CouchDB
• moved to RabbitMQ in the backend
• moved to CouchDB for sessions
Tuesday, 12 July 2011
20. evolution 2
• moved more functionality from controller
to plugins
• moved to custom Engine
• phased out Model
• moved to Redis for session handling
• moved to Redis for RabbitMQ response
handling
Tuesday, 12 July 2011
21. lessons learned
• Redis rocks (not only for session handling)
• CouchDB rocks
• RabbitMQ scales like hell and rocks too
• Catalyst rocks with lots of memory too
• choose your weapons wisely
Tuesday, 12 July 2011
22. Catalyst lessons
• write plugins, lots of them
• do it the Catalyst way or you die
• message driven development is hard with
Catalyst
• watch your memory and your leaks
• use a fast session storage engine
Tuesday, 12 July 2011
23. coding lessons learned
• bump out the first version as quick as
possible
• rewrite it with the user feedback over time
• dense code helps avoiding bugs
• get to the point quickly, don’t spend ages
on nice code
Tuesday, 12 July 2011