Web application architecture: Implementing MVC in the browser using a server as a repository of data and templates
What would be the advantages and disadvantages of implementing a web application with the following architecture:
Simple server that simply serves JSON responses of data, and HTML with templates to be rendered in the client. The client side be a javascript MVC "application" that receives and caches HTML the templates and asks for data in JSON format as needed. The js is the heart and logic of the application, implementing all the behaviour and interaction.
In this particular scenario, the server would ask as a repository of data and as a server of HTML templates. The client receives the templates and caches them for later (using offline storage, why not) rendering the开发者_如何学JAVAm with the JSON data in the browser itself.
I can see some upsides to this:
- The browser only requests just the necessary data and templates, making it work with a very low bandwidth. Caching the templates is a big plus.
- The server is quite simple, and may even be implemented in javascript using Node.js to allow for a graceful fallback for browsers that have javascript disabled by rendering the templates in the server and sending the generated html in the response.
and some downsides:
- More requests are made as templates and data are requested separately
- In a bare bones application of this idea, it doesn't work if the user has javascript disabled.
I've been thinking about this for a while, and I don't know how crazy this idea is, and if there are current implementations of this, or even if this has a name. Any extra advantages or disadvantages? Any existing implementations?
Feel free to close it if this idea does indeed have a name and a question exists about it.
If I had the rep, I'd make this a community wiki, but I can't.
Linkedin's engineering team is currently blogging about how they moved from server-side templates to client-side JavaScript templates.
There's already several articles available
- Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates
- Blazing fast node.js: 10 performance tips from LinkedIn Mobile
I don't know if something like this exists.
However, I don't find a real gain in requests to the server, as with the usual server-side MVC you can download the template only once and request just the JSON data (perhaps moving some of the model's behaviour to JS). Also, remember that 10 requests of 1kb of data to the server will take longer than 1 request of 10kb. If you have more requests with less data you may experience higher delays.
One big downside that I find to this idea is that you are exposing all your code. You may obfuscate it, but it is still there for anyone to see it.
A big upside: it might work offline if you implement some offline storage with a minimum of data.
Old question, but I saw that nobody here mentioned Bones—built on NodeJS and BackboneJS, to do just what you're looking for.
From the website:
Bones provides conventions for Backbone applications. It allows most code to be shared on the server and the client. Bones exposes your Backbone routes as regular paths on the server so they can be accessed by non-JavaScript agents, while capable clients can enjoy the normal client-side Backbone experience.
https://github.com/developmentseed/bones
精彩评论