Your SlideShare is downloading. ×
Web apps of the future
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

Web apps of the future

431

Published on

Published in: Technology, Design
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
431
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
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. 1
  • 2. This summarizes the past decade in Java Web Application Architecture. Your currentarchitecture probably looks like this. Middle block is Servlet-based, the past sevenyears or so generally Spring+Hibernate or JSF+JPA, Struts before that. It could be anyof two dozen other stacks, the common thread is that the HTML compositionhappens server side. 2
  • 3. iPhone 3G was launched June 9th, 2008. The original iPhone had people curious, butgenerally unconvinced. The iPhone 3G was the game changer. 3
  • 4. This chart puts into perspective just how big touch screen portable devices became inhow little time. It’s a pity the number of Windows licenses sold is not available, itwould be nice to contrast these numbers to. 4
  • 5. This is the past decade in architecture today. It poses three main challenges. 5
  • 6. Smaller screens: obviously.Poor data connections: low bandwidth, high latency (actually a bigger problem forthe TCP connection than the low bandwidth) and the damn thing resets to a lowpower state after a few seconds, with a significant ramp-up delay.People demand apps: not so much a technical limitation, but it impacts applicationarchitecture as we’ll see later. 6
  • 7. 7
  • 8. Dealing with small screens isn’t that difficult. There are three approaches: <list>.Device Detection happens on the server side: send tailored content to each deviceclass.Responsive Design is the opposite: structure your views in such a way that they’llwork for any screen size. Essentially device detection on the client. [CSS3 MediaQueries][1] have made this a lot easier.[1]: http://www.w3.org/TR/css3-mediaqueries/ 8
  • 9. This is a good example of responsive design. Live demo: just resize a browser window.http://www.lukew.com/ff/entry.asp?1509 9
  • 10. Summary: smaller screens. [Twitter Bootstrap][1] is the foremost CSS framework[1]: http://twitter.github.com/bootstrap/ 10
  • 11. Mobile connections have low bandwidth, high latency and intermittent availability. 11
  • 12. 12
  • 13. Filmstrip view courtesy of http://webpagetest.orgNotice that BP’s site is quicker to show the first bit of content (perceived speed).However, BP’s initial content is a sidebar, whereas Exxon is quicker with the maincontent. Both sites are correctly built with regards to the large title image: the textcontent is not blocked from appearing before the image is loaded. 13
  • 14. (Shown in an external browser at full size, with horizontal scrolling)Shell’s website fares horribly compared to the other two. It’s content doesn’t evenbegin to appear until a second after the next nearest is completely done. Webperformance matters. Google, Yahoo!, Bing, Mozilla and a bunch of others have allreported [significantly improved conversion rates][1] after a web page speedup.Google has started penalizing slow websites in PageRank.[1]: http://www.stevesouders.com/blog/2010/05/07/wpo-web-performance-optimization/ 14
  • 15. The timeline view is available in all current browsers to help optimize page loading.Take special notice of bars that abut (rather than overlap) earlier bars. In this case, abit of content (such as a document.write() call in a script tag) may be prohibiting thebrowser from loading the next resource. 15
  • 16. AJAX loading: make part of the content appear with the initial load of HTML, then useJavaScript to load additional content.Widget toolkits: datatables.net, jqueryui.com, yuilibrary.com and tons of others. 16
  • 17. Summary: it’s all well-documented on the web. 17
  • 18. 18
  • 19. If you have an app, it’s quite likely that this has happened to you. All nice and dandy,but not desirable as a long term architecture. It’s hard to maintain feature paritybetween the two apps, it’s likely that they’ll grow apart. 19
  • 20. This is slightly healthier, but again, it’s likely that one of the two will receive more lovethan the other. 20
  • 21. Modern JavaScript has gotten [incredibly][1] [powerful][2] and it’s increasinglypopular to move the full MVC to the client side, powered by a REST back-end. REST(Google it) is a paper by Roy Fielding that essentially defines the interface contractthat HTTP implements. It’s the way to make the most of the HTTP protocol.[1]: http://bellard.org/jslinux/ (JavaScript x86 virtual machine running Linux)[2]: http://www.eveonline.com/universe/spaceships/ishtar/ (WebGL 3D starshipviewer for EVE Online (Firefox/Chrome)) 21
  • 22. The desktop app is a JavaScript application that consumes the exact same JSONservices as the mobile app. It requires a bit of static resources (HTML/CSS/JS andimages) to bootstrap.Consider making your JSON API public. If you do, other people will make apps andmashups at no additional cost to you. A great example is the NS (Dutch railways): theNS has its own iOS and Android apps, but no Windows Phone app. Because theirJSON API is public, other people have stepped in and made excellent Windows Phoneapps.Note: the Edge Server is an optional architectural component. JavaScript single-originissues may force you to use an edge server (reverse proxy) to expose multiple back-end systems via a single URL. The popular choices right now are Node.js and Nginx. Ifyou can get away with not having one, life is generally easier. 22
  • 23. 23
  • 24. OAUTH came up during the Q&A. It’s an HTTP based mechanism by which to delegateuser authentication to a trusted third party (“Sign in with your Twitter account”). Thekey thing is that OAUTH starts with an HTTPS redirect to the third party. During logon,the top-level URL in the browser’s address bar is the third party, not the client website. This means the user does not share his/her username and password with anyparty other than the authentication provider. This implies that there’s no additionalattack surface on the user’s credentials.Aside from authentication, OAUTH supports an authorization mechanism. This iscommonly seen in sites and apps that interact with social networks like Twitter andFacebook. A website or app can be granted access to e.g. post on the user’s wall ontheir behalf. This access is revocable. 24

×