UX/UI modernisation
Chat System: How to Manage Conversation (Part Two)
Chat System: How to Manage Conversation
Our goal for this project is to provide a chat system for visitors of the website so they can be easily assisted by the website’s owner in our support department. It is essential for the website’s owner to have the ability to customize the chat widget and have a powerful integration of support in the back office with all visitors and user’s information from the website’s database. This means that any of our chat system customers will have a customizable widget for their websites and their own desk/back office that integrates with their own services.
Summary
In general, all messages should be related to a conversation entity. Let’s say, for example, a room. The room contains all messages and all participants of the conversation.
There are two ways to create a room:
- The operator manually initializes conversation with the visitor who has no open rooms.
- The visitor initializes an open conversation and one of the free operators joins in the room.
There is only one way to close a room:
- The operator has permission to close the conversation, or room. Any new messages must then be started in a new room.
It is possible that some conversations will take a long time. In this case, the visitor will have one room open through all sessions of conversation until the room is closed by the operator.
There are three collections in Firebase Realtime Database. These are:
- Room-Metadata – All rooms are stored with ID, state and participants.
- Room-Messages – All messages are stored as per the room ID.
- Users – All users with an active room or who are online are stored.
Power of Firebase Rules
The primary and advantageous feature of this database is its ability to define strict access to each field of data. For example, non-participants in a particular conversation will not have any access to read the messages in that conversation and only operators or administrators are able to close a conversation.
Conclusion
Firebase rules are powerful and vital. They give you the chance to define very strict security protocols for any part of data. In our case, we defined all fields strictly and in their types. The rules also define the access to read and write according to the user role (See Part 1 for more information about roles) and according to the already existing part of data.
Cons
- Takes some time to design the scheme of data properly.
- Is not as powerful as the usual imperative rules defined by server-side codes.
Pros
- It is simple.
- Does not need important server-side codes to handle access.
In the next article, we show you how to design a JavaScript library.
References
Top articles
- Which OS Versions Should My App Support for Optimal Performance?
- 5 Key Technology Issues in Healthcare Industry
- Complete Guide to Microsoft Dataverse
- Key Success Factors for Technology Modernization
- Cloud Agnostic Applications: Why Do You Need It?
- Is Flutter ready for Enterprise mobile apps?
- 7 ERP Implementation Challenges and How To Overcome Them
- Understanding Technical Debt: Definition, Impact & Tips for Businesses
Related Articles
UX/UI modernisation
Chat System: Firebase, Authentication and Roles (Part One)
Volodymyr Terebus
June 14, 2018
UX/UI modernisation
Chat System: How to design a library (Part Three)
Volodymyr Terebus
December 5, 2018
Game Development
HTML5 Game Optimization: Proven Techniques for Speed and Efficiency
Andrii Barvynko
September 24, 2024
Game Development
The Art and Science behind Design and Architectural Patterns
Andrii Barvynko
November 7, 2018
Startup and MVP
Proof of Concept vs. Prototype vs. Minimum Viable Product
Volodymyr Terebus
December 13, 2018
