During my experience developing web applications, it’s challenging to find the “best” web development approach of them all.I like these principles:
- POJO approach. No inheritance, interfaces, minimal annotations. Configuration is all that’s necessary.
- Convention over Configuration. Even with POJO, some configuration is needed. Minimize configuration by using conventions. And document the conventions! Because conventions can sometimes be confusing.
- REST approach. This is not anti-SOAP or anti-WS-*. It means designed for the web, and embrace resource-oriented and stateless principles.
- Use JSON. For browser-server communication JSON is preferable. Atom+XML is more suited for documents and server-server communication.
- Decentralized. Rather than one big app, decompose as much as possible. Decentralization means a more robust infrastructure is needed, and yes it means looking for trouble.
- Resource-oriented. Contrasts with page-oriented or procedural. Somewhat similar to object-oriented but with resource semantics. Kind of Objects than implement IResource.
- Interoperable. Services are exposed via JSON-REST API, AtomPub, or other mechanism. Can also consume other services easily
- Robust security infrastructure. Provides sufficient authentication and authorization mechanisms, and easily programmable.
- “ Native”. Blends with the host environment, even if just a simulation. jQTouch, Qt, Swing, are all good examples here.
- Lightweight. Prefers lightweight specialized frameworks, like Merb, Sinatra, than Ruby on Rails. Spring than Java EE. Heavy full-stack framworks (some call it “bloated”, though I don’t believe that term anymore) does have its plus sides though, less headache is one of them.
- Scalable. Runs on a scalable clustered system like Google Apps Engine or Heroku. Also means dictated by scalability restrictions of the respective environments (more headaches).
- Reasonably Reusable. I wanted cross-platform, but now it has expanded to cross-environment (with mobile devices and other stuff). So now I think some sort of reusability is desirable. For example, JavaScript logic that can be used by server-side desktop web application, server-side mobile web application, and client-side applications with embedded browser component.
The Fluid Web framework (I made up that term) provides most of the benefits with a reasonable level of complexity and learning curve.
Fluid Web will also use the best programming model for the task at hand. Divided broadly, there are three programming models in question:
- POJO Model. to Spring Programming Model. Also used in JavaScript and all Object-oriented programming languages. It’s RPC and object-oriented.
- REST Model. The “Web programming model” as Google calls it. This is less of an API and more of a protocol(s). It’s resource-oriented or document-oriented.
- Comet model. Asynchronous programming model. Data is passed through several message channels. Everybody are clients, they can publish and subscribe to the channels. XMPP belongs here too.
- SQL model. Great for accessing data stores declaratively. Also in this category: SPARQL for RDF triplets, YQL for web resources, GQL for Google Big Table, Microsoft’s LINQ. Resulting data is document-oriented.
I have been somewhat obsessed by this quest since a few years ago, and haven’t yet found the true answer. Betting on it on a commercial project is also too risky. So I decided that I will do more experiments on it on a research basis, and share my experiences here.
Feel free to share your ideas.
No related posts.
Related posts brought to you by Yet Another Related Posts Plugin.
-
http://topsy.com/tb/bit.ly/8uzzhc Tweets that mention Quest for The Fluid Web Framework | AdaRuby — Topsy.com