Posted on Aug 15 In the previous part, I provided an overview of our powerful chat application which offers real-time multilingual translations.In this part, we will delve into the backend how we set up all the routes, and also how we use socketIO to get real-time functionalities.Our application revolves around three essential models: User, Conversation, and Message.In essence, our route structure is designed to achieve our ultimate goal of displaying messages. This involves a series of HTTP requests:Making a POST request to authenticate and log in the userMaking a GET request to get comprehensive information about other users.Making a GET to fetch both the conversation and associated messagesLet’s start with the User model. Within this model, each user will maintain a list of their conversations with others. Additionally, users will be able to set their preferred translated language during sign-up, thus enhancing the multilingual communication experience.Moving on to the Conversation model, it serves as a container for all the messages exchanged within a particular conversation. Moreover, the model also associates the users who are part of that conversation. This setup ensures that messages are organized and accessible within the context of their relevant discussions, while maintaining a clear link to the users involved.Lastly, let’s look at the Message model. An important aspect of this model is that it includes the sender’s information. This addition proves invaluable in distinguishing between the sender and recipient of each message, which in turn facilitates the seamless configuration of APIs and enhances the overall communication process.Moving forward to the controllers, where we’ll navigate through the implementation of various routes.While I’ll skip detailing the signup, login, and user profile update routes, I’d like to highlight the user-related routes. Specifically, we’ll discuss the process of fetching users from our database.One of the very first questions, how can we display the friend lists?In response, we devised a strategic approach: categorization of users into two distinct groups: those who are logged in and have never been contacted, and those with whom you’ve engaged in previous conversations. This segmentation enhances the user experience and helps organize interactions effectively.From this point onward, we can retrieve the unique conversation IDs and seamlessly showcase each individual conversation, which facilitates the comprehensive display of all messages that our logged-in user has exchanged with others.Equally crucial is the route dedicated to creating new messages, a feature that defines the essence of our application. Through this functionality, users can receive translated versions of their messages, aligned with their chosen language preference in their profiles.Messages are classified into two types: text messages and translated voice messages, with the latter being stored using Cloudinary to store URLs for easy retrieval and playback.If you want to send a voice message, you can use the route below.And finally here comes the best part: infusing the app with real-time capabilities through SocketIO. Before delving into the mechanics, let’s unravel the rationale behind employing SocketIO and the reasons that set it apart from traditional real-time communication implemented through REST APIs.1/ REST APIs operate in a stateless manner, treating each GET or POST request in isolation without maintaining any continuous connection.→ In our context, where we’re striving for REAL-TIME updates, using REST APIs would necessitate incessant requests to the server,even if there might not be new messages. This approach is resource-intensive and inefficient.2/ Enter SocketIO, empowering us to establish a persistent connection between two users that remains active until the users opt to disconnect.The server, in turn, automatically updates and pushes new messages to the users without necessitating a site reload or any additional actions.Certainly, let’s break down the process. Firstly, we’ll initiate the connection using the io.on("connection") method, a built-in feature of SocketIO.The following code snippet helps us track users who are online. Whenever a user connects to our app (by logging in), their ID is sent from the front end to SocketIO, and we manage them through a Map.It’s crucial to use a Map to avoid user duplication. When we emit the data back to the front end, we’ll also need to convert it to an array, as Maps and Sets need manual serialization for compatibility.The nextfour lines of code are crucial for enabling real-time messaging in our application.As a quick recap, we have a Map named onlineUsers that keeps track of connected users. Each user has a unique socket ID associated with them. When a user successfully connects, they receive a socket ID.Here’s how the messaging process works:When you want to send a message to a specific user, you send the recipient’s ID from the front end to the backend as data.With the recipient’s ID, you can retrieve their socket ID from the onlineUsers map.Once you have the recipient’s socket ID, you emit the message to that socket ID, which effectively sends the message to the intended recipient.This process ensures that messages are sent directly to the recipient in real-time. Here’s the basic structure of how this works:Lastly, when a user disconnects from the app, we can use socket.on("disconnect")to remove them from the list of online users and emit the updated list to the frontend to reflect the current online status of users.You can find comprehensive information about error handling, CORS configuration, database integration, and the array of packages employed throughout our project by exploring our repository at: https://github.com/Talckatoo.Stay tuned for Part 3 on how we’ve built the front-end aspects of our project.Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well Confirm For further actions, you may consider blocking this person and/or reporting abuse Sm0ke - Jul 5 Akshat Jain - Jul 5 Hasnain01-hub - Jun 5 Odewole Babatunde Samson - Jul 4 Once suspended, miminiverse will not be able to comment or publish posts until their suspension is removed. Once unsuspended, miminiverse will be able to comment and publish posts again. Once unpublished, all posts by miminiverse will become hidden and only accessible to themselves. If miminiverse is not suspended, they can still re-publish their posts from their dashboard. Note: Once unpublished, this post will become invisible to the public and only accessible to miminiverse. They can still re-publish the post if they are not suspended. Thanks for keeping DEV Community safe. Here is what you can do to flag miminiverse: miminiverse consistently posts content that violates DEV Community's code of conduct because it is harassing, offensive or spammy. Unflagging miminiverse will restore default visibility to their posts. DEV Community — A constructive and inclusive social network for software developers. With you every step of your journey. Built on Forem — the open source software that powers DEV and other inclusive communities.Made with love and Ruby on Rails. DEV Community © 2016 - 2023. We're a place where coders share, stay up-to-date and grow their careers.