Deprecated: Assigning the return value of new by reference is deprecated in /customers/7/b/4/mashupstation.com/httpd.www/Wikka/libs/Wakka.class.php on line 130 Deprecated: Assigning the return value of new by reference is deprecated in /customers/7/b/4/mashupstation.com/httpd.www/Wikka/libs/Wakka.class.php on line 261 Deprecated: Function set_magic_quotes_runtime() is deprecated in /customers/7/b/4/mashupstation.com/httpd.www/Wikka/wikka.php on line 90 Deprecated: Function ereg() is deprecated in /customers/7/b/4/mashupstation.com/httpd.www/Wikka/libs/Wakka.class.php on line 441 mashupstation.com: Basic rules for web application development

mashupstation.com : SimpleRules

HomePage :: FAQ :: Examples :: Manage files :: Forum :: Links :: Recently Commented :: Login

Basic rules for web application development


1. All functionality that possibly can be implemented on the client side shall be implemented on the client side.
2. All communication with the server middleware shall be constrained to service-interfaces; For instance REST.
3. No part of the client shall be evoked, generated or templated from the server-side. This rules out in-line conditional HTML in JSP, ASP, PHP, et.c.
4. The logic making up the server middleware will be implementing only the following functionality;
  1. Security
  2. Database access
  3. Cross-domain proxying for remote resources implementing only a) and b).

That's all.

Reasons;

1) Because implementing functionality on the server which will be presented on the client increases complexity and conversely also time to change and debug. It is also an unecessary entanglement between system parts. True, many system encapsulates the client-side generation very much, like Tapestry. As soon as you step out of the supported widgets and use-cases, however, you land in a quagmire of mixed places and complexity.

2) If we restrict and make explicit all communication to and from the server, we increase reusability in our application, since the client-side isn't tightly bound to the server, and as a bonus we also get a service interface to our app which can be used as public service, pay service or just to tie in to the corporate SAO framework.

3) This is kind of implied from rule one. But just to make things very explicit; It is the very conditional HTML/js evoked from server-side scripts which increases complexity in an application, even in ruby on rails, not to mention JSF, Struts, et.c. Happily, at least large parts of the rails community have begun to think in terms of RESTful applications, for these very reasons.

4) Again, by restricting where to implement functionality, you reduce the amount of mistakes. It has been argued that there should be a fourth functionality; Business rules. I argue that business rules on the server-side (I.e.. take the name of the customer and look up number of microwave ovens bought from another database and write the result in a third) is firmly in the security camp, since security issues are the reasons not to have that functionality on the client. I'm open for dicussion though :)

There are 54 comments on this page. [Display comments]

Valid XHTML 1.0 Transitional :: Valid CSS :: Powered by Wikka Wakka Wiki 1.1.6.2
Page was generated in 0.1782 seconds