iWantMyName architecture

an overview of the architecture behind iWantMyName. This talk was presented at several perlmongers events.

Transcript

1. Tuesday, 10 July 12
2. Tuesday, 10 July 12
3. stripped down catalyst stripped the M out of the VC Tuesday, 10 July 12
4. pure NoSQL no relational DB left in the entire stack Tuesday, 10 July 12
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, 10 July 12
6. in a bit more detail Tuesday, 10 July 12
7. lightweight • stripped out the model handling entirely • stripped out the authentication handling • many custom plugins (core and contrib) Tuesday, 10 July 12
8. authentication architecture • multi platform handling (including different session cookie domains) • CouchDB based storage • OAuth • API login (release pending) Tuesday, 10 July 12
9. session handling • started with Postgres and the standard session handler • moved to CouchDB for multi domain handling • moved to Redis for speed Tuesday, 10 July 12
10. backend • all business logic in the backend • clusters of perl/erlang daemons • reading off RabbitMQ • answers cached in Redis Tuesday, 10 July 12
11. multi anything • multi domain support • different platforms in one daemon • i18n + multi currency • separate template trees Tuesday, 10 July 12
12. static content Tuesday, 10 July 12
13. Tuesday, 10 July 12
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, 10 July 12
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, 10 July 12
16. Tuesday, 10 July 12
17. backend in detail • Dæmonise daemons • plugin based daemon framework • dungenkeeper maintaining population • git://github.com/ideegeo/Daemonise.git Tuesday, 10 July 12
18. workflow engine • CouchDB based workflows • RabbitMQ based processing • perl based daemons • talked about it before: http://lnz.me/cVcW Tuesday, 10 July 12
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, 10 July 12
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, 10 July 12
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, 10 July 12
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, 10 July 12
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, 10 July 12
24. questions? Tuesday, 10 July 12
25. springtimesoft.com/lenz Tuesday, 10 July 12
26. credits • http://www.flickr.com/photos/amagill/ • http://www.flickr.com/photos/n0rthw1nd/ • http://www.flickr.com/photos/kemped/ • http://www.flickr.com/photos/vistavision/ • http://www.flickr.com/photos/brenda-starr/ • http://www.flickr.com/photos/ abbeychristine/ • http://www.flickr.com/photos/beigephotos/ • http://www.flickr.com/photos/scania/ • http://www.flickr.com/photos/brewbooks/ • http://www.flickr.com/photos/dunechaser • http://www.flickr.com/photos/neenahhistory • http://www.flickr.com/photos/mlrs193/ • http://www.flickr.com/photos/axis/ • http://www.flickr.com/photos/thevlue/ Tuesday, 10 July 12