@angelolloqui
really nice write up, thanks. Taking the time to explain some of your initial design decisions, particularly with the likes of Firebase, was insightful. It would be great to know how things progressed as it scaled further and whether you changed course on any of those design decisions.
I also had a specific question on how you chose to handle receiving new messages efficiently, when the user has the app open, given that each user can be involved in multiple threads. For example, did you create a "child_added" listener for each user-thread when the user opened the app, or only listen to the thread the user is currently viewing (perhaps combined with background notifications for non-active threads), or another approach entirely?
Computer engineer with a Master in Web technologies. Specialized in mobile application development, with broad experience using Agile methodologies and Certified Scrum Master. Active open source contr
Hi @codi0
! I'm glad you found it useful. Regarding your questions:
We still have the same design in place. We have done some minor improvements on the chat but nothing that affects the design decisions exposed in here. So far, the chat has grown a lot (a 10x since the post, with more than 1K messages a day), and we are now fully consuming the free tier and starting to pay. We are still not paying much but if we continue this trend we will have to make some design changes in a not so far future (not sure how yet).
I am not sure I understand your second question fully, but what we do to handle the multiple threads is:
We have a global unread chat message count in the user entry that we keep listening for the whole app session. This has very little data and changes only on new messages received on the user's thread. It is used to set the chat badge on the tabbar and some other places
We have a screen with the user's chat thread list, sorted by last message and paginated to most recent ones. User's can request more by scrolling down but by default only 20 get downloaded. This list is only observed when the user is inside the chat list screen, and the observer released when he leaves. The list does not contain the messages, only the thread info (which contains a copy of the last one)
When user gets into a specific thread, then we start observing messages of that thread. We release the observer as soon as he leaves the screen.
Users also get a push notification when a new message is added to any thread (except if he is already viewing the thread detail screen)
@angelolloqui really nice write up, thanks. Taking the time to explain some of your initial design decisions, particularly with the likes of Firebase, was insightful. It would be great to know how things progressed as it scaled further and whether you changed course on any of those design decisions.
I also had a specific question on how you chose to handle receiving new messages efficiently, when the user has the app open, given that each user can be involved in multiple threads. For example, did you create a "child_added" listener for each user-thread when the user opened the app, or only listen to the thread the user is currently viewing (perhaps combined with background notifications for non-active threads), or another approach entirely?
Hi @codi0 ! I'm glad you found it useful. Regarding your questions:
We still have the same design in place. We have done some minor improvements on the chat but nothing that affects the design decisions exposed in here. So far, the chat has grown a lot (a 10x since the post, with more than 1K messages a day), and we are now fully consuming the free tier and starting to pay. We are still not paying much but if we continue this trend we will have to make some design changes in a not so far future (not sure how yet).
I am not sure I understand your second question fully, but what we do to handle the multiple threads is:
Good to hear it's growing nicely. Hope that continues! And thanks for answering my slightly unclear question with so much detail, very helpful. :)