Dashboarding with Nuxt/Vue
Tags: javascript, vue
Published: 2019-12-18 16:42:58

### Starter kit for non-specialists

In corporate life one often has to aggregate data and expose results to some audience, internal or external, in the form of a dashboard with text, tables and graphs.

There is a continuum of tools to ease the creation of such dashboards, from Excel sheets and PowerPoint slides to Business Intelligence (BI) tools producing custom web pages. MS Office tools are easy to use, but web pages are far superior in terms of rendering and distribution.

So the myriad of BI tools essentially offer automated web page creation from a more of less restricted set or inputs. The less parameters the simpler to use, the faster to deliver, but on the other hand, the less flexible the output. Each BI tool implies a trade-off designed for a context.

Practical experience shows that the short term constraints of corporate life strongly favors immediate results to medium term flexibility. People often choose tools that yield quick wins irrespective of the technical debt or the vendor lock up they may build , sometimes beyond reasonable. Think of the impact of bloated spreadsheets, far outgrowing Excel’s natural scope, in organizations.

With this bias in mind, I have tried to write an opinionated dashboard “framework” (for lack of a more modest word) that offers enough guidance to deliver results quickly but cannot lead to a dead end which would force a rewrite from scratch.

First and foremost, it is based on [Nuxt](https://nuxtjs.org/), itself based on [Vue](https://vuejs.org/), itself based on [Web Standards](https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/The_web_and_web_standards#Web_standards). Nuxt has a large community and strong momentum. Vue is the most approachable of the three dominant JavaScript web frameworks ([React](https://reactjs.org/) and [Angular](https://angular.io/) are the other two) and is impeccably documented. Additionally its [150k+ Github stars](https://github.com/vuejs/vue) are a sign that developers do not find it unpleasant to use, a key point in this context. This foundation guarantees absolute flexibility and maintainability (as much as one can anticipate). The dashboard layer is thin as icing on a cake, convenient in many usual cases, but ultimately optional.

Now there is no magic. It is also a trade-off. As opposed to many dashboarding solutions typically wrapping JavaScript in Python — I even wrote one ([ezdashboard](https://gitlab.com/oscar6echo/ezdashboard), used in production) to appreciate the benefits and limits of this approach — here the user must not shy away from direct contact with JavaScript.

As a consequence the learning curve is undoubtedly steeper.

However with the recent evolution of JavaScript, notably the Vue ecosystem, and the convenience of modern development tools ([VS Code](https://code.visualstudio.com/) in particular) the hurdle is not so high either.

So the trade-off is arguably all the more appealing.

## Links

So much for the general context. Check out the:

- [Demo dashboard](https://oscar6echo.github.io/nuxt-dashboard-template)
- Source code repo: [nuxt-dashboard-template](https://github.com/oscar6echo/nuxt-dashboard-template)
- [Documentation](https://oscar6echo.github.io/nuxt-dashboard-template-doc)

The rest of this article skims over the main features of the [nuxt-dashboard-template](https://github.com/oscar6echo/nuxt-dashboard-template) and the content in the sample tabs. For more info, visit the links above.

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/tvynywb7t58cf49f3tzm.png)

## Features

In a nutshell, the [nuxt-dashboard-template](https://github.com/oscar6echo/nuxt-dashboard-template) started out as a regular Nuxt app — built with the official [create-nuxt-app](https://github.com/nuxt/create-nuxt-app). Then it was developed to offer the following features:

- 1 or 2-level tab layout — so that a developer can cram a decent amount of data without scroll.
- Routing among tabs/sub-tabs — so that a developer only focuses on the content to display.
- App state management in url — so that a shared url leads a user right into a specific tab/sub-tab in a specific state.
- A store to manage the routing state and any user component state.
- Demo (same) dashboards in 2 major CSS frameworks: [vuetify](https://vuetifyjs.com/en/), the most feature complete, and [bootstrap](https://getbootstrap.com/), the incumbent.
- Build to **single** index.html file—while this may seem contrived, even sub-optimal, you cannot ignore that corporate environments are often so. 
:smirk:

*NOTE*: Nuxt is known for its [SSR](https://medium.com/walmartlabs/the-benefits-of-server-side-rendering-over-client-side-rendering-5d07ff2cefe8) capabilities. Here dashboards stick to [SPA](https://en.wikipedia.org/wiki/Single-page_application) mode, as they are meant to be deployed as static sites. But with Nuxt’s flexibility and versatility, the [switch to SSR is within easy reach](https://blog.lichter.io/posts/nuxt-dynamic-ssr-spa-handling/).


## Examples

Most dashboard retrieve data and display tables or graphs. To help with these typical use cases the demo dashboards contain user components that:

- Request REST APIs with [axios](https://axios.nuxtjs.org/) and [fetch](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch)
- Request GraphQL API with [apollo-client](https://github.com/nuxt-community/apollo-module)- Load static files with [axios](https://axios.nuxtjs.org/)
- Connect to [Web Socket](https://developer.mozilla.org/en-US/docs/Web/API/WebSocket) for real time data feed
- Display grid/table with [ag-grid](https://www.ag-grid.com/)
- Display plots/graphs with [highcharts](https://www.highcharts.com/demo)
- Use browser APIs ([geolocalisation](https://developer.mozilla.org/en-US/docs/Web/API/Geolocation_API), [canvas](https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API), [web worker](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API))

## Conclusion

The [nuxt-dashboard-template](https://github.com/oscar6echo/nuxt-dashboard-template) is more demanding on a user than the typical Python based helper tools that I have seen. To come back to the initial remark it is resolutely geared towards flexibility.

Why ? The limitations of the wrapper-approach have proven a serious drag at times, in a corporate setting where dashboards need grow organically with features which may collide in unanticipated ways with the wrapper hard limits..

So while it is not a tool for everybody, it can take a non-specialist but motivated engineer quite far — I think.