Best Dashboard Architecture

Question

I need to build a dashboard for an application, the dashboard will have different dashlets and each dashlet can have any one of the following things:

1. Graphs (JFreeCharts and some Javascript Chart)
2. Table data from tables
3. Data from external sources
4. Maps

What can be a good architecture for such kind of application?

What I have currently in mind is:

1. Each dashlet should have its own lifecycle and when the dashboard loads it should just show the UI of the dashlets initially.
2. After the page load each dashlet sends a server call (based on its type) to fetch its data
3. After the data has been fetched, each dashlet (based on its type) renders the data.

Answer 1

I think what you are looking for is more along the lines of managing or controlling your dashboard. I am designing something similar. I would suggest you look at google app engine it can be used to automate and control this: https://developers.google.com/appengine/docs/whatisgoogleappengine

Also look at these open-source dashboards: https://github.com/twilio/stashboard

Answer 2

I would advise against using a custom web framework when there are so many free ones available.

As mentioned in another answer, the traditional MVC style frameworks don't really fit well to your 'dashboard' desired style of UI. They are best used for creating static web sites based on data retrieved elsewhere. They don't handle user interaction well and you usually have to hand roll your own AJAX to do anything useful without a page request.

A better breed of web frameworks to look at are the Web 2.0 fraemworks, also known as the frameworks which help you build web applications. It is important to understand the difference between web site and web applications. They are usually differentiated by the latter being interactive and the former being mostly static. Websites which also have some interactive components are still web sites. A good way to think of it is ask yourself "Does this feel like a desktop app?".

For web application development in the Java (JVM) realm, I would use Vaadin. It lets you write Java code similar to Swing programming, with event based methods. You can even avoid writting HTML altogether if you'd like by defining your views programatically. This lets you unittest your view logic (in web apps, there is more than usual) which is not posible with regular HTML template based frameworks. The other main advantage is that it has built in methods which allow you to write Java code to handle dynamic, asynchronous functionality and it all gets translated to JavaScript automatically. No need to write 4 different languages while writing your web app, just write Java for everything! Try it out, it is fun to work with!

Another web app framework that is getting alot of attention is Lift. I do not have experience with it but many devs I have spoken with have promoted it to me. I believe it uses HTML templates with Java code as the back-end. It is also apparently really easy to get started and your web app spun up. It also has built in support for doing AJAX like functionality. Worth looking into at least.

There are probably many more web app frameworks out there that would suit your needs. These all have the advantage of being tested, independently maintained, updated, and secure*. If you roll your own framework for this project, you need to worry about everything yourself. Written a web framework that doesn't offer anything new would be like written yet another programming language that isn't innovative; it is just a waste of time.

Answer 3

First of all, there are plenty of front-end frameworks to get you started. Some of the more popular ones include:

• Backbone
• Javscript MVC
• Sproutcore

A bit of Google searching can yeild pros and cons of each and I would weight your options accordingly.

That all being said, the basic problem you posed actually seems similar to ours. In the end, we built something a bit different in house. Many of the frameworks out there are optimized to display a singular canonical "view" based on a Model reflected by the DB and a Controller to manage small changes. A dashboard has, in essence, a variety of different modules that must be doing their own independent things as you've mentioned in your question. Because of the high number of independent modules, I feel like you might feel pains in some of the frameworks listed above.

I can't tell you exactly how to implement such a module architecture, but here are some rules of thumb we used when designing ours:

Module Design:

• Module-based. (Login module, Map module, each Dashlet may be a module, etc.)
• Modules must have one Model, may have no more than one Collection (which is-a Model), and may have one or more Views.
• A module may be used in multiple places and pages. The singular Model should stay the same, but the Views are likely different.

Rendering:

• Almost all HTML on the page is written and updated by javascript modules. The template files are almost empty except for headers and basic scaffolding.
• All modules render their full HTML selves and replace themselves into the DOM. The module should have as complete of a static HTML representation ready to go before inserting into the DOM. This means the render functions use “.replaceWith()” instead of “.append()”.
• If simple HTML replacing isn’t an option (i.e. needs to be animated) a transition function should be defined detailing how to go from one rendered state to another.
• Because rendering is expensive, Views by default do not auto-refresh on all Model changes. Re-rending happens through events only. _render() is in-fact an internal method.

Orthogonality:

• A single inter-module event dispatcher on the page Controller handles all cross-effects between modules.
• Modules should never “reach outside” of their own DOM context. If an event in one module affects another, it should go through the page controller dispatcher.
• Each module as orthogonal as possible. They depend on each other as little as possible.
• Each module in its own file.

Connecting to backend:

• All modules use the same global backend adapter. Modules never talk to the backend by themselves. This makes your front-end back-end agnostic.

Recursive:

• Modules are commonly included in other modules.
• Modules re-render recursively.

Testable:

• Because modules render static HTML, they can be predictably tested.
• Modules must be testable.
  • Standard input -> Module -> Predictable static HTML output.
  • Standard events -> Module -> Predictable static HTML output.

If anyone knows of other frameworks along these lines, please share!

Answer 4

Our web app is based exactly on this architecture and in production since end of last year. You can see it at http://beebole.com

We just optimized the calls to our own server. There is a single call to get the common data needed by most widgets, each time a screen is loaded.

Then if a widget needs additional data, it makes a call itself to our server. The external widgets call their own data too, but to another server.