Quest for The Fluid Web FrameworkAuthor: ceefour | Filed under: Fluid Web
- 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).
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:
- 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.