KMountford's avatar

Optimal way to deal with dashboard that displays lots of different queries?

Hey, was hoping to bounce a few questions off of somebody.

TL:DR Data that can be pulled in one go then needs to be analysed for each user on their dashboard, how would you do it? Separate API calls for each tile for a little amount of information each time - the breaking down of statistics taking place server-side? Or pull all relevant data in one call, attach to dashboard view, and break it down in javascript, client-side? Another way?

I'm developing an app where the primary feature is a dashboard that displays a number of different statistics relevant to the user that is logged in. Each 'tile' on the dashboard will either be a chart.js (or similar) graph, or a basic statistic (e.g. time spent). There will likely be 12 - 14 of these tiles.

The user will be able to display different data depending on the period they select, which will narrow down the query (e.g. this week, last 2 weeks, last month, etc.).

My planned setup at the moment involves creating an API with Lumen which will handle pulling in all of the relevant data and returning relevant data then application-wide things happening with Laravel (or potentially a JS 'back end'? No experience with them yet, but it may make sense here?)

What I'm now trying to decide is if I should use one endpoint for all of the data and produce the relevant narrower data (e.g. add up time spent) using javascript or if I should have multiple endpoints that will produce the narrowed data (e.g. api.site.com/matches/{unique_identifier_for_user}/played_time?period=week).

Obviously this means the dashboard will be making multiple HTTP requests (10 - 12) to populate the dashboard, but does mean if I want to call just one or two of the statistics later I can.

If I just make one call when I call the dashboard (dashboard?period=weekly) then I can dump all of the data relevant to the week into the view and sort through it with javascript. But for 10 - 12 tiles this is going to be a sizeable amount of javascript.

Also means I'd have no endpoints for other uses of the statistics, possible duplicating javascript in other parts of the application.

Perhaps I'm going about this all wrong? What do you think? How would you approach this?

  1. Given a dashboard with 10 or 12 tiles / graphs that display statistics about something, what's the optimal way to handle this? One request that gets all relevant data for a period of time, attaches to view, then breaks it down using javascript, or multiple ajax requests to populate each tile with break down of statistics happening client side (think api.site.com/something/{unique_identifier_for_user}/total_time?period=week). Another way?

  2. If it's server-side, how would you lay this out? Statistics or Report controller?

0 likes
2 replies
EliasSoares's avatar
Level 10

How are you loading this statistics? Using Ajax?

  1. First load of your page, get the initial information writing at Javascript (Maybe you have a lot of things to load, ok, but it will be loaded anyway, the same amount of data)
  2. Make a controller that accepts to receive an JSON that asks for one or more statistics, so you will do only one http request by update.
1 like
KMountford's avatar

Still planning, so not decided how I'll load it yet. Likely with AJAX, although an initial request is possible.

I really like the sound of using a controller that accepts a JSON request for all or some statistics, that's a great solution. The flexibility of calling one, few or all statistics with one request!

So api.site.com/statistics/matches/{unique_identifier_for_user}?period=week processes JSON for requested stats (e.g. all, or time played, score, etc.) then does whatever analysis is relevant, groups output and returns it, making it accessible in javascript with only one request. Have I got that right?

Seems like a great solution. Thanks!

Please or to participate in this conversation.