fullStackChatApp
1.0.0
Предупреждение: осталось мало, чтобы закончить приложение. Он должен добавить регистрационные экраны пользователя, уведомления в фоновом режиме и обновления данных запросов дружбы и новых друзей через сокеты.
На данный момент приложение разрабатывается в течение месяца, в течение месяца, когда она проходила периоды времени, реализуя каждое основное требование.
После завершения основных требований обнаружены новые требования, а оставшиеся более сложные будут реализованы.
Создание приложения началось с простых эскизов графического интерфейса. Эти наброски были потеряны по этой причине, я не могу их поместить здесь. Пожалуйста, смотрите в последнем разделе, где показаны фотографии проекта.
Графический интерфейс был реализован при использовании статических тестовых данных.
Это первый проект, который, безусловно, имеет большое значение от старых, которые я сделал. Я пробовал наиболее логичным и оптимальным способом использовать шаблоны проектирования, чтобы иметь чистый код и защитить бизнес -логику.
В ограниченном сроке была реализована дизайн, который должен был быть немного изменен (только классы, связанные с сообщениями) из -за ограничений уляя.
Чтобы дать быстрое и оптимальное приложение, я решил сохранить сообщения в памяти устройства. Для этого я использовал инструмент улей, который служит локальной базой данных NOSQL.
Как оптимальное решение, каждый раз, когда появятся новые сообщения, я буду сохранять их в устройстве, а также в оперативной памяти, чтобы экран чата не должен заставлять пользователя ждать. Только последнее сообщение о существующих преобразовании устройства будет сохранено в оперативной памяти.
Также здесь следует отметить, что изображения профиля пользователей будут храниться на устройстве пользователя, в то время как адреса локальных изображений будут храниться в оперативной памяти.
Чтобы продемонстрировать логику сервера, см. Изображение ниже.
Посмотрите на изображение, которое имитирует сеанс пользователя, который отправляет запрос в друзья другому пользователю.
Пример был приведен для того, чтобы увидеть, когда потребуется использование веб -токков и когда использование API REST.
Операции в режиме реального времени, такие как отправка сообщений и запросов в друзья, будут использовать WebSockets, в то время как такие операции, как открытие сеанса и обновление данных пользователя, будут использовать API REST.
Это раздел, который еще предстоит полировать. В основном отсутствует оптимизация кода API REST (более правильным способом), добавьте новые методы в часть каналов, чтобы добавить новые уведомления и добавить методы в API и каналы REST для регистрации пользователей.
Чтобы обеспечить лучший пользовательский опыт (в смысле скорости), было необходимо использовать базу данных NOSQL, потому что таким образом можно получить доступ к данным пользователя быстрее.
Очевидно, что эта мысль нельзя сказать, что является правильной, потому что, поскольку существуют отношения между идентификаторами, данные других пользователей, связанных с основным пользователем, должны быть обновлены.
Вскоре этот раздел может быть изменен и реконструирован. На данный момент логика модели очень простая, каждый пользователь будет содержать сообщения, которые еще не прочитали, имена пользователей, которые являются их друзьями, имена пользователей, которые отправили запросы в друзья и такие данные, как имя пользователя, изображения (зашифрованные) и многое другое.
Следует также отметить, что у Django еще не есть интеграция с базой данных NOSQL, по этой причине я использовал инструмент Djongo , который очень любопытный и очень полезный, он применяет модели SQL к MongoDB для защиты бизнес -логики.
