42 architecture docs #49
Conversation
docs/service-layer/other-events.md
Outdated
|
|
||
| # Retrieve New Messages | ||
|
|
||
| This event will bring new messages to the FE, which will be stored in the local storage. There will be a limit on cached messages. The limit will be per conversation. Once there are new messages that exceed the pile, we will delete old ones. |
There was a problem hiding this comment.
With our FE - service layer separation, we sometimes tend to think data are remotely retrieved, while it is not. Don't you think this logic is simply duplicating the data we locally have in IndexedDB into the local storage?
There was a problem hiding this comment.
The idea behind this approach is to reduce the calls load.
"There will be a limit on cached messages. The limit will be per conversation. "
I think we shouldn't bring everything every time we open the app and I added this sort of caching logic for that.
Picture you opening a messaging app, we don't bring everything every time, I think it is too much load but only what is new.
For more info refer to: README.md/ ## Alice checks status requests
Shall I review that logic based on other specific points that might not be clear?
There was a problem hiding this comment.
I definitely agree with loading messages in chunks, but do we really need to cache anything? I do not see a real advantage reading from localStorage vs reading from IndexedDB. Can't React in-memory state be the "cache solution" with respect to this logic?
There was a problem hiding this comment.
I reviewed and re structured that part providing a better and (hopefully) more comprehensible solution.
There was a problem hiding this comment.
It is indeed more comprehensible. Thank you.
Added service layer architecture document for didcomm interaction and basic wallet functions.