1 / 61

Flickr

Flickr. A Case Study in Rich Internet Application Development Cal Henderson. Hi . Cal Henderson Flickr Architect Yahoo! Inc. flickr.com. Over 2 million users Over 93 million photos 368 TB of hard disk space (376,832 GB). A flickr history.

paige
Download Presentation

Flickr

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

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

  4. 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

  5. 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

  6. Vancouver, BC (not in America)

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

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

  9. 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

  10. Interweb Web Servers Storage Servers Database Servers Hardware architecture

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

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

  18. 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

  19. 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?

  20. 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.

  21. 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

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

  23. 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

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

  25. 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 ;)

  26. 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

  27. 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

  28. 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

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

  30. 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

  31. 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

  32. 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

  33. 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?

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

More Related