Всего необходимо реализовать 4 коллекции для хранения данных. Коллекции были созданы на основе диаграммы «Сущность - связь», проектирование документоориентированной базы данных не требует отвечать стандартам ACID, соответственно нормализация данных для документоориентированных БД необязательна. Данные в MongoDB хранятся в качестве атрибутов в едином документе формата JSON. В такой модели данные оптимизированы для интуитивно понятной разработки и горизонтальной масштабируемости.
Коллекция categories-справочник категорий предметов одежды, где:
«_id»-идентификатор типа «ObjectId».
«category» - строковое значение (название категории, например, «Обувь»).
Коллекция users - содержит сведения обо всех зарегистрированных пользователях, где:
«_id»-идентификатор пользователя. Тип «ObjectId».
«name» - имя пользователя, указанное при регистрации. Тип «String».
«email» - электронная почта пользователя, указанная при регистрации. Тип «String».
«password» - зашифрованная строка-токен, содержит пароль. Тип «String».
«date» - дата регистрации. Тип «Date».
«instagram» - профиль пользователя в Instagram. Тип «String».
«phone» - мобильный телефон пользователя. Тип «String».
«avatar» - ссылка на хранящееся изображение. Тип «String».
Коллекция items- содержит ссылку на документ в коллекции usersи массив поддокументов-товаров, где:
«_id»-идентификатор документа коллекции типа «ObjectId».
«userId» - связка с документом в коллекции «user» по идентификатору. Тип «String» или «ObjectId».
«items» - список всех опубликованных пользователем товаров. Тип «Array».
Массив «items» - это массив поддокументов, каждый из которых имеет следующую структуру:
«_id»-идентификатор типа «ObjectId».
«title»-наименование товара типа «String».
«description»-описание товара. Тип «String».
«userId»-ссылка на автора объявления. Тип «ObjectId».
«category»-ссылка к документу коллекции «categories». Тип «ObjectId».
«photos»-массив ссылок на фотографии, которые иллюстрируют загруженный товар. Тип «Array». Внутри объекты типа «String».
«tags»-массив тегов для описания товара. Тип «Array». Внутри хранятся объекты «tag» с типом «String» и идентификатором «_id» типа «ObjectId».
Коллекция likedItems - содержит ссылку на документ в коллекции users, массив поддокументовdislike, где хранятся «_id» товаров, которые не понравились пользователю и массив поддокументовpairs, где хранятся сведения о пользователе, которому текущий пользователь подошел. Коллекция описана следующим образом:
«_id»-идентификатор документа коллекции типа «ObjectId».
«dislike» -поддокумент, где хранятся идентификаторы товаров, которые не понравились пользователю (необходимо для формирования ленты товаров). Тип «Array». Внутри находятся объекты типа «String».
«userId» - идентификатор пользователя, для которого отслеживаются «pairs» и «dislike». Тип «String».
«pairs» -поддокумент, где хранятся понравившиеся товары. Тип «Array».
При этом в каждом объекте массива «pairs» находится:
«items» - поддокумент, который хранит идентификаторы понравившихся товаров. Тип «Array».
Вподдокументе хранятся ссылки на товары типа «ObjectId».
«_id» - идентификатор элемента массива «pairs». Тип «ObjectId».
«userId» - идентификатор пользователя, которому принадлежат эти товары. Тип «String».
Несмотря на то, что используется нереляционная база данных, необходимо выделить сущности.Основные сущности - это «Пользователь», «Товар» и «Обмены». Любой обмен состоит из пары пользователей и пары товаров соответственно (чтобы пара была подобрана, необходимо, чтобы пользователю А понравился товар Б, и наоборот). Также обмен может отслеживаться с помощью статусной модели. Каждый пользователь имеет отношение к двум спискам товаров: товары, которые опубликовал сам пользователь, и товары, которые понравились пользователю во время пролистывания ленты. Сущности «Тип товара» и «Стиль» достаточно условны, они содержат описательные данные о загружаемом товаре (предмете гардероба). Для каждого пользователя формируется «Рейтинг». Рейтинг высчитывается на основе успешных/неуспешных обменов, количества товаров и заполненности профиля. Модель данных представлена ниже. (см.рисунок 10).
Рис. 10. Диаграмма «Сущность - связь» для приложения обмена одеждой
Ввиду своей иерархической структуры хранения данных MongoDB позволит делать быстрые операции над коллекциями, документами, т.к. объектный язык запросов в этом случае намного эффективнее стандартных SQL-запросов.
Для манипуляции с данными необходимо разработать функции, которые позволяют:
Организовать операции CRUD для сущностей «Товар» и «Пользователь».
Соотнести списки понравившихся товаров для создания сущности «Обмен».
Отобразить контактные данные тех пользователей, которым взаимно понравились опубликованные предметы одежды.
Отслеживать, какие товары пользователь уже просмотрел, чтобы формировать качественную выдачу на главном экране.
В будущих версиях сервиса для свободного обмена одеждой также планируется:
Отслеживать статусную модель сущности «Обмен».
Высчитывать переменную «Рейтинг» в сущности «Пользователь» в зависимости от совершенных обменов.
Отслеживать местоположение пользователя (а соответственно и товаров) для более удобного поиска и настройки ленты просмотра.
Выводы по главе 3
В третьей главе выделены основные нефункциональные требования к приложению, а именно: адаптивность, кроссбраузерность, соответствие дизайн-системе продукта (общий унифицированный стиль). Также определены принципы визуального проектирования интерфейса: иерархия, фокус, контраст, выравнивание и баланс элементов, баланс пространства. Далее спроектированы и описаны экраны пользовательского интерфейса, которые полностью покрывают ранее смоделированный бизнес-процесс обмена одеждой. Из получившихся экранов сформирована диаграмма переходов между экранами - спроектирована навигация приложения.
Для выбранной СУБД во второй главе была составлена модель данных в виде диаграммы «сущность - связь». Описано представление коллекций и документов, которые будут разработаны далее средствами СУБД MongoDB. Описано четыре коллекции. Также перечислены виды функций, которые необходимо разработать для манипуляции с данными.
4. Разработка сервиса для свободного обмена одеждой
В четвертой главе представлен обзор процесса разработки серверной части, в том числе настройка маршрутизации и подключение к базе данных, представлен процесс разработки компонентов на клиентской части, управление состоянием приложения с помощью технологии redux.Описан процесс реализация базы данных, показан процесс и результаты тестирования запросов к базе данных, подключение к удаленному серверу MongoDBAtlas и реализация моделей данных, необходимых для корректной работы приложения. интерфейс шардинг информационный серверный
Реализация базы данных
В разделе приведен процесс и технология создания схем (моделей данных) для взаимодействия с коллекциями базы данных. Далее проиллюстрирован процесс тестирования созданных запросов к базе с помощью инструмента Postman.
Настройка подключения и развертка удаленного сервера базы данных
Необходимо установить MongoDBна компьютер, на котором ведется разработка. Установочный дистрибутив MongoDB«весит» 263МБ для операционной системы Windows 10.
Сама база данных будет развернута на удаленном сервере с помощью облачного сервиса MongoDBAtlas. В рамках бесплатного тарифа M0 MongoDBAtlasпредоставляет 500 мегабайт для хранения запросов и коллекций документов. Подключиться к удаленной базе данных можно и через локальный клиент MongoDBCompass. Для того, чтобы можно было получить доступ к удаленной базе данных необходимо добавить IPадрес в список разрешенныхIPадресов, создать пользователя и назначить ему соответствующие права доступа. Затем получить строку подключения MongoURI. Эту строку можно использовать в приложении.
Получать данные и отображать их очень просто. ВMongoDB достаточно гибкий JSON-формат документов и низкий порог освоения технологии: не нужно специальных знаний языка SQL. Таким образом, простая логика и простые запросы реже создают проблемы.
Для того, чтобы подключить базу данных к серверной части, необходимо знать строку подключения (MongoURI) и вызвать метод «.connect()», который принимает MongoURI (для удобства MongoURI вынесен в отдельный модуль), затем можно указать дополнительные параметры. Метод «.connect()»возвращает объект типа «Promise», где потребитель «.then()»сообщает в консоли сервера, что подключение было успешно, или в случае ошибки (потребитель «.catch()») записывает ошибку в консоль и завершает процесс подключения.
const mongoose = require('mongoose');
const db = require('./config/keys').mongoURI;
//db подключение
mongoose
.connect(db, {
useNewUrlParser: true,
useUnifiedTopology: true,
useFindAndModify: false
})
.then(() => console.log('Подключено к базе!'))
.catch((err) => {
console.log('Подключение невозможно');
console.log(err);
process.exit();
});
Описание моделей данных
Для работы с MongoDB вNode.js была использована технология Mongoose. Она позволяет объектно моделировать сущности для большего удобства работы с данными. Mongooseпозволяет реализовать валидацию, строить запросы и настраивать бизнес логику. Mongooseустанавливается с помощью пакетного менеджера NPM, а затем подключается в серверной части следующим образом: «constmongoose = require('mongoose');».
В серверной части каждая модель описана отдельным файлом, который находится в папке «Models». Всего для приложения реализовано шесть схем: «ItemSchema», «CategorySchema», «ChangeSchema», «LikedItemSchema», «LikedItemCollectionSchema», «UserSchema».
Пример описания схемы сущности «Items». Каждый раз, когда в контроллере необходимо будет обращаться к сущности, необходимо использовать экспортированный модуль «Items» (т.е. экспортированную схему). Схема представляет собой JavaScriptобъект, для полей которого можно настроить различные типы, ограничения, и значения по умолчанию.
const mongoose = require('mongoose');
const Schema = mongoose.Schema;
const CategorySchema = require('./Category');
const ItemSchema = new Schema({
_id: Schema.Types.ObjectId,
userId: Schema.Types.ObjectId,
title: String,
category: String | CategorySchema,
description: String,
tags: [
{
tag: String,
},
],
photos: [String],
});
const ItemsSchema = new Schema({
userId: {
type: String,
required: true,
},
items: [ItemSchema],
});
module.exports = Items = mongoose.model('items', ItemsSchema);
Описание всех моделей данных находится в приложении Д.
Процесс тестирования запросов к базе данных
Для тестирования запросов был использован сервис Postman.Postman предназначен для проверки запросов с клиента на сервер и получения ответа от бэкенда. Алгоритм работы с postmanпри тестировании всех запросов одинаков.
В ходе работы были использованы и протестированы следующие типы запросов: «POST», «GET», «PUT» или «DELETE». Каждый тестируемый адрес запроса состоит из двух частей: адрес хоста (в данном случае «http:/localhost:5000»), иадрес конечной точки, например, «/api/users/login».
Postmanпозволяет ввести данные для тестирования: во вкладке «Params» можно указать передаваемые параметры запроса. Во вкладке «Body» можно задать тело запроса, т.е. что именно будет отправлено на сервер.
Результат запроса всегда представлен в формате текста, JSON или HTML-страницы.
Рассмотрим пример тестирования регистрации пользователя. Для этого по указанному URL («http:/localhost:5000/api/users/register»)отправляются в теле запроса поля из формы регистрации: «Имя», «Email», «Пароль» и «Повторите пароль». Поле «Повторите пароль» перед сохранением в базе данных сравнивается с полем «Пароль», если они не одинаковы, сервер возвращает сообщение пользователю, что пароль должны совпадать. В данном случае пароли верны, Emailвведен корректно, пользователя с такими же параметрами еще не существует в базе данных, а следовательно, можно зарегистрировать пользователя. Сервер возвращает положительный результат (STATUS 200 OK) и возвращает объект в формате JSON. Это новый пользователь.
Разработка серверной части сервиса
В разделе описан процесс разработки серверной части сервиса для свободного обмена одеждой, используя технологии Node.jsи Express.js. Исходный код серверной части опубликован в репозитории на GitHub:https://github.com/plastya-flomaster/swop-backend.
Стартовая конфигурация сервера
Инициализация проекта выполнена с помощью пакетного менеджераNPM. Команда npminit позволяет инициализировать проект следующим образом:
Рис. 11. Инициализация проекта с помощью команд менеджера NPM
Для работы также потребовались следующие пакеты. Каждый пакет также установлен с помощью пакетного менеджера NPMкомандой «npminstall<Имя библиотеки>»:
bcryptjs: используется для хеширования паролей, перед записью в базу данных.
body-parser: промежуточное программное обеспечение, чтобы разбирать и считывать входящие запросы (тело запроса).
express: фреймворк для Node.js, чтобы реализовать маршрутизацию, обработку запросов, и формирование ответов с сервера.
jsonwebtoken: утилита для авторизации.
mongoose: библиотека для взаимодействия с MongoDB в объектном стиле.
passport: аутентифицирует запросы, с помощью плагинов-стратегий (в работе будет использоваться плагин passport-jwt).
passport-jwt: используется для аутентификации с помощью JSON Web Token (JWT);
validator: библиотека с инструментами для валидации полей.