fullStackChatApp
1.0.0
AVERTISSEMENT: il reste peu de choses pour terminer l'application. Il doit ajouter les écrans d'enregistrement des utilisateurs, les notifications en arrière-plan et les mises à jour de données des demandes d'amis et de nouveaux amis via des sockets.
Pour l'instant, l'application se développe depuis un mois, un mois au cours de laquelle il a passé des périodes en mise en œuvre de chaque exigence de base.
À la fin des exigences de base, les nouvelles exigences détectées et les autres plus complexes continueront d'être mises en œuvre.
La création de l'application a commencé par des croquis simples de l'interface graphique. Ces croquis ont été perdus pour cette raison que je ne peux pas les mettre ici. Veuillez consulter la dernière section où les photos du projet sont présentées.
L'interface graphique a été implémentée lors de l'utilisation de données de test statique.
Ceci est le premier projet qui a de loin une grande différence avec les anciens que j'ai faits. J'ai essayé de la manière la plus logique et la plus optimale possible d'utiliser des modèles de conception pour avoir du code propre et protéger la logique métier.
Dans une limite de temps, la conception a été mise en œuvre, la conception qui devait être un peu modifiée (seulement les classes liées aux messages) en raison des limites de la ruche.
Pour donner une application rapide et optimale, j'ai décidé d'enregistrer les messages dans la mémoire de l'appareil. Pour ce faire d'une manière, j'ai utilisé l'outil Hive, qui sert de base de données NOSQL locale.
En tant que solution optimale, chaque fois que de nouveaux messages arrivent, je les enregistrerai dans l'appareil, ainsi que dans le RAM afin que l'écran de chat n'ait pas à faire attendre l'utilisateur. Seul le dernier message des conversions existantes de l'appareil sera enregistré dans le RAM.
Ici également, il convient de noter que les images de profil des utilisateurs seront stockées sur l'appareil de l'utilisateur, tandis que les adresses des images locales seront stockées dans le RAM.
Pour démontrer la logique du serveur, consultez l'image ci-dessous.
Regardez l'image, qui simule une session d'un utilisateur qui envoie une demande d'ami à un autre utilisateur.
L'exemple a été donné afin de voir quand l'utilisation de WebSockets serait nécessaire et quand l'utilisation de l'API REST.
Les opérations en temps réel telles que l'envoi de messages et de demandes d'amis utiliseront les websockets tandis que les opérations comme l'ouverture d'une session et la mise à jour des données d'un utilisateur utiliseront l'API REST.
C'est la section qui reste à polir. Il manque principalement d'optimiser le code API REST (d'une manière plus correcte), d'ajouter de nouvelles méthodes à la pièce des canaux pour ajouter de nouvelles notifications et ajouter des méthodes à l'API REST et aux canaux pour que les utilisateurs puissent s'inscrire.
Pour donner une meilleure expérience utilisateur (au sens de la vitesse), il était nécessaire d'utiliser une base de données NoSQL, car de cette manière, les données de l'utilisateur sont accessibles plus rapidement.
De toute évidence, cette pensée ne peut pas être correcte, car comme il existe des relations entre les identités, les données d'autres utilisateurs liées à l'utilisateur principal devront être mises à jour.
Bientôt, cette section peut être modifiée et rénovée. Pour l'instant, la logique du modèle est très basique, chaque utilisateur contiendra des messages qui n'ont pas encore été lus, des noms d'utilisateur qui sont leurs amis, des noms d'utilisateur qui ont envoyé des demandes d'amis et des données telles que le nom d'utilisateur, les images (cryptées) et plus encore.
Il convient également de noter que Django n'a pas encore officiellement des intégrations de base de données NoSQL, pour cette raison, j'ai utilisé l' outil Djongo , qui est très curieux et très utile, il applique des modèles SQL à MongoDB pour protéger la logique métier.
