0

I am working on an data visualisation app that will allow the user to filter the data that he sees by various criteria.

I want to keep as much logic as possible on Python/Django side, like this:

  1. Data is passed from Django view to the template.
  2. On the frontend, user filters the data through various controls: dropdowns, sliders etc.
  3. The controls inputs are sent back to Django view (via AJAX post request?), which returns filtered data and sends it back to the template.

4.The template - the visualization - is updated with the filtered data.

Is this a good approach? My concern is that a lot of data will be flying around and the app might be unresponsive.

Another, possibly faster idea is to filter the data on client's side in JavaScript - but I would really like to leverage the great Python data munching libraries instead.

barciewicz
  • 3,511
  • 6
  • 32
  • 72
  • I'm confused what you mean by "Data is passed from Django template to the view". Doesn't the view pass data to the template? For the AJAX, you might want to implement https://www.django-rest-framework.org/ into your project for a nice RESTful interface. – Cole Dec 10 '18 at 23:24
  • @Cole, of course, corrected now. Also, I already have an DRF API, so I indeed might use that. But my concern will still be valid I guess - data flying back and forth, as opposed to being filtered on client's side, which will be possibly faster. – barciewicz Dec 11 '18 at 06:43

1 Answers1

0

If you want to use DRF API, then go with it. A lot of websites have filtering features. I'd suggest you to take a look at django_filter package. It's possible to integrate it with DRF.

The worst thing in filtering data on client side is that you can't use pagination. Imagine that you have 500+ objects to filter, javascript filtering function is what really will make your app slow.

At the same time, if you have 20-30 objects to filter and this number won't grow up, then you can go with JS only and single endpoint: getAll()

Common approach is to set up javascript on_change handler and construct GET requests like(example from real project) this:

https://yourbackend.com/api/product/?status=not_published,published,inactive&search=132&moderation_status=declined,on_moderation,not_ready&ordering=desc&price_max=1000&page=1

DRF + django_filters will work just fine that, with minimum of your code involved.

Well known pitfall on js side is to make request without timeout, eg user writes text and on every keyUP() event request being sent. Or he moves the slider and a lot of requests being made - you'll need to make request when users stop it, eg 300ms after he chosen value. See this question for reference.

Sure, there's one more point. Your database have to be normalised and have proper indexes. But you have to look at this side if you'll have really slow SQL queries.

Summing up: I'd choose thin js layer and do most of work on backend.

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Satevg
  • 1,601
  • 2
  • 16
  • 23