Your SlideShare is downloading. ×
Iwmn architecture
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Iwmn architecture

2,803
views

Published on

an overview of the iWantMyName architecture. A catalyst app powered by a RabbitMQ based backend flavored with a lot of CouchDB and sugar coated with some Redis.

an overview of the iWantMyName architecture. A catalyst app powered by a RabbitMQ based backend flavored with a lot of CouchDB and sugar coated with some Redis.

Published in: Technology, Business

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,803
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
19
Comments
0
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Tuesday, 12 July 2011
  • 2. Tuesday, 12 July 2011
  • 3. stripped down catalyst stripped the M out of the VCTuesday, 12 July 2011
  • 4. pure NoSQL no relational DB left in the entire stackTuesday, 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/anythingTuesday, 12 July 2011
  • 6. in a bit more detailTuesday, 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 speedTuesday, 12 July 2011
  • 10. backend • all business logic in the backend • clusters of perl/erlang daemons • reading off RabbitMQ • answers cached in RedisTuesday, 12 July 2011
  • 11. multi anything • multi domain support • different platforms in one daemon • i18n + multi currency • separate template treesTuesday, 12 July 2011
  • 12. static contentTuesday, 12 July 2011
  • 13. 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/languageTuesday, 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
  • 16. Tuesday, 12 July 2011
  • 17. backend in detail • Dæmonise daemons • plugin based daemon framework • dungenkeeper maintaining population • git://github.com/ideegeo/Daemonise.gitTuesday, 12 July 2011
  • 18. workflow engine • CouchDB based workflows • RabbitMQ based processing • perl based daemons • talked about it before: http://lnz.me/cVcWTuesday, 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 sessionsTuesday, 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 handlingTuesday, 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 wiselyTuesday, 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 engineTuesday, 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 codeTuesday, 12 July 2011
  • 24. questions?Tuesday, 12 July 2011
  • 25. springtimesoft.com/lenzTuesday, 12 July 2011
  • 26. credits • http://www.flickr.com/photos/amagill/ • http://www.flickr.com/photos/scania/ • http://www.flickr.com/photos/n0rthw1nd/ • http://www.flickr.com/photos/brewbooks/ • http://www.flickr.com/photos/kemped/ • http://www.flickr.com/photos/dunechaser • http://www.flickr.com/photos/vistavision/ • http://www.flickr.com/photos/neenahhistory • http://www.flickr.com/photos/brenda-starr/ • http://www.flickr.com/photos/mlrs193/ • http://www.flickr.com/photos/ • http://www.flickr.com/photos/axis/ abbeychristine/ • http://www.flickr.com/photos/thevlue/ • http://www.flickr.com/photos/beigephotos/Tuesday, 12 July 2011