I’m looking for pointers for an application architecture for an extranet application that we plan to deliver with ASP.NET MVC.
There will be about 50 Entity types, and around 200 users. The main entities will have 2M+records.
The users are divided into small groups, typically 2 or 3 people a group. Each group has different information requirements. As such we are planning on developing a number of widgets which the users can group together to make their personalized application. Ignoring the UI issues of window/widget management, several ways of achieving this spring to mind:
1) use Ajax for each widget and provide some synchronization with perhaps Steve Sandersons knockout.js With a bit of clever planning this could solve some of the issues of multiple copies of the same field being on the screen at once. What I don’t like about this approach is that lots of the widgets need the same data, but will be requesting it separately. Even with server-side caching to reduce DB queries this is still going to be generating a huge number of unnecessary http requests.
2) Build the pages server side by assembling all the required widgets. This would be akin to what is done with OrchardCMS. I’m taking a look at that in a bit more detail.
3) Build it more as a HTML5/JS app with Websockets to manage the communication. This feels like too much too new.
So: any ideas – has this been solved before – if so, where/what/how.
Why not choose a combination of both #1 and #2. #3 sounds enticing but you are going to have issues with browser support (at this time). When you are rendering the pages you know the number and type of widgets required for the page. You can create a unified XML document with all of the data required by the widgets.
Begin creating the document when you know all of the data. Request the data on the server and cache it. You could then download this document to the client where each widget could query a seperate node. The widgets would render locally and then pull data from the document.