1

Our app is basically an image search engine. We have around 20000-30000 images and we want to search them either by keyword or by category (or both of them).

The first consideration is taking all the information asyncronously at the beginning (on page loading) so the app can work as a spa (without latency delay and minimizing the impact on the server).

Our jsons are normalized so we decrease the size of the files. We won't modify data from the client side so this is the only benefict we get from normalizing jsons

categories.json:

{
      language: "xxxx",
      "categories": [
      {
          "id": 1,
          "parent_id": null,
          "label": "House"
      }, {
          "id": 2,
          "parent_id": 1,
          "label": "Furniture"
      },
       ....
     ]
  }

keywords.json:

 {
  "language": "xxx",
  "keywords":
  [
    {
        "id": "table",
        "images": [2381, 2746, 3602, 4038, 6572, 6572, 13176, 13273, 28659, 28660],
        "cat": [1, 2]
    },
    .... 

  ]
}

images.json:

{
  "base-url": "http://www.xxxxx.org/images/",
  "images": [
    {
      "id": 2381
      "license": 7,
      "type": 3,
      "file": "4.jpg"
    },
    .....

  ]
}

license.json and type.json are similar.

As we thought about normalized jsons, we have to problems:

We should denormalize our data for showing to the user.

We shoud cache data so we don't download the json files almost everytime the user opens our webpage.

These are the solutions we've thought, so we'd like to know which one you would choose:

  1. We shoud denormalize our data with JavaScript and send it as a property to the react component. I'm almost new to React/Redux so I don't know if there is any pattern, library... to do it.

  2. Maybe the best way to normalize/denormalize our data could be an IndexedDB but it's not broad supported. In this way, normalize /denormalize could be easier than using javascript and we'd get our data cached.

  3. Forget about our initial idea, request denormalized json data to the API Server so each time we search images we make an ajax request. Our API still needs to be done so it would be ok. This design is more scalable as our bank of images could grow.

user2670996
  • 2,654
  • 6
  • 29
  • 45

1 Answers1

1

Considering the size of the image list it would probably be best to handle the filtering on the server and just send the filtered list to the client. With or without filtering you might consider paging the image list rather than sending the whole list at once. Paging makes it a little more complex but preserves responsiveness of the client.

J. Mark Stevens
  • 4,911
  • 2
  • 13
  • 18
  • json file size is ok, around 5MBytes. Pagin is a must because the app must anyway request the image files – user2670996 Nov 10 '15 at 18:04
  • If you don't mind sending the whole then just processing the normalized data in your store is no problem. The way I do it is to have sourceData, filterData and liveData. When the filter is active liveData = filterData otherwise liveData = sourceData. The component gets the liveData. – J. Mark Stevens Nov 10 '15 at 18:08
  • in our view component we would have to show data from several jsons, it's not filtering but also some kind of join as in databases. Users enter a keyword and we need to show the images, license, categories involved... I guess we would need something like https://github.com/agershun/alasql – user2670996 Nov 10 '15 at 18:32
  • If the data is related combine in the store to liveData. Its hard to give precise advise without knowing the whole picture. – J. Mark Stevens Nov 10 '15 at 18:36