fullStackChatApp
1.0.0
Warnung: Es ist nur wenig übrig, um die Anwendung zu beenden. Es muss die Benutzerregistrierungsbildschirme, Benachrichtigungen im Hintergrund und die Datenaktualisierungen von Freundschaftsanfragen und neuen Freunden über Sockets hinzufügen.
Derzeit entwickelt sich der Antrag seit einem Monat, einem Monat, in dem sie Zeiträume durchführte, um jede Grundvoraussetzung umzusetzen.
Nach Abschluss der grundlegenden Anforderungen werden die neuen Anforderungen und die verbleibenden komplexeren Anforderungen weiterhin implementiert.
Die Erstellung der Anwendung begann mit einfachen Skizzen der grafischen Schnittstelle. Diese Skizzen gingen aus diesem Grund verloren, ich kann sie nicht hierher bringen. Bitte beachten Sie den letzten Abschnitt, in dem Fotos des Projekts angezeigt werden.
Die grafische Schnittstelle wurde während der Verwendung statischer Testdaten implementiert.
Dies ist das erste Projekt, das bei weitem einen großen Unterschied zu den alten hat, die ich gemacht habe. Ich habe auf die logischste und optimalste Weise versucht, Designmuster zu verwenden, um saubere Code zu haben und die Geschäftslogik zu schützen.
In einer zeitlichen Begrenzung wurde das Design implementiert, das ein bisschen geändert werden musste (nur die Klassen im Zusammenhang mit Nachrichten) aufgrund der Einschränkungen des Bienenstocks.
Um eine schnelle und optimale Anwendung zu geben, habe ich beschlossen, die Nachrichten im Gerätespeicher zu speichern. Dazu habe ich das Hive -Tool verwendet, das als lokale NoSQL -Datenbank dient.
Als optimale Lösung speichere ich jedes Mal, wenn neue Nachrichten in das Gerät sowie im RAM kommen, damit der Chat -Bildschirm nicht zum Warten des Benutzers dazu bringen muss. Nur die letzte Nachricht der vorhandenen Konvertierungen des Geräts wird im RAM gespeichert.
Auch hier ist zu beachten, dass die Profilbilder der Benutzer auf dem Gerät des Benutzers gespeichert werden, während die Adressen der lokalen Bilder im RAM gespeichert werden.
Um die Serverlogik zu demonstrieren, siehe Bild unten.
Schauen Sie sich das Bild an, das eine Sitzung eines Benutzers simuliert, der eine Freundschaftsanfrage an einen anderen Benutzer sendet.
Das Beispiel wurde gegeben, um zu sehen, wann die Verwendung von Websockets benötigt würde und wann die Verwendung von REST -API.
Echtzeit-Vorgänge wie das Senden von Nachrichten und Freundschaftsanfragen verwenden WebSockets, während Vorgänge wie das Öffnen einer Sitzung und die Aktualisierung der Daten eines Benutzers die REST-API verwenden.
Dies ist der Abschnitt, der noch poliert werden muss. Es fehlt hauptsächlich, den REST -API -Code (korrekter) zu optimieren, dem Kanäle -Teil neue Methoden hinzuzufügen, um neue Benachrichtigungen hinzuzufügen und den Rest -API und Kanälen für Benutzer zu registrieren.
Um eine bessere Benutzererfahrung (im Sinne von Geschwindigkeit) zu bieten, musste eine NoSQL -Datenbank verwendet werden, da auf diese Weise schneller auf die Daten des Benutzers zugegriffen werden können.
Es ist klar, dass dieser Gedanke nicht korrekt ist, da Daten von anderen Benutzern, die sich auf den Hauptbenutzer beziehen, aktualisiert werden müssen, da es Beziehungen zwischen den Identitäten gibt.
Bald kann dieser Abschnitt geändert und umgebaut werden. Im Moment ist die Logik des Modells sehr einfach. Jeder Benutzer enthält Nachrichten, die noch nicht gelesen wurden, Benutzernamen, die seine Freunde, Benutzernamen sind, die Freundschaftsanfragen und Daten wie Benutzername, Bilder (verschlüsselt) und mehr gesendet haben.
Es sollte auch beachtet werden, dass Django noch nicht offiziell NoSQL -Datenbankintegrationen hat. Aus diesem Grund habe ich das Djongo -Tool verwendet, das sehr neugierig und sehr nützlich ist. Es wendet SQL -Modelle auf MongoDB zum Schutz der Geschäftslogik an.
