fullStackChatApp
1.0.0
警告：幾乎沒有完成應用程序的剩餘時間。它需要添加用戶註冊屏幕，後台通知以及朋友請求的數據更新和通過插座的新朋友。
目前，該應用程序已經開發了一個月，一個月，它經歷了實施每個基本要求的時間。
完成基本要求後，檢測到的新要求以及其餘更複雜的要求將繼續實施。
應用程序的創建始於圖形接口的簡單草圖。由於這個原因，這些草圖丟失了，我不能把它們放在這裡。請查看顯示項目照片的最後一部分。
使用靜態測試數據時實現了圖形接口。
這是迄今為止與我所做的舊項目有很大差異的第一個項目。我嘗試以最合乎邏輯，最佳的方式使用設計模式以具有乾淨的代碼並保護業務邏輯。
在一個時間限制中，設計了設計，由於Hive的局限性，必須對設計進行一些更改（僅與消息相關的類）。
為了提供快速，最佳的應用程序，我決定將消息保存在設備內存中。為了以某種方式使用hive工具，該工具是本地NOSQL數據庫。
作為最佳解決方案，每次新消息都會出現時，我都會將它們保存在設備中以及RAM中，以便聊天屏幕不必使用戶等待。設備現有轉換的最後一條消息將保存在RAM中。
同樣，應該注意的是，用戶的配置文件圖像將存儲在用戶的設備上，而本地圖像的地址將存儲在RAM中。
要演示服務器邏輯，請參見下面的圖像。
查看圖像，該圖像模擬了將朋友請求發送給另一個用戶的用戶的會話。
給出了示例，以查看何時需要使用Websocket以及何時使用REST API。
諸如發送消息和朋友請求之類的實時操作將使用Websockets，而諸如打開會話和更新用戶數據之類的操作將使用REST API。
這是尚待拋光的部分。主要缺少的是優化REST API代碼（以更正確的方式），將新方法添加到頻道部分以添加新的通知並將方法添加到REST API和頻道中，以供用戶註冊。
為了提供更好的用戶體驗（從速度意義上講），有必要使用NOSQL數據庫，因為這樣可以更快地訪問用戶的數據。
顯然，這種想法不能說是正確的，因為由於身份之間存在關係，因此必須更新與主要用戶相關的其他用戶的數據。
很快，本節可以更改和改建。目前，模型的邏輯非常基本，每個用戶將包含尚未讀取的消息，用戶名是他們的朋友，用戶名和數據（例如用戶名，圖像（加密）等）的用戶名。
還應注意的是，Django尚未正式具有NOSQL數據庫集成，因此，我使用了Djongo工具，這非常好奇且非常有用，它將SQL模型應用於MongoDB來保護業務邏輯。
