API improvment : nb_notes per folder/tag

Features
1

Could it be possible to improve the API and return the number of notes per folder or tag ?

currently I have to do

GET /folders

and for each item

GET /folders/:id/notes

and repeat it for each sub folder

plus the same with tags

GET /tags/:id/notes

but it's time consumming :confused:

1 Like
2

In that case, Iā€™d suggest to add /count at the end to retrieve the number.

3

That does not solve th Iproblem of one request too much
I really need the count of notes per tag or folder when i get that info of each of them

4

Ah, I see.

5

I guess we could have a note_count property on the tag and folder objects. It would be a virtual property (since not in the db) calculated dynamically when requesting the object.

6

Could either of you provide an API endpoint example for this functionality?

7

It should not be a new endpoint, it should be available with

/GET tags
/GET tag
/GET folders
/GET folder
8

So you would like the API to return something like this for GET /folders:

  {
    "id": "140a30783e5d4b00819ba878f792dd23",
    "parent_id": "",
    "title": "My Test Folder",
    "notes_count": 17,
    "type_": 2
  },
...
9

yes :slight_smile:
With the process I discribed in post 1 , I added notes_count by myself after having queried /folders/:id/notes which is absolutly not good for perf.

10

Yes thatā€™s correct. As the ā€œnotes_countā€ property is not in the database, it would be a virtual one thatā€™s computed when you request it. We donā€™t really have this concept in the API now but itā€™s a useful one and shouldnā€™t be too hard to add.

11

Although, when you look at the server side of things, that value has to be calculated for every folder, thus an additional count(*) statement (which requires a table scan - very bad for perf) has to be executed. Thus the runtime changes from O(N) to O(N*M). M is the average number of notes per folder.

I'm not convinced that such an edge case warrants the perf impact for everything else. But hey, I'm not the owner, so it's not my call. Such an impact is only acceptable, when requested (by a flag, endpoint alteration, ...) and should not be done by default. I've been a long time in performance and I'm just saying that you should be aware of the consequences. It might not matter if you have a few notes, but it will be noticeable, if you have a a lot of notes and folders.

So the overhead you have experiennced when doing it manually, will now be done by the server - every time someone request a list of folders.

12

I know all of That.
Would be better if the counter was a real column that is increased or decreased each time a post or delete occured
No?

13

It duplicates information. And, as the saying goes, ā€œIf you have two copies of the same information, at least one of them is wrong.ā€

14

yes, at least if what suggested laurent could see the light, that should be helpful