History API Module-wise Tags

[RinkleDang]

Hello everyone!

We have used UCI History API for in-app notifications. While we are getting the response, the response does not include 'module' tag in it. We had decided to go with the following approach to solve for this:

1. Each Template will be assigned a Bot ID
2. These IDs will be mapped to the modules and the table will be stored in Shiksha

However, while each bot is mapped to a specific module (for instance, Bot A is mapped with Attendance module), each module has different bot IDs mapped to it (for instance, attendance shall have 4 bots i.e. 4 templates)
@snehal0904 pointed out that while this approach can be figured out, it will make the frontend slow as we have a 'module-wise' filter on frontend. She has suggested providing an extra field in the params for the same.

@SaketSinha what would you suggest? Is there any other approach to this?

@snehal0904 please feel free to edit or add, in case I am missing something.

cc - @sagarihanda @snehal0904 @ManojNathIC @coolbung

[SaketSinha]

IMO, maintaining a Module-Bot mapping table on the Shiksha side should be fine. I don't feel there would be much of a performance issue, since the number of bots is not very huge. But I will request inputs on performance by @ChakshuGautam @coolbung .

[sagarihanda]

Few trade-offs to consider here:

1. Over time, a single user's in-app notification history can become large (50-100). However, since we are only showing notifications received in the last 30 days, so might never exceed ~100 notifications.

2a. If the module is stored on Shiksha's end - whenever a user selects a module filter, the module will be compared against list of Bot IDs (essentially message templates) and identify all Bot IDs mapped to this module. Then the picked Bot IDs will be compared 1-by-1 to all notifications received in the History API for a match. Then the matched notifications will be shown on the screen.

2b. If module is stored in the history API - the filter can be applied directly and the # of steps to achieve end result are reduced - hence making it more efficient.

Given these multiple steps required for ~100 notifications, it could potentially make the loading slow. @coolbung @ChakshuGautam hope this clarifies. Would be great to get your thoughts here so we can pick an approach and proceed.