Друзья, всем привет! Меня зовут Игорь Карелин, я frontend-разработчик в компании Домклик. В прошлой части мы разобрали, как создать аутентификацию с помощью библиотеки Passport, а сегодня мы рассмотрим такие манипуляции, как добавление, редактирование, удаление и получение задач. Для начала давайте разберём HTTP и некоторые типы запросов. HTTP (англ. HyperText Transfer Protocol, «протокол передачи гипертекста») — протокол прикладного уровня передачи данных, изначально — в виде гипертекстовых документов в формате HTML, а в настоящее время используется для передачи произвольных данных. Метод HTTP — последовательность из любых символов, кроме управляющих и разделителей, указывающая на основную операцию над ресурсом. Для разграничения действий с ресурсами на уровне HTTP-методов и были придуманы следующие варианты: GET — получение ресурса; POST — создание ресурса; PUT — обновление ресурса; DELETE — удаление ресурса. Это основные методы которые мы будем использовать в нашем приложении. С полным списком и подробнее о HTTP можно почитать по ссылке. Давайте запустим Docker и наше приложение, дополнив структуру с помощью команд Nest CLI. При работе через Nest CLI автоматически импортируются файлы в модули, что очень удобно. Далее руками создадим несколько файлов: task.dto.ts, task.interface.ts и task.model.ts Теперь поговорим о том, какой минимальный набор данных нам потребуется в задаче, и опишем нашу схему. Чтобы не переусложнять нашу модель, я предлагаю ограничиться заголовком, подробным описанием, датами создания и обновления. Для начала опишем interface. Приступим! Тут всё просто, мы пишем, что у нас будет заголовок и описание. Далее создадим модель и схему в файле task.model.ts. В декораторе @Schema мы указываем название коллекции в базе данных и передаём timestamps: true , при создании и обновлении данных в коллекции у нас будут автоматически записываться даты. После создания задачи это будет выглядеть так:  Далее мы создаём класс TaskModel  и наследуем от интерфейса TaskInterface, создав при этом обязательные поля с заголовком и описанием. Вызываем SchemaFactory.createForClass, передав в качестве аргумента TaskModel, и экспортируем полученное значение. После этого не забываем добавить в модуль task.module.ts. В прошлой части мы подробно разобрали, что такое контроллеры и для чего они нужны. Давайте определимся с корневым маршрутом для задачи и зададим ему путь /api/tasks. Нам потребуются следующие методы:  POST — создание задачи; PUT — изменение задачи; DELETE — удаление задачи; GET — получение одной или всех задач. В NestJs методы описываются с помощью декораторов, что очень удобно. Доступ к манипуляциям с данными есть только у пользователя, который ранее авторизовался и создал задачи под своей учётной записью.  Итак, мы описали файл контроллера с импортом сервисов, проверкой и методами, перечисленными ранее. Обратите внимание на декораторы @UseGuards(AuthGuard('jwt'))  и @Req() req: благодаря ранее созданной аутентификации можно получать данные пользователя при каждом запросе к маршруту. Мы можем проверять доступ к задачам, которые относятся только к текущему пользователю. Подробнее изучить логику выборки конкретных данных, относящихся к пользователю, мы можем в сервисе. В сервисах у нас написана логика работы с данными и CRUD-операции. Перед тем как взглянуть на сервис задач, давайте посмотрим, какой код добавился и для чего он нужен. В ранее созданныйUserModel в 17 строку добавили отношение «одни ко многим», чтобы можно было с лёгкостью определить, какие задачи доступны конкретному пользователю.  После этих манипуляций при получении данных пользователя мы увидим ID задач, относящихся к нему. Выглядит это так:   Далее мы дополнили UsersService методами добавления и удаления ID задач из модели пользователя. Методы представлены в 65 и 69 строках.  Давайте перейдём к сервису задач.  В сервисе представлены методы добавления, изменения, получения и удаления задач, а также приватный метод для проверки наличия запрашиваемой задачи у пользователя. Я опишу каждый метод подробнее.  createTask — метод создания задач. При вызове мы получаем ID пользователя, задачу с заголовком и описанием, далее записываем в базу и в ответ получаем объект с ID задачи. Потом вызывается метод setTaskToCurrentUser, в который передаётся ID пользователя и ID задачи, а затем ищется пользователь по ID и запись ID задачи найденному пользователю.  getAllTasks — тут всё просто: передаётся список ID задач текущего пользователя и дальнейшее их получение. getTask — получаем список задач текущего пользователя и запрашиваемую задачу, далее проверяем, есть ли она у пользователя. Если есть — возвращаем задачу, если нет — вернём пустой ответ. deleteTask — как и в getTask, получаем список задач текущего пользователя и запрашиваемую задачу, далее проверяем, есть ли она у пользователя. Если есть — удаляем ID задачи из модели пользователя и удаляем саму задачу, иначе возвращаем ошибку. updateTask — проверяем наличие задачи у пользователя. Если она есть, изменяем её на новую, иначе возвращаем ошибку, что задача не найдена. taskExistence — последний представленный приватный метод, который проверяет, есть ли текущий ID задачи у пользователя. На заключительном этапе нам необходимо проверить, что все ранее созданные данные добавлены в модуль.   В этом файле мы импортировали UsersModule для использования UsersService в TasksService. Добавили сервис, контроллер и модель задач для работы с базой данных. Не забываем проверить, что TasksModule присутствует в AppModule. На этом пока остановимся. Мы поговорили о HTTP и разработали методы работы с задачами. В следующей, финальной части мы напишем весь фронтенд. Спасибо за внимание! Исходный код доступен по ссылке.