Pitfalls of true client-server architecture in web applications ?

Question

I've been researching on building web applications in a true client-server fashion.

This type of architecture basically consists of :

• A thin server, merely a headless api that :

  • handles security concerns

  • processes core business logic

  • provides data persistence

• A fat client, with a desktop-like design that :

  • caches data, and makes offline use possible

  • has gui-templating and rendering capabilities

  • holds and processes non-critical business logic

However, at first sight such an architecture wouldn't play nice with how the web works today :

1. poor or no possible fallback when javascript isn't available (2% of user-agents nowadays, am I right ?)

2. accessibility concerns (I'm kinda clueless here)

3. SEO concerns, cloacking is an option but that means one should provide some server-side html rendering, and making that content relevent could be tricky

Anything else I'm missing ? Which approach would you take to work around those issues ?

Answer 1

• It's either JavaScript or Flex (with JS being preferable). And those 2% can safely be ignored in my opinion
• Accessibility - Check this, it is still in progress, but worth taking a look.
• Search engines index content. You are going to write an application, which focuses on functionality, not content. You can have an opening plain-html screen, which to be indexed.

Answer 2

REST allows architectures of just this kind to be easily created for Web applications as well as desktop applications.

Here a REST server will respond to HTTP requests (GET, POST, DELETE and suchlike) to perform CRUD operations for persistence, and most likely business core rules and security.

Multiple REST servers might be aggregated using "coordinators" in larger systems to handle concerns like transactions.

Above this the UI layer will do the actual presentation to clients using HTML, AJAX or whathaveyou.

The great advantages of this approach are:

• It's scalable. The REST persistence and coordination layers are stateless, so extra servers can be brought in to address a bigger load.

• Data persistence, security and business logic are neatly encapsulated away from the UI.

• Different UIs can be created for different situations reasonably simply, e.g. a slimmed-down UI for mobile phones, etc.

The disadvantages include:

• It's relatively new, so tool support is lacking (especially in the Microsoft space)

• Deployment of larger systems can get complex, as there may be lots of service interdependencies

Hope this helps,