Possible Improvements - nonduality345/Convos GitHub Wiki

While working on this code I realized I could featurize this indefinitely. Below are some improvements that I would consider making to the current code base to make this a much more robust application:

• Currently, deleting conversations deletes them for both the sender and the recipient, which may or may not be the best behavior. If you consider how email works, If I as a sender delete a conversation, that does not imply that the conversation is deleted on the recipient's side. To rectify this, I would change the database to have two columns for deleting: one for the sender and one for the recipient. Retrieving Convos would be a little more involved: requesting a list of Convos, for each, the application would need to determine if the user is the sender or the receiver for the Convo and then check the column to see if it is deleted by the user. Also, business logic would need to be taken into consideration. If I, as a creator of a Convo, made a mistake and included the wrong person, maybe I would like to delete it for both myself and the recipient so that the recipient is not aware of it.

• Currently, when requesting a specific message, the application will retrieve the info for that message and all of its parent messages. This was a feature to allow client applications to display the thread of messages. While this could prove to be handy, it could face some pitfalls, specifically when the number of messages in the hierarchy are significantly large. To rectify this, I would limit the number of messages that are returned in the thread.

• Currently, Convos are between two users only, but it may be nice to be able to include multiple people into the conversation. In this case, I would break out the "Participants" of a Convo into its own table, referring back to the Convo table and the User table with foreign key constraints. This would add some more complexity to the deletion methodology described above.

• Currently, there is no authorization logic involved in identifying the user. Ideally, there would be some sort of OAuth service that this application could leverage to obtain an access token to identify the user.