1

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

iPhone 3G was launched June 9th, 2008. The original iPhone had people curious, but

generally unconvinced. The iPhone 3G was the game changer.

3

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

This is the past decade in architecture today. It poses three main challenges.

5

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

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

This is a good example of responsive design. Live demo: just resize a browser window.

http://www.lukew.com/ff/entry.asp?1509

9

Summary: smaller screens. [Twitter Bootstrap][1] is the foremost CSS framework

[1]: http://twitter.github.com/bootstrap/

10

Mobile connections have low bandwidth, high latency and intermittent availability.

11

12

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

(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

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

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

Summary: it’s all well-documented on the web.

17

18

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

This is slightly healthier, but again, it’s likely that one of the two will receive more love

than the other.

20

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

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

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