Database - Front End Application Structure - database

Question

This question may be too broad/conceptual for the SO community, but I'll give it a shot.
Quick Project Overview:
I have an project that consists of a front end application requesting data from a database via Angular $http requests. Each request is pretty much mapped one to one with a controller that visualizes the data specified in that request.
For example, I can specify keywords over a certain timeframe with:
get/A/kwords/?year=2013&month=9
and receive:
[
{"kword": "a", "count": 100, },
{"kword": "b", "count": 200, },
...
]
which I then plug in to a d3 directive.
The Problem:
I've reached the point in the project where I'm forced to either give extra work to the people developing the backend or the frontend. As the app currently stands, the database sends large chunks of JSON data that the front end then has to apply transformative functions upon in order to shape the data into the format required for the different d3 directives. For example, some JSON requests send excess data that the front end needs logic for to standardize the data entering the directives.
This is logic that I do not think the front end should be forced to handle. In my mind, the front end should only have to interact with the JSON request parameters, and not the format of the actual data coming in. I think it makes more sense for the backend to be able to serve up data in consistent formats depending on the URL params.
For example, instead of the backend serving up data formatted as such:
/get/B/kwords/?year=2013&month=9&limit=6
[
{
"kword": "a",
"data": [{"impressions": 100, "clicks": 150, "conversions": 200} ]
},
{
"kword": "b",
"data":[{"impressions": 50, "clicks": 60, "conversions": 70} ]
},
...
]
and forcing the front end to break apart this array-object-array-object, I should be able to specify a data=impressions parameter in the request:
/get/B/kwords/?year=2013&month=9&limit=6&data=impressions
[
{
"kword": "a",
"data": 100,
},
{
"kword": "b",
"data": 50,
},
...
]
Does this make sense/is this a reasonable request?

Answer 1

I was in a similar situation and I initially ended up going with the route that the backend handles the filtering and the front-end handles just binding data to d3.
The problem is that this is very very slow. Each $http request took 1-3 seconds so the filtering experience was not very good as you had to click a filter and wait to see a response.
It's actually much easier to send as much data as possible to the front-end and do filtering there. So while the initial page load takes a bit longer, filtering is instant. I ended up rewriting both the backend and front end to do the work on the front-end. I tried to make the initial data sent from the back-end as flat as possible and iterated through that array and pushed relevant data to properties on a javascript object to quickly transform data.
If I were to do this project again, I might have tried exploring the libraries dc.js and crossfilter as to try to avoid writing some of my filtering logic.
These are examples of just how fast filtering can be on the client side:
http://dc-js.github.io/dc.js/
http://square.github.io/crossfilter/