Flickr

1. Flickr A Case Study in Rich Internet Application Development Cal Henderson

2. Hi • Cal Henderson • Flickr Architect • Yahoo! Inc

4. flickr.com • Over 2 million users • Over 93 million photos • 368 TB of hard disk space • (376,832 GB)

5. A flickr history • Flickr started out as a Massively Multiplayer Online Game called “Game Never Ending” • On February 10th, 2004, Flickr was launched at the Emerging Technology Conference

6. A flickr history • Our two year birthday is next week – come to our party! • Saturday 11th February • http://upcoming.org/event/51807 • There will be cake

7. Vancouver, BC (not in America)

8. A flickr feature tour • Photos! • On web pages!

10. A flickr feature tour • How does it differ from other photo management services? • Social network based • Collaborative metadata • Community aggregation

16. Flickr architecture • Flickr is powered by a bunch of hardware in Texas and Virginia • A few hundred boxes • It can be broken down into 3 chunks: • Web serving • Photo storage / serving • Databases

17. Interweb Web Servers Storage Servers Database Servers Hardware architecture

18. Client / Browser Templates AJAX Page Logic API Application Logic Software architecture

19. AJAX • What’s that all about? • Asynchronous Javascript and XML • Jesse James Garret, AP, Feb 2005 • Previously called “remoting” • Google maps, Gmail, Flickr et al

20. AJAX History • Started out as loading scripts into <iframe>‘s or writing <script> tags into the document • Microsoft created XmlHttpRequest (1998) • Everyone else followed suit • JSON appeared in 2005 • Javascript object notation

21. The roundtrip • User initiates action • Browser makes background request • Server does it’s thing • Server responds • Javascript in browser executes to handle response • Response is displayed somehow to user

22. The roundtrip • User initiates action • Browser makes background request • Server does it’s thing • Server responds • Javascript in browser executes to handle response • Response is displayed somehow to user

23. Browser compatibility • Sounds too easy? • Luckily all the browsers implement XmlHttpRequest slightly differently • We can avoid the grief by wrapping the different implementations in a simple library • For all browsers we just make a request and receive a response, hiding the ugliness

24. AJAX Abstraction • In fact, we care even less about the implementation when trying to get things done • We can abstract away the entire request/response cycle, hiding the protocol • We just receive a Javascript object – we don’t care if it came back as XML-RPC, REST or JSON

25. Debugging AJAX Apps • AJAX applications are harder to debug than static web pages • The client or server could be at fault • You can’t see what’s happening • We need special tools to: • See what gets sent over the wire • See what our code is doing

26. Debugging AJAX Apps • The simplest way to see what’s going on is to echo things out to the browser • That’s what alert() was built for, right?

29. Avoiding alert() • alert() isn’t always the best solution • If we want to dump a lot of data, creating a “debugging window” within the application makes our lives easier.

31. Sniffing the wire • With AJAX applications, we care about the data going over the wire • If we can see the HTTP traffic, we can make sure we’re sending the right requests and that the server is acting as we expect

32. Ethereal • Ethereal lets us grab and analyze all network traffic • http://www.ethereal.com/ • Windows, Linux, Mac (via fink)

34. Sniffing the wire • This is great to see what’s going on, but it’s a read-only tool • It would be really nice if we could edit requests and responses on the fly to help us test different scenarios

35. Fiddler • Fiddler from Microsoft • http://www.fiddlertool.com/ • Free • Windows only • Works best with IE, but also works with FF

37. Debuggers • Beyond looking at the traffic, we need to be able to see what’s going on in our guts • In the old days, we had to be content with alert() statements and patience • In these enlightened days we have debuggers ;)

38. Visual Studio • Microsoft have a free version of Visual Studio (Visual Studio Express) which contains their IE debugger • http://msdn.microsoft.com/vstudio/express/ • Full debugger environment • Watch lists • Breakpoints • Stack tracing

39. Venkman • For those of you with a Firefox preference, Venkman provides the same features • http://www.mozilla.org/projects/venkman/ • Free • Open source • Quite ugly

41. Dynamic pages • Now that we routinely manipulate the DOM, we don’t always know what state the “source” of the page is in • New tools help us introspect the DOM on the fly

42. Firefox • Choose ‘custom’ install when installing Firefox • Adds a “DOM Inspector” option to the tools menu

44. IE Dom Tools • IE Instant Source Viewer • http://www.blazingtools.com/is.html • IE Dom Inspector • http://www.ieinspector.com/dominspector/ • IE Developer Toolbar & Dom Explorer • http://www.microsoft.com/downloads/details.aspx?FamilyID=e59c3964-672d-4511-bb3e-2d5e1db91038

46. AJAX in the wild • We can build whole applications in AJAX, but there are drawbacks • Having URLs for resources are important • Smushing everything into a single interface gets ugly quickly

47. AJAX in the wild • We can use AJAX to allow click-to-edit functionality, avoiding two page roundtrips • For discrete pieces of functionality, we can create small AJAX applications • Organizer

49. Web 2.0? • Web 2.0 is the talk of the town • Web 2.0 isn’t all about AJAX • What can we learn from Web 2.0?

50. Five ways to love web 2.0 • Collaboration • Embrace collaborative metadata • Don’t ghettoize your users