The document discusses the evolution of web application architecture over the past decade. It describes how architectures have transitioned from server-side HTML composition to client-side single page applications powered by RESTful APIs and JavaScript. It also outlines the main challenges of mobile and touchscreen devices, including smaller screens, poor network connections, and user expectations of dedicated apps. Solutions discussed include responsive design, techniques for improving performance over slow networks, and moving application logic and data access to the client side.

1. 1

2. This summarizes the past decade in Java Web Application Architecture. Your current
architecture probably looks like this. Middle block is Servlet-based, the past seven
years or so generally Spring+Hibernate or JSF+JPA, Struts before that. It could be any
of two dozen other stacks, the common thread is that the HTML composition
happens server side.
2

3. iPhone 3G was launched June 9th, 2008. The original iPhone had people curious, but
generally unconvinced. The iPhone 3G was the game changer.
3

4. This chart puts into perspective just how big touch screen portable devices became in
how little time. It’s a pity the number of Windows licenses sold is not available, it
would 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 for
the TCP connection than the low bandwidth) and the damn thing resets to a low
power state after a few seconds, with a significant ramp-up delay.
People demand apps: not so much a technical limitation, but it impacts application
architecture 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 device
class.
Responsive Design is the opposite: structure your views in such a way that they’ll
work for any screen size. Essentially device detection on the client. [CSS3 Media
Queries][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.org
Notice 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 main
content. Both sites are correctly built with regards to the large title image: the text
content 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 even
begin to appear until a second after the next nearest is completely done. Web
performance matters. Google, Yahoo!, Bing, Mozilla and a bunch of others have all
reported [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, a
bit of content (such as a document.write() call in a script tag) may be prohibiting the
browser from loading the next resource.
15

16. AJAX loading: make part of the content appear with the initial load of HTML, then use
JavaScript 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 parity
between 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 love
than the other.
20

21. Modern JavaScript has gotten [incredibly][1] [powerful][2] and it’s increasingly
popular 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 contract
that 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 starship
viewer for EVE Online (Firefox/Chrome))
21

22. The desktop app is a JavaScript application that consumes the exact same JSON
services as the mobile app. It requires a bit of static resources (HTML/CSS/JS and
images) to bootstrap.
Consider making your JSON API public. If you do, other people will make apps and
mashups at no additional cost to you. A great example is the NS (Dutch railways): the
NS has its own iOS and Android apps, but no Windows Phone app. Because their
JSON API is public, other people have stepped in and made excellent Windows Phone
apps.
Note: the Edge Server is an optional architectural component. JavaScript single-origin
issues 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. If
you 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 delegate
user authentication to a trusted third party (“Sign in with your Twitter account”). The
key 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 web
site. This means the user does not share his/her username and password with any
party other than the authentication provider. This implies that there’s no additional
attack surface on the user’s credentials.
Aside from authentication, OAUTH supports an authorization mechanism. This is
commonly seen in sites and apps that interact with social networks like Twitter and
Facebook. A website or app can be granted access to e.g. post on the user’s wall on
their behalf. This access is revocable.
24