Удаление поста из блога создание функционала для выполнения операции с помощью Angular и MongoDB


Содержание материала:

Удаление поста из блога: создание функционала для выполнения операции с помощью Angular и MongoDB

Angular 2 – это open source фреймворк для создания мобильных, десктопных и веб-приложений.

Angular 2 хоть и является приемником AngularJS 1.x, но может быть рассмотрен как совершенно новый фреймворк, созданный на основе лучших наработок из AngularJS 1.x. Отсюда пошло изменение в его именовании – теперь используется просто имя Angular, что указывает именно на Angular 2. В свою очередь, имя AngularJS ссылается на прошлую версию AngularJS 1.x. В этой статье мы будем использовать имена Angular и Angular 2 попеременно, но они оба ссылаются на Angular 2.

В данной статье мы создадим небольшое Angular 2 веб-приложение, которое позволит делать следующие вещи:

  • Быстро создавать новые записи, используя поле ввода, простым нажатием клавиши Enter
  • Выбирать статус записи
  • Удалять ненужные записи

По этой ссылке доступно демо приложения. Все исходные коды приложения можно найти в GitHub репозитории.

Итак, давайте начнём!

Angular CLI

Одним из самых простых способов создать новое Angular 2 приложение – использовать интерфейс командной строки (CLI) для Angular от разработчиков этого фреймворка, который позволит:

  • Создать стартовый шаблон со всем необходимым кодом для нового Angular 2 приложения
  • Добавить необходимые компоненты, директивы, сервисы, pipes и т.д. к существующему приложению

Для установки Angular CLI необходимо запустить в командной строке:

В данном случае, параметр -g указывает на то, что этот пакет установится глобально и после этого нам будет доступна команда ng .

Чтобы проверить правильность установки, можно выполнить такую команду:

Если всё установлено верно, то будет выведена версия пакета.

При необходимости, вы можете посетить официальную документацию для более детального ознакомления c Angular CLI.

Генерируем наше приложение

Теперь, когда у нас есть установленный Angular CLI, мы можем использовать его для создания стартового шаблона для нашего приложения:

Этой командой мы создадим новую директорию для нашего проекта со всем необходимым для начала работы.

После генерации шаблона, выполним следующие команды:

Тем самым, у нас будет запущенный локальный сервер, который обслуживает наше приложение и доступен по адресу http://localhost:4200/. Также при изменении кода, наше приложение будет автоматически перезагружаться, что добавит немного комфорта в процесс разработки.

Составные части Angular

При выполнении команды ng new , Angular CLI создал для нас стартовый Angular 2 шаблон, но это только лишь одна из полезных возможностей, предоставляемых этим инструментом. Этот инструмент также поможет нам добавить дополнительные составные части в существующее Angular приложение, при помощи команды ng generate :

Если вы не знакомы с основными строительными блоками Angular 2 приложения, то крайне рекомендую ознакомиться с быстрым стартом Angular 2 сначала.

Для нашего приложения нам понадобятся:

  • Todo класс для представления каждой отдельной записи
  • TodoService для создания, обновления и удаления записи
  • TodoApp компонент для отображения пользовательского интерфейса

Итак, давайте добавим последовательно все эти компоненты в наше приложение.

Создание класса Todo

По той причине, что мы используем TypeScript, у нас есть возможность создать класс для представления Todo записей. Поэтому, воспользуемся возможностями Angular CLI для генерации Todo класса:

Что создаст следующие файлы:

Давайте откроем файл src/app/todo.ts и заменим его содержимое на:

В нашем случае, каждая Todo запись имеет три свойства:

  • id : числовой тип, уникальный ID каждой записи
  • title : строковый тип, название записи
  • complete : булевый тип, статус для записи – завершена задача или нет

Использование конструктора позволит нам при создании экземпляра класса определить нужные значения, например:

Angular CLI также создал для нас src/app/todo.spec.ts файл, поэтому давайте добавим в него юнит-тест, чтобы убедиться в работоспособности логики конструктора:

Для проверки того, что наш код работает так, как мы ожидали, запустим юнит-тесты командой:

Которая запустит окружение для тестирования Karma и выполнит все наши тесты.

Если тесты не были пройдены успешно, то, возможно, вы допустили какую-то ошибку в коде приложения. Просто сравните ваш код с кодом, находящимся в репозитории приложения: https://github.com/sbogdanov108/angular2_crud

Теперь, когда у нас есть Todo класс, давайте создадим Todo сервис, который будет управлять всеми записями нашего приложения.

Создание Todo сервиса

TodoService , который будет нами создан, должен отвечать за управление Todo записями. В будущей статье, мы разберём, как взаимодействовать с REST API сервисом, но в рамках данной статьи, мы используем простое хранение всех данных приложения в оперативной памяти.

Приступим к генерации нового сервиса с помощью Angular CLI:

Этой командой мы создадим файлы:

Сейчас нам нужно добавить логику работу сервиса TodoService в файл src/app/todo.service.ts :

Детали реализации описанных выше методов не являются темой данной статьи и могут иметь любую логику работы, удовлетворяющей вашим потребностям. Основной смысл данных действий в том, что мы вынесли бизнес-логику нашего приложения в отдельный сервис.

И чтобы убедиться, что написанная нами логика работает, давайте добавим несколько юнит-тестов в файл src/app/todo.service.spec.ts , который был сгенерирован Angular CLI.

Так как Angular CLI уже создал для нас заготовку кода, всё, что остаётся сделать – реализовать нужные тесты:

Karma поставляется с встроенным и предварительно сконфигурированным фреймворком для тестирования Jasmine. Вы можете ознакомиться с документацией Jasmin для лучшего понимания синтаксиса этого фреймворка.

Чтобы проверить правильность работы нашей бизнес-логики, заново запустим наши юнит-тесты:

Отлично, всё работает! Теперь самое время создать интерфейс нашего приложения.

В Angular 2 интерфейс приложения реализуется с помощью компонентов.

Создание TodoApp компонента

И снова давайте используем Angular CLI для генерации компонента:

Эта команда создаст следующие файлы:

Шаблоны и стили также могут быть включены во внутрь файлов скриптов. Angular CLI создаёт несколько отдельных файлов по умолчанию, поэтому, в этой статье, мы будем использовать отдельные файлы.

Давайте начнём с добавления шаблона для компонента в файл src/app/todo-app/todo-app.component.html :

Далее приведено короткое представление Angular синтаксиса для шаблонов, в случае, если вы ещё с ним не сталкивались:

  • [свойство]=»выражение» : назначить свойству результат выражения
  • (событие)=»утверждение» : выполнить утверждение, когда произойдёт событие
  • [(свойство)]=»выражение» : создать двухстороннее связывание с указанным выражением
  • [ : добавить ваш_класс CSS к этому элементу, когда выражение будет истинным
  • [style.color]=»выражение» : назначить свойство CSS color в зависимости от результата выполнения выражения

Если вам не знаком синтаксис Angular для шаблонов, то необходимо ознакомится с официальной документацией на эту тему.

Давайте посмотрим, что происходит в нашем шаблоне. На самом верху есть поле ввода для создания новой записи:

  • [(ngModel)]=»newTodo.title» : добавляет двухстороннее связывание между значением input и newTodo.title
  • (keyup.enter)=»addTodo()» : говорит Angular, чтобы он выполнил метод addTodo() , когда клавиша Enter была нажата в поле ввода

Не беспокойтесь пока о том, откуда появились newTodo или addTodo() – мы вскоре их рассмотрим более подробно. Просто попытайтесь понять смысл шаблона.

Далее следует секция для вывода записей todo:

  • *ngIf=»todos.length > 0″ : показать элемент section и всё его содержимое, только при условии, что есть хотя бы одна запись todo

Внутри этой секции, мы просим Angular сгенерировать li элементы для каждой записи:

  • *ngFor=»let todo of todos» : в каждой итерации цикла, мы проходимся по записям todos и назначаем конкретную запись в переменную todo
  • [ : применить класс CSS complete к элементу li , при условии, когда todo.complete является истиной

И наконец, мы отображаем информацию о каждой записи внутри цикла ngFor :

  • (click)=»toggleTodoComplete(todo)» : выполнить toggleTodoComplete(todo) при клике на этом чекбоксе
  • [checked]=»todo.complete» : назначить значение todo.complete свойству checked
  • (click)=»removeTodo(todo)» : выполнить метод removeTodo(todo) , когда была нажата кнопка

Хорошо, теперь давайте вздохнём �� Мы прошлись через довольно-таки большое количество синтаксиса.

Если у вам возникнет желание изучить более подробно синтаксис шаблонов Angular, то отличным вариантом будет начать с официальной документации по шаблонам.

На данный момент, вы могли удивиться – как же выражения addTodo() и newTodo.title могут быть выполнены. Ведь мы ещё не определили их, поэтому, откуда Angular узнает, что они значат?

Это именно то место, где в дело вступает контекст выражения. Контекст выражения компонента является экземпляром компонента. И в свою очередь, экземпляр компонента является экземпляром класса компонента.

Класс компонента нашего TodoAppComponent определён в src/app/todo-app/todo-app.component.ts .

Angular CLI уже создал для нас заготовку класса TodoAppComponent :

Таким образом, мы можем немедленно приступить к добавлению нашей логики работы.

Нам понадобится экземпляр TodoService, поэтому, давайте начнём со вставки его в наш компонент.

Первым делом, мы импортируем TodoService класс и определим его в массиве providers декоратора Component :

В компоненте TodoAppComponent будет произведена вставка зависимости TodoService , таким образом, при необходимости использования этого сервиса будет создан его одиночный экземпляр.

Для системы зависимостей Angular существует множество способов использования. Применённый нами выше синтаксис является укороченной нотацией провайдера класса, таким образом, используется singleton паттерн для работы с зависимостями. Для более детального ознакомления с зависимостями Angular можно рассмотреть документацию на эту тему.

Теперь, когда мы объявили зависимость, можно использовать экземпляр TodoService в конструкторе TodoAppComponent :

Сейчас мы можем реализовать всю необходимую логику для работы нашего шаблона, добавив свойства и методы в TodoAppComponent класс:

Сначала при инициализации класса компонента, мы назначаем свойству newTodo экземпляр класса Todo с помощью кода new Todo() . Это то самое newTodo, которому мы добавили двухстороннее связывание в шаблоне:

При изменении значения поля ввода в шаблоне, значение в экземпляре компонента всегда будет обновляться. Так же, как и в случае изменения этого значения в экземпляре компонента, значение поля ввода будет обновлено.

Потом мы реализовали все необходимые методы, которые используются в нашем шаблоне.

Реализация этих методов является очень короткой и легкой для понимания, так как мы поручили обработку всей логики работы сервису todoService.

Делегирование бизнес-логики сервису, является хорошей практикой в программировании и это позволит нам централизованно управлять и тестировать эту логику.

Теперь на осталось сделать пару шагов, чтобы получить готовое приложение.

Последние штрихи

Для начала найдём в нашем проекте файл src/app/angular2-todo-app.component.ts и внесём в него изменения:

Главные изменения состоят в том, что мы импортировали созданный нами компонент TodoAppComponent для вывода записей, и внесли в декоратор Component указание использовать класс TodoAppComponent для обработки директивы app-todo , описанной в этом классе.

Теперь откроем файл src/app/angular2-todo-app.component.html и заменим всё его содержимое на вызов директивы:

Итак, у нас получилось работающее приложение, правда без стилей.

Добавим предварительно подготовленные стили, которые можно взять по ссылке. И вставим их в файл src/app/todo-app/todo-app.component.css . После сохранения у нас получится полностью готовое и работоспособное приложение.

И до того, как мы закончим этот туториал, давайте попробуем сделать одну интересную вещь с помощью Angular CLI.

Деплой приложения на GitHub Pages

Angular CLI позволяет произвести деплой приложения на GitHub Pages с минимум движений, буквально одной командой.

Для начала нам нужно создать репозиторий на GitHub с именем, которое указано в файле package.json :

Затем выполнить команду:

Команда github-pages:deploy говорить Angular CLI сделать билд статической версии Angular приложения и выполнить его push в бранч gh-pages нашего GitHub репозитория.

Теперь, созданное нами приложение доступно по адресу: https://sbogdanov108.github.io/angular2_crud/

Просто чудесная возможность для быстрого развёртывания приложения, не правда ли?

Подводя итог…

Angular 2 – крайне мощный инструмент для создания приложения, без всякого сомнения.


В этой статье, мы рассмотрели много разных тем и пришло время подвести краткое резюме тому, что изучили:

  • Мы узнали, как установить Angular CLI и как много времени этот инструмент может сохранить для нас, при создании нового приложения или добавление функционала к существующему
  • Мы изучили, как реализовать бизнес-логику в сервисах Angular и как произвести тестирование этой логики используя юнит-тесты
  • Как использовать компоненты для взаимодействия с пользователем и каким образом делегировать логику работы сервису, используя вставку зависимостей
  • Мы изучили основы синтаксиса шаблонов Angular и немного коснулись темы работы зависимостей в Angular
  • И под конец, мы узнали, как можно быстро развернуть наше приложение на GitHub Pages

Осталось много того, о чём ещё хотелось бы поговорить, но это уже темы для следующих статей:

  • Взаимодействие с REST API бэкэндом, используя Angular 2 HTTP сервис
  • Фильтрация записей todo с помощью Angular pipes
  • Реализация навигации для создания многостраничного приложения

И ещё много другого…

Исходные коды приложения доступны в GitHub репозитории по ссылке.

При создании статьи были использованы следующие источники:

Настройка репликации MongoDB на сервере Ubuntu

MongoDB – это очень популярная база данных NoSQL, используемая для хранения и управления информацией сайта или приложения. Среди преимуществ MongoDB стоит выделить простое масштабирование, удобный формат данных и динамическую разработку схем.

Данное руководство покажет, как настроить репликацию данных, что обеспечит высокую доступность информации и позволит создать надежную систему обхода отказа. Это очень важно в любой среде производства, поскольку отказ или сбой базы данных негативно скажется на производительности сайта и на доверии ваших клиентов.

Примечание: Нужно предварительно установить MongoDB; инструкции по установке можно найти в следующих статьях:

Что такое сеты MongoDB?

MongoDB обрабатывает репликацию при помощи так называемых сетов, или наборов реплик (англ. «replication sets»). Наборы реплик – это, по сути, те же ноды, которые используются в настройке master-slave; то есть, один член набора становится основным и далее используется в качестве ведущего при синхронизации настроек остальных членов.

Разница между наборами реплик и репликацией master-slave состоит в том, что наборы реплик используют встроенный автоматический механизм переключения в случае сбоя ведущего члена.

Первичный член (или узел) – это точка доступа для взаимодействия с набором реплик; это единственный узел, который может выполнять операции записи.

Каждый набор реплик может иметь только один первичный узел, поскольку репликация происходит путем копирования логов операций (oplog) первичного узла и изменения вторичных узлов согласно полученным данным. Наличие нескольких первичных узлов приведёт к конфликтам данных.

Топ-пост этого месяца:  Как настроить DNS сервера на VDS, VPS сервере

Вторичные узлы – это узлы набора реплик, подчиняющиеся первичному узлу. Каждый набор реплик может иметь несколько вторичных узлов одновременно.

По умолчанию приложения будут запрашивать первичный узел для выполнения операций чтения и записи, однако можно настроить установку для чтения из одного или нескольких вторичных узлов. Вторичный узел может стать первичным в случае сбоя или перехода текущего первичного узла в автономный режим.

Примечание: В связи с тем, что данные передаются асинхронно, операции чтения из вторичных узлов могут привести к обслуживанию устаревших данных. Потому использовать эту функцию не рекомендуется.

Арбитр – это дополнительный член набора реплик, который фактически не принимает участие в процессе репликации; он добавляется в набор реплик для выполнения некоторых ограниченных функций как прерыватель соединений.

Если первичный узел становится недоступным, из вторичных узлов автоматически выбирается новый первичный узел. Если вторичных узлов четное количество, может возникнуть затруднение при выборе первичного узла. В таких ситуациях и используется арбитр.

Арбитр необходим, если в наборе реплик есть только вторичные узлы.

Настройка вторичных узлов

Бывают случаи, когда не все вторичные узлы должны следовать за первичным. Набор реплик может содержать до 12 членов, 7 из которых могут голосовать в случае падения первичного узла.

Узлы реплик с приоритетом 0

Иногда голосование или отдельные узлы набора реплик, ставшие первичными, могут негативно повлиять на производительность приложения.

К примеру, при репликации данных на удалённый центр обработки аппаратное обеспечение может справиться с ролью первичного узла; установив приоритет 0, вы можете быть уверены, что этот узел не станет первичным, но будет участвовать в копировании данных.

Скрытые узлы репликации

Иногда возникает необходимость отделить главный набор реплик, доступный и видимый клиентами, от фоновых узлов, которые преследуют другие цели.

К примеру, отдельный вторичный узел может работать в качестве основы для проведения анализа, который определённо выиграет от использования актуальных данных, но может помешать работе некоторых узлов. Такой узел можно скрыть, и тогда он не будет вмешиваться в общие операции набора реплик.

Приоритет скрытых узлов всегда должен быть нулевым, поскольку такой узел не должен стать первичным, но должен участвовать в репликации и в голосовании.

Задержка членов репликации

Опция delay позволяет задать время ожидания, по истечении которого вторичные узлы приступают к выполнению операции, скопированной из oplog-а.

Это позволяет защититься от случайного удаления данных или восстановиться после взлома. Например, узлы с довольно большим временем ожидания (в несколько часов) не станут немедленно выполнять операции, запущенные по ошибке, в своих наборах данных и могут быть использованы для отмены изменений на остальных узлах.

Такие узлы не должны становиться первичными, но должны участвовать в остальных операциях. Кроме того, они должны быть скрытыми (чтобы предотвратить чтение процессами устаревших данных).

Настройка набора реплик

Для примера попробуем настроить простой набор реплик, состоящий из первичного и двух вторичных узлов. Для такого набора потребуется три выделенных сервера.

Примечание: В руководстве на серверах используется система Ubuntu 12.04.

Сначала нужно установить MongoDB на каждый сервер, участвующий в репликации. Все необходимые инструкции по установке можно найти здесь:

Подготовив серверы к работе, нужно настроить их взаимодействие.

Примечание: Для выполнения дальнейших инструкций нужен доступ к root.

Настройка DNS-резолвинга

Чтобы все экземпляры MongoDB взаимодействовали друг с другом, нужно настроить разрешение имён хостов каждого узла. Для этого можно либо настроить субдомены для каждого узла либо отредактировать /etc/hosts на каждом компьютере.

Для долгой настройки лучше использовать субдомены, а для тестовой настройки – отредактировать файлы hosts, что и будет рассмотрено ниже.

Итак, откройте файл hosts на одном из узлов репликации:

После первой строки (с настройками для localhost) нужно добавить запись для каждого члена набора реплик. Они выглядят так:

Примечание: Внешний IP-адрес можно найти в панели управления сервером. Имя хоста можно выбрать любое, но оно должно быть описательным.

В данном примере файл /etc/hosts будет выглядеть так:

127.0.0.1 localhost mongo0
123.456.789.111 mongo0.example.com
123.456.789.222 mongo1.example.com
123.456.789.333 mongo2.example.com

На всех узлах репликации этот файл будет выглядеть почти одинаково. Сохраните и закройте файл. После этого нужно изменить имя хоста сервера согласно новым настройкам. Следующая команда должна отражать имя сервера, на котором она запущена, указанное в файле /etc/hosts.

Примечание: Отредактируйте команду на каждом сервере.

Также нужно отредактировать файл /etc/hostname, указав в нём новое имя хоста:

nano /etc/hostname
mongo0.example.com

Примечание: Инструкции этого раздела нужно выполнить на каждом узле репликации.

Настройка репликации MongoDB

Для начала нужно остановить MongoDB на каждом сервере:

service mongodb stop

Затем нужно настроить каталог, который будет использоваться для хранения данных. Создайте его с помощью следующей команды:

Каталог дл хранения данных готов. Теперь нужно отредактировать конфигурационный файл, чтобы отразить в нём новую конфигурацию набора реплик.

В этом файле нужно отредактировать несколько параметров. Найдите переменную dbpath и направьте её на только что созданный каталог:

Раскомментируйте строку port, чтобы включить стандартный порт:

В нижней части файла нужно раскомментировать параметр replSet. Задайте ему значение, которое вы легко сможете узнать:

В завершение нужно включить ветвление процессов. В нижней части файла укажите:

Сохраните и закройте файл. Запустите узел репликации:

mongod —config /etc/mongodb.conf

Примечание: Инструкции этого раздела нужно выполнить на каждом узле репликации.

Запуск набора реплик и добавление узлов

Теперь все члены набора реплик готовы к работе, притупайте к инициации репликации данных и добавлению узлов.

На одном из узлов введите:

Появится командная строка MongoDB для текущего узла.

Запустите набор реплик:

Эта команда инициирует набор реплик и добавит в него текущий сервер. Чтобы проверить это, введите:

После этого в репликацию можно добавить остальные узлы, сославшись на имя хоста, заданное в /etc/hosts:

Повторите это для всех узлов. Теперь репликация данных настроена и запущена!

Заключение

Правильно настроенные наборы реплик позволяют защитить БД от аварийных отказов и аппаратных сбоев, а это чрезвычайно важно в любой среде производства.

Angular и Django: создание приложения микро-блога

Интересует тема, как вызывать функции API Angular 6 и HttpClient? В этом учебном пособии будут показаны некоторые методы построения приложения для микро-блогов, использующего Angular 6 и Django Rest Framework (DRF). В процессе мы узнаем следующее:

  • Как сделать бэкэнд приложение с помощью Django и API Django Rest Framework
  • Создание простого одностраничного приложения Angular 6, которое может запрашивать API
  • Аутентификация пользователей с помощью JSON Web Tokens (JWT)

Готовы? Давайте начнем!

Обзор

Это разделенное приложение, использующее два разных фреймворка. Таким образом, данные должны проходить через несколько шагов, чтобы перейти от базы данных к экрану пользователя. Вот простая диаграмма потока данных:

База данных SQLite → Модель Django → Сериализатор Django → Django ViewSet → Сервис Angular → Компонент Angular

В этом руководстве будет рассмотрено, как создать каждую часть нашего приложения для микро-блогов.

Приложение Django

Модели Django

Наше приложение микро-блога содержит две модели данных: User и BlogPost. Модель User предоставлена самим фреймворком Django, поэтому нам нужно создать только класс модели для BlogPost. Это довольно просто и определяет несколько полей, а также «волшебный» метод Python «to-string», называемый __str __() .

После создания класса модели необходимо создать и провести миграции схемы БД.

Сериализатор

Django Rest Framework работает в концепции модели, сериализаторы и ViewSets. Сериализатор описывает, как преобразовать объекты модели в JSON и обратно. Django ORM использует классы моделей, а конечные точки API используют JSON. Сериализатор — это то, что преобразовывает одно в другое.

В отличие от наших вышеприведенных классов моделей, нам необходимо предоставить сериализатор для модели User. Django Rest Framework не делает это за нас, даже если сама модель User находится непосредственно в Django.

Кроме того, мы создаем класс BlogPostSerializer, который определяет, какие поля в модели BlogPost должны быть преобразованы в JSON. Обратите внимание, что мы также определяем связь с классом User. Это означает, что при сериализации объекта BlogPost полученный JSON будет содержать вложенный объект, который является сериализованной моделью пользователя. Представление JSON BlogPost может выглядеть так:

ViewSet

Следующее, что нам нужно для Django Rest Framework — это ViewSet. Это коллекция Django Views (иными словами, контроллеров), которые содержатся в классе.

Также как и в сериализаторе, мы создаем ViewSet дял обеих моделей: User и BlogPost.

В этом примере приложение не позволяет редактировать пользовательские модели с помощью API, поэтому UserViewSet настроен с permission_ >, не позволяя API писать в БД. Как же происходит редактирование профилей пользователей, спросите вы? Это выходит за рамки этого примера, но встроенное приложение-админка Django предоставляет способ сделать это, если нужно. При создании своего собственного приложения вы можете создать компонент Angular, чтобы пользователи могли редактировать свои профили и изменять разрешение ReadOnly на другое разрешение, позволяя пользователям редактировать только свои собственные профили.

Класс BlogPostViewSet также содержит класс разрешений IsAuthenticatedOrReadOnly. Это позволяет посетителям просматривать любые записи в нашем приложении, но только пользователи, которые вошли в систему, могут создавать записи.

Конфигурация Django URL

Нам также необходимо добавить адреса ViewSet’ов в URL нашего приложения.

Во-первых, мы добавляем URL-адреса ViewSet в наше приложение для микроблогов:

Во-вторых, добавим URL приложения в URL проекта:

Проверим наше API

Django Rest Framework поставляется с встроенным средством просмотра Swagger API. Чтобы узнать, что доступно в API, все, что вам нужно сделать, — запустить python manage.py runserver и посетить localhost:8000/api, чтобы увидеть конечные точки API в действии.

Вызов API из Angular

Мы завершили настройку бэкенд части приложения. Теперь пришло время создать наши компоненты и сервисы для Angular. Они вызовут конечные точки API, а также предоставят пользовательский интерфейс для приложения.

В предыдущем посте мы уже создали шаблоны Django, необходимые для обслуживания приложения Angular, поэтому мы можем погрузиться в сам код Angular.

Компонент и шаблон

В первой части руководства мы создали базовый компонент Angular. Сейчас нам нужно добавить несколько свойств и методов для работы с записями блога.


Наш компонент содержит два новых свойства: ‘posts’ представляет собой массив записей блога, который мы получили от API. Свойство ‘new_post’ содержит простой объект JavaScript, который используеся для создания формы новой записи блога.

Кроме того, есть еще два метода: getBlogPosts() будет запрашивать API через BlogPostService и заполнять объект ‘posts’, а createPost() берет данные из ‘new_post’ и отправляет их в функцию API.

В нашем файле шаблона Angular мы добавляем список pfgbctq в блоге и форму для создания нового сообщения.

Сервис Angular для одного сообщения блога

В 1-ой части мы создали класс UserService для Angular для обработки вызовов API, связанных с пользовательсокй авторизацией и работы с токеном. Теперь мы создадим вторую службу: BlogPostService, которая обрабатывает соединения с конечными точками API BlogPost, которые мы создали выше.

Вот заключительная часть нашей головоломки, сервис для сообщения блога:

Обратите внимание на методы list() и create() в нашем сервисе. Они создают Observable, используя HttpClient Angular и возвращают его вызывающему. Вот так компонент получает свои данные.

Использование токена CSRF

Помните, что в вышеприведенном коде ViewSet, конечные точки Blog Post имели разрешения только для проверки подлинности или чтения? Когда мы отправляем данные запросом POST в API, нам также нужен способ сообщить, что пользователь аутентифицирован.

Итак, давайте рассмотрим первую часть, где вызывали конечную точку API: аутентификацию, чтобы получить JSON Web Token. Мы можем использовать этот токен, чтобы указать API, что пользователь вошел в систему, а также идентификатор пользователя. Все, что нам нужно сделать, это добавить заголовок «Авторизация» в заголовки HTTP, которые мы отправляем с запросом API. При использовании JWT значение должно быть «JWT», за которым следует пробел, а затем весь токен.

Вот полный пример заголовка авторизации:

Обратите внимание, что в этом примере нам нужно отправить заголовок при записи в API. Поскольку анонимные пользователи могут видеть сообщения в блоге, и у них не будет токена JWT, мы не отправляем заголовок авторизации с запросами GET, создаваемыми методом list(). Однако в другом приложении, где контент не отображается анонимным пользователям, нам также необходимо отправить заголовок авторизации в запрос GET.

Создание приложения Angular с использованием API Azure Cosmos DB для MongoDB. Подключение к Cosmos DB с помощью Mongoose Create an Angular app with Azure Cosmos DB’s API for MongoDB — Use Mongoose to connect to Cosmos DB

Из этого руководства в нескольких частях вы узнаете, как создать приложение Node.js с использованием Express и Angular и подключить его к учетной записи Cosmos, настроенной с API Cosmos DB для MongoDB. This multi-part tutorial demonstrates how to create a Node.js app with Express and Angular, and connect it to it to your Cosmos account configured with Cosmos DB’s API for MongoDB. В этой статье описана часть 5 руководства, которая основана на части 4. This article describes Part 5 of the tutorial and builds on Part 4.

В этой части руководства вы выполните следующее: In this part of the tutorial, you will:

  • подключитесь к Cosmos DB с помощью Mongoose; Use Mongoose to connect to Cosmos DB.
  • получите строку подключения к Cosmos DB; Get your Cosmos DB connection string.
  • создадите модель Hero; Create the Hero model.
  • создадите службу Hero для получения данных Hero. Create the Hero service to get Hero data.
  • Запустите приложение на локальном компьютере. Run the app locally.

Если у вас еще нет подписки Azure, создайте бесплатную учетную запись Azure, прежде чем начинать работу. If you don’t have an Azure subscription, create a free account before you begin.

Предварительные требования Prerequisites

Перед началом работы с этим руководством выполните шаги в части 4. Before you start this tutorial, complete the steps in Part 4.

Для этого руководства требуется запустить Azure CLI локально. This tutorial requires that you run the Azure CLI locally. Требуется Azure CLI версии 2.0 или более поздней. You must have the Azure CLI version 2.0 or later installed. Чтобы узнать версию, выполните команду az —version . Run az —version to find the version. Если вам необходимо установить или обновить Azure CLI, ознакомьтесь со статьей об установке Azure CLI 2.0. If you need to install or upgrade the Azure CLI, see Install the Azure CLI 2.0.

В этом руководстве изложены пошаговые инструкции по созданию приложения. This tutorial walks you through the steps to build the application step by step. Готовое приложение можно скачать из репозитория angular-cosmosdb на GitHub. If you want to download the finished project, you can get the completed application from the angular-cosmosdb repo on GitHub.

Использование Mongoose для подключения Use Mongoose to connect

Mongoose является библиотекой моделирования данных объектов (ODM) для MongoDB и Node.js. Mongoose is an object data modeling (ODM) library for MongoDB and Node.js. Вы можете использовать Mongoose для подключения к учетной записи Azure Cosmos DB. You can use Mongoose to connect to your Azure Cosmos DB account. Следуйте инструкциям ниже, чтобы установить Mongoose и подключиться к Azure Cosmos DB: Use the following steps to install Mongoose and connect to Azure Cosmos DB:

Установите модуль npm mongoose, который является API, используемым для обмена данными с MongoDB. Install the mongoose npm module, which is an API that’s used to talk to MongoDB.

Топ-пост этого месяца:  Электронная коммерция - что это такое Развитие и проблемы рынка

В папке server создайте файл с именем mongo.js. In the server folder, create a file named mongo.js. Затем добавьте в этот файл сведения о подключении учетной записи Azure Cosmos DB. You’ll add the connection details of your Azure Cosmos DB account to this file.

Скопируйте следующий код в файл mongo.js. Copy the following code into the mongo.js file. Этот код предоставляет следующие функциональные возможности: The code provides the following functionality:

Требует установки Mongoose. Requires Mongoose.

Переопределяет объект Promise Mongo, чтобы использовался базовый объект Promise, который встроен в ES6 или ES2015 и более поздней версии. Overrides the Mongo promise to use the basic promise that’s built into ES6/ES2015 and later versions.

Вызывает ENV-файл, который позволяет задавать определенные настройки в зависимости от среды — промежуточной, производственной или среды разработки. Calls on an env file that lets you set up certain things based on whether you’re in staging, production, or development. Вы создадите этот файл при работе со следующим разделом. You’ll create that file in the next section.

Содержит строку подключения MongoDB, которая задается в ENV-файле. Includes the MongoDB connection string, which is set in the env file.

Создает функцию подключения, которая вызывает Mongoose. Creates a connect function that calls Mongoose.

В области Explorer в разделе server, создайте папку с именем environment. In the Explorer pane, under server, create a folder named environment. В папке environment создайте файл с именем environment.js. In the environment folder, create a file named environment.js.

Из файла mongo.js нужно включить значения для параметров dbName , key и cosmosPort . From the mongo.js file, we need to include values for the dbName , the key , and the cosmosPort parameters. Скопируйте следующий код в файл environment.js: Copy the following code into the environment.js file:

Получение строки подключения Get the connection string

Для подключения приложения к Azure Cosmos DB вам потребуется обновить параметры конфигурации этого приложения. To connect your application to Azure Cosmos DB, you need to update the configuration settings for the application. Чтобы обновить параметры, выполните следующие шаги: Use the following steps to update the settings:

На портале Azure получите номер порта, имя учетной записи Azure Cosmos DB и значение ее первичного ключа. In the Azure portal, get the port number, Azure Cosmos DB account name, and primary key values for your Azure Cosmos DB account.

В файле environment.js измените значение port на 10255. In the environment.js file, change the value of port to 10255.

В файле environment.js измените значение accountName на имя учетной записи Azure Cosmos DB, которая была создана на шаге 4 руководства. In the environment.js file, change the value of accountName to the name of the Azure Cosmos DB account that you created in Part 4 of the tutorial.

Получите первичный ключ для учетной записи Azure Cosmos DB, использовав следующую команду CLI в окне терминала: Retrieve the primary key for the Azure Cosmos DB account by using the following CLI command in the terminal window:

— имя учетной записи Azure Cosmos DB, созданной в части 4 этого руководства. is the name of the Azure Cosmos DB account that you created in Part 4 of the tutorial.

Скопируйте первичный ключ в файл environment.js как значение key . Copy the primary key into the environment.js file as the key value.

Теперь ваше приложение имеет все необходимые сведения для подключения к Azure Cosmos DB. Now your application has all the necessary information to connect to Azure Cosmos DB.

Создание модели Hero Create a Hero model

Далее необходимо определить схему данных для хранения в Azure Cosmos DB, определив файл модели. Next, you need to define the schema of the data to store in Azure Cosmos DB by defining a model file. Выполните следующие действия, чтобы создать модель Hero, определяющую схему данных: Use the following steps to create a Hero model that defines the schema of the data:

В области Explorer в папке server создайте файл с именем hero.model.js. In the Explorer pane, under the server folder, create a file named hero.model.js.

Скопируйте следующий код в файл hero.model.js. Copy the following code into the hero.model.js file. Этот код предоставляет следующие функциональные возможности: The code provides the following functionality:

  • Требует установки Mongoose. Requires Mongoose.
  • Создает схему с идентификатором, именем и фразой. Creates a new schema with an ID, name, and saying.
  • Создает модель с помощью схемы. Creates a model by using the schema.
  • Экспортирует модель. Exports the model.
  • Коллекция должна называться Heroes (а не Heros, как бы она называлась по умолчанию в соответствии с правилами именования Mongoose для множественного числа). Names the collection Heroes (instead of Heros, which is the default name of the collection based on Mongoose plural naming rules).

Создание службы Hero Create a Hero service

После создания модели Hero нужно определить службу для чтения данных, а также выполнения операций перечисления, создания, удаления и обновления. After you create the hero model, you need to define a service to read the data, and perform list, create, delete, and update operations. Выполните следующие действия для создания службы Hero, которая запрашивает данные из Azure Cosmos DB: Use the following steps to create a Hero service that queries the data from Azure Cosmos DB:

В области Explorer в папке server создайте файл с именем hero.service.js. In the Explorer pane, under the server folder, create a file named hero.service.js.

Скопируйте приведенный ниже код в файл hero.service.js. Copy the following code into the hero.service.js file. Этот код предоставляет следующие функциональные возможности: The code provides the following functionality:

  • Получает созданную модель. Gets the model that you created.
  • Устанавливает подключение к базе данных. Connects to the database.
  • Создает переменную docquery , которая использует метод hero.find , чтобы определить запрос, возвращающий все элементы hero. Creates a docquery variable that uses the hero.find method to define a query that returns all heroes.
  • Выполняет запрос с помощью функции docquery.exec с разрешением на получение списка всех элементов hero, для состояния ответа которых установлено значение 200. Runs a query with the docquery.exec function with a promise to get a list of all heroes, where the response status is 200.
  • Если для состояния установлено значение 500, возвращается сообщение об ошибке. Sends back the error message if the status is 500.
  • Так как мы используем модули, извлекаются элементы hero. Gets the heroes because we’re using modules.

Настройка маршрутов Configure routes

Теперь необходимо настроить маршруты для обработки URL-адресов для запросов на получение, создание, чтение и удаление. Next, you need to set up routes to handle the URLs for get, create, read, and delete requests. Методы маршрутизации указывают функции обратного вызова, также называемые функциями обработчика. The routing methods specify callback functions (also called handler functions). Эти функции вызываются, когда приложение получает запрос к указанной конечной точке и метод HTTP. These functions are called when the application receives a request to the specified endpoint and HTTP method. Используйте следующие шаги, чтобы добавить службу Hero и определить свои маршруты: Use the following steps to add the Hero service and to define your routes:

В Visual Studio Code в файле routes.js закомментируйте функцию res.send , которая отправляет пример данных hero. In Visual Studio Code, in the routes.js file, comment out the res.send function that sends the sample hero data. Вместо нее добавьте строку для вызова функции heroService.getHeroes . Add a line to call the heroService.getHeroes function instead.

В файле routes.js добавьте для службы Hero команду require : In the routes.js file, require the hero service:

В файле hero.service.js обновите функцию getHeroes , чтобы она принимала параметры req и res , как показано ниже: In the hero.service.js file, update the getHeroes function to take the req and res parameters as follows:

Давайте выделим пару минут на проверку и просмотрим предыдущий код. Let’s take a minute to review and walk through the previous code. Сначала мы переходим к файлу index.js, который задает сервер узла. First, we come into the index.js file, which sets up the node server. Обратите внимание, что он настраивает и определяет ваши маршруты. Notice that it sets up and defines your routes. Затем файл routes.js обращается к службе Hero и дает ей команду получить функции, например getHeroes, а также передать запрос и ответ. Next, your routes.js file talks to the hero service and tells it to get your functions, like getHeroes, and pass the request and response. Файл hero.service.js получает модель и подключается к Mongo. The hero.service.js file gets the model and connects to Mongo. При вызове он выполняет getHeroes и возвращает обратно ответ 200. Then it executes getHeroes when we call it, and returns back a response of 200.

Запуск приложения Run the app

Затем выполните приложение, следуя приведенным ниже шагам: Next, run the app by using the following steps:

Сохраните все изменения в Visual Studio Code. In Visual Studio Code, save all your changes. Нажмите кнопку Отладка слева, , а затем — кнопку Начать отладку . On the left, select the Debug button , and then select the Start Debugging button .

Теперь переключитесь на браузер. Now switch to the browser. Откройте средства разработчика и перейдите на вкладку «Сеть» . Перейдите по адресу http://localhost:3000 , где расположено ваше приложение. Open the Developer tools and the Network tab. Go to http://localhost:3000 , and there you see our application.

В приложении пока нет элементов hero. There are no heroes stored yet in the app. В следующей части этого руководства мы добавим функции put, push и delete. In the next part of this tutorial, we’ll add put, push, and delete functionality. Затем мы сможем добавлять, обновлять и удалять элементы hero из пользовательского интерфейса, используя подключения Mongoose к базе данных Azure Cosmos. Then we can add, update, and delete heroes from the UI by using Mongoose connections to our Azure Cosmos database.

Очистка ресурсов Clean up resources

Вы можете удалить группу ресурсов, учетную запись Azure Cosmos DB и все связанные ресурсы, когда они больше не нужны. When you no longer need the resources, you can delete the resource group, Azure Cosmos DB account, and all the related resources. Чтобы удалить группу ресурсов, выполните шаги, описанные ниже: Use the following steps to delete the resource group:

  1. Перейдите к группе ресурсов, в которой вы создали учетную запись Azure Cosmos DB. Go to the resource group where you created the Azure Cosmos DB account.
  2. Выберите Удалить группу ресурсов. Select Delete resource group.
  3. Подтвердите имя удаляемой группы ресурсов и выберите Удалить. Confirm the name of the resource group to delete, and select Delete.

Дополнительная информация Next steps

Приступите к части 6 руководства и добавьте в приложение функции Post, Put и Delete: Continue to Part 6 of the tutorial to add Post, Put, and Delete functions to the app:

Курс «Node, Angular и MongoDB: разработка полноценных веб-приложений»

  • О курсе
  • Программа курса
  • Особенности

Если вы разбираетесь в HTML-верстке и хотите дальше развивать свои навыки в программировании, то стоит обратить внимание на разработку веб-приложений при помощи Angular. Знания этого фреймворка дает шанс найти достойную высокооплачиваемую работу.

В программе курса «Node, Angular и MongoDB: разработка полноценных веб-приложений», организованным проектом «Нетология», вы научитесь формировать и запускать web-сервер, работать с новыми интересными внешними модулями и узнаете, что нового в работе с сервером у Agular 2.

Все привыкли, что веб-приложения на JavaScript работают только внутри браузера, но его возможности куда обширней. Благодаря движку V8, встроенному во фреймворк Node, вы поймете, что разработка серверных приложений достигается так же просто, как на Python или PhP.

В курсе по созданию веб-приложений:

  • Создание и запуск web-сервера при помощи Socket и Express.
  • База MongpDB, хранение структурированных данных.
  • Построение интерактивных интерфейсов на Angular.
  • Автоматизированное тестирование веб-приложения.

Повысьте свою квалификацию, освойте программу курса и в вашем резюме появятся записи, которые покажут ваш профессиональный уровень. Сертификат от Нетологии дает преимущество перед ТОП-работодателями, что даст возможность найти место с хорошей и стабильной заработной платой.

Создание MEVN-приложения (Часть 2/2)

Создание full-stack приложения на основе Vue.js и Express.js (+MongoDB)

Эта статья является продолжением предыдущей части руководства, посвященного цели создания базового функционала приложения, разрабатываемого на стеке технологий MongoDB, Express.js, Vue.js and Node.js.

В этой части будет уделено внимание созданию CRUD-операций (Create, Read, Update, Delete), выполняемых при помощи Express.js и MongoDB (для работы с MongoDB мы будем использовать Mongoose).

С исходным кодом готового проекта можно ознакомиться в репозитории на GitLab — MEVN Application.

Что было сделано в предыдущей части

  • создан базовый каркас приложения
  • создано соединение между клиентской и серверной частями приложения

Что будет сделано в этой части


— реализация CRUD-операций при помощи Mongoose

В предыдущей части мы остановились на следующем месте создания приложения. В клиентской части при переходе по адресу http://localhost:8080/posts мы ожидаем отображения в окне браузера списка всех записей (posts), которые получаем с сервера при помощи функции fetchPosts модуля PostService.js.

Давайте снова запустим клиентскую часть командой yarn run dev и серверную часть командой yarn start.

Процесс установки и запуска MongoDB опустим, так как это выходит за рамки этой и так довольно объемной статьи; подразумевается, что читатели данного руководства уже обладают достаточным уровнем знаний в этой области.

Теперь если в браузере мы перейдем по адресу http://localhost:8080/posts, то увидим такую страницу (что и ожидалось):

Создадим подключение к MongoDB при помощи Mongoose. Для этого сначала установим пакет mongoose как зависимость проекта:

И подключим установленный mongoose в главном файле сервера:

Помимо этого сделаем замену промиса библиотеки Mongoose нативным промисом Node.js:

Осталось только подключить Mongoose к MongoDB и связать это действие с запуском сервера express для большей логичности:

Что происходит в этой части кода? В строке mongoose.connect мы подключаем Mongoose к MongoDB. Адрес подключения и опции подключения указаны в файле config/config.js:

Затем в строке mongoose.connection мы прослушиваем подключение Mongoose к MongoDB. Если соединение произошло успешно (событие open), то при помощи метода once, сообщаем в консоли о данном факте; следующим действием запускаем сервер express — app.listen.

Если же при соединении произошла ошибка error, то при помощи метода on сообщаем об этом в консоли.

Примечание переводчика: для полноты картины можно было бы еще обработать событие disconnected, если вдруг произойдет неожиданное отключение Mongoose от MongoDB.

Можно задать вопрос — зачем такие сложности в данном примере кода? На самом деле здесь все правильно и логично, так как мы запускаем сервер express только тогда, когда произошло успешное подключение к базе данных MongoDB.

Mongoose — создание Schema

Прежде чем продолжать работать с MongoDB, мы должны отступить слегка в сторону Mongoose.

Основная цель создания и использования Mongoose — это типизация и верификация данных, записываемых в MongoDB. Другими словами, в Mongoose есть стандартизированный тип данных, создаваемый конкретно для одной из баз данных в MongoDB.

Такой тип данных в Mongoose называется Schema. Для нашей базы данных articles мы создадим Schema под названием PostSchema. Для этого создадим поддиректорию src/models и в ней файл post-model.js с таким содержанием:

Что происходит в данном файле? В нем мы подключаем библиотеку Mongoose для того, чтобы воспользоваться ее методом Schema.

При помощи метода Schema создаем свой пользовательский тип данных PostSchema, в котором говорим, что все данные, которые будут записываться в базу данных articles, должны быть объектами и иметь текстовое поле title и текстовое поле description.

Затем при помощи PostSchema мы создаем пользовательскую модель PostModel при помощи метода model библиотеки Mongoose. Библиотека Mongoose “прикручивает” к модели PostModel коллекцию методов, например — save(), remove(), find() и многие другие.

Эту модель мы экспортируем и при помощи этой модели ( и ее методов) будем создавать и сохранять данные в articles.

Express — создание маршрутов

Прежде чем продолжать работу с моделями Mongoose, внесем в главный файл src/index.js изменение — добавим поддержку маршрутизатора. Это делается для того, чтобы поддержать чистоту и читаемость кода.

Создадим поддиректорию src/routes и в нем файл posts.js, в котором будут содержаться все действия, связанные с маршрутом /posts. В этом файле также подключим модель PostModel:

В итоге заголовок файла src/routes.posts.js будет выглядеть таким образом:

В главном файле src/index.js подключим файл с маршрутами:

Полный вариант индексного файла будет выглядеть таким образом:

Операция CREATE

В файле src/routes/posts.js создадим обработку операции CREATE — создания и записи в базу данных articles:

Что происходит в этом участке кода? Здесь идет обработка POST-запроса на маршруте /posts. Функция обратного вызова создает новый объект post при помощи модели Post.

В качестве значения полей title и description будут использоваться приходящие со стороны клиента значения поля body объекта request.

Экземпляр post модели Post наследует у него методы для записи в базу данных и редактирования в базе данных. В данном случае мы воспользуемся методом save для записи объекта post в базу данных articles.

Если при записи в MongoDB произошла ошибка, то выведем эту ошибку в консоль. Иначе, скажем express, чтобы он сообщил нам об успешном выполнении операции при помощи метода send.

Конечно же, нужно протестировать обработку данного POST-запроса. Для этого я воспользуюсь удобным инструментом Postman:

Как видим, сервер express успешно принимает POST-запрос и при помощи Mongoose делает запись в базу данных MongoDB.

Операция READ

Операция чтения всех данных из базы данных articles выполняется следующим участком кода:

Здесь при GET-запросе на маршрут /posts мы воспользуемся моделью Post и ее методом find, который найдет все записи в базе данных articles и вернет их методом send. Но перед этим будет выполнена сортировка найденных данных методом sort.

Если вдруг произошла ошибка чтения базы данных, express сообщит об этом, отправив код ошибки 500 (“Ошибка сервера”) методом sendStatus.

Давайте получим с помощью Postman все имеющиеся в базе данных articles записи:

Немного же их пока!

Создание и отправка записей из клиента

Настало время настроить возможность создания и отправки данных из клиента (client).

Для этого первоначально создадим новый компонент (страницу) src/components/pages/NewPostPage.vue и пропишем для него маршрут в src/routes/index.js:

Затем наполним содержимым сам компонент NewPostPage.vue:

Что мы видим в этом компоненте? Секция template маленькая и простая — это всего лишь форма для создания и отправки данных. Данные отправляются по нажатию на кнопку button.

Примечание переводчика: здесь было бы правильнее воспользоваться обработкой события submit формы; для этого переместить метод addPost на form( @submit.prevent=”addPost” ) и поменять тип кнопки на “submit” .

Отправка данных из компонента выполняется методом addPost, который через async/await делает следующее. Если значения полей формы не пустые, то вызывает на исполнение метод addNewPost модуля PostsService (мы создадим этот метод немного позже).

Аргументом метода addNewPost передаем объект, который создаем на основе значений полей формы. Как только метод addNewPost успешно выполнился, мы при помощи router возвращаемся на страницу со списком всех записей.

Метод goBack также возвращает нас назад на страницу со списком всех записей, но только при нажатии на кнопку button.

Нам осталось определить метод addNewPost, который и будет отправлять данные с клиента на сервер express. Для этого в файле src/services/PostsService.js добавим такое содержание:

Как видим, метод addNewPost обрабатывает POST-запрос при помощи axios, которому в качестве аргументов мы передаем путь и данные params, которые тот отправит express’у.

Все готово для создания и отправки данных. Откроем браузер по адресу http://localhost:8080/posts/new — должна отобразиться форма, в которой введем данные и отправим на сервер.

Затем проверим, что сервер получил наши данные и записал их в базу данных. Вернемся на страницу со списком всех записей — http://localhost:8080/posts:

Операции CREATE и READ успешно нами созданы и протестированы. Осталось создать две оставшиеся — UPDATE и DELETE.

Операция UPDATE

На стороне сервера в файле src/routes/posts.js добавим два метода — для получения единичной записи по ID и для обновления единичной записи по ID.

Получение единичной записи:

Обновление единичной записи:

В случае с получением единичной записи все просто — мы обрабатываем GET-запрос на маршрут /posts/:id.

Воспользуемся моделью Post и методом findById библиотеки Mongoose. Как видно из самого названия метода, он ищет в базе данных записи с указанным ID. В нашем случае ID приходит со стороны клиента как значение id объекта request.

Далее мы сообщаем Mongoose, чтобы он вернул нам только поля title и description найденного объекта. Если все плохо, то express сообщает нам статус 500; если все хорошо — возвращает найденную запись.

В случае с обновлением записи в базе данных все происходит почти тоже самое. По PUT-запросу на маршрут /posts/:id ищется запись с указанным ID. Если запись найдена, то выполняем две проверки. Если с клиента пришло значение поля title, то записываем его как значение одноименного поля title объекта post. Если с клиента пришло значение поля description, то записываем его как значение одноименного поля description объекта post.

Тем самым мы обновляем найденный объект полученными с клиента данными. Осталось только записать обновленный post снова в базу данных. Express рапортует об успешности или не успешности записи в базу данных.

Обновление записи из клиента

В клиентской части приложения добавляем еще один компонент (страницу) — EditPostPage.vue. В этом компоненте мы будет получать из базы данных единичную запись по ее ID; редактировать поля title и description этой записи; и снова отправлять эту запись на сервер в базу данных, тем самым обновляя ее.

Пропишем в маршруты клиента src/routes/index.js новый компонент EditPostPage.vue:

И наполним его содержимым:

В шаблоне template компонента у нас все также есть простая форма и метод editPost для отправки на сервер данных. Также есть ссылка router-link, которая перенаправит нас на страницу Posts при клике на нее.

В логической части компонента у нас присутствуют два метода модуля PostsService — getPost и updatePost. Метод getPost предельно прост — получаем запись с сервера по указанному ID.

Как только получили — записываем их в данные компонента, в объект post. Единственный момент — мы “вешаем” метод на хук mounted, чтобы он вызывался автоматически на исполнение.

Метод updatePost также прост и понятен. Если поля формы не пустые, то формируем на основе их значений объект с полями id, title, description. И передаем этот объект как аргумент методу updatePost. Метод перенаправит эти данные при помощи axios на сервер. После успешного выполнения метода updatePost автоматически вернемся обратно на страницу со списком всех записей Posts.

В файле src/services/PostsService.js мы добавим оба этих метода:

Теперь в браузере можем протестировать вновь созданную страницу:

Операция DELETE

Для операции удаления записей в базе данных давайте создадим такой обработчик:

В клиентской части добавим в компонент src/components/pages/PostsPage.vue кнопку для удаления записи:

На кнопку повесим обработчик события removePost, которому аргументом будем передавать ID записи.

removePost будет использовать метод deletePost модуля PostsService для удаления записи из базы данных.

В файле src/services/PostsService.js определим метод deletePost:

Протестируем из браузера удаление записей:

Все отлично — операции удаления записей работает успешно. На данном этапе можно сказать, что задача успешно выполнена и нами создано приложение, выполняющее основные операции с записями в базе данных.

Node, Angular и MongoDB: разработка полноценных веб-приложений

Node, Angular и MongoDB: разработка полноценных веб-приложений

Видео курса

Комментарии

Похожие курсы

Angular (Angular 2+) и NodeJS — MEAN стек руководство

Узнайте как подключить свой Angular 2 / Angular 5 Frontend с помощью NodeJS, создав реальное приложения.

Знаете есть курсы, которые показывают вам пример «Hello World», и затем называют это концом? Этого не произойдет с вами в этом курсе. Начиная с очень простого приложения и основных функций, вы быстро сможете включать в свои приложения множество различных маршрутов, переменных, наблюдений, событий, аутентификации и авторизации.

Как я могу создать приложение CRUD в Angular 6 с локальным mongoDB?

Я путаюсь с тем, как создать базовый CRUD в угловых с mongoDB. Я устанавливаю mongodb и создаю базу данных, но я не знаю, где создается моя база данных. Как я могу подключить мою БД с угловым 6 и как я могу вставить, обновить и удалить запись. Другая путаница связана с моделями. где создается модель и как вызывать эти модели для взаимодействия с БД. Я очень новичок в Angular 6 и MongoDB. Пожалуйста, ведите меня шаг за шагом. Я много искал, но не нашел ничего ценного. Ответы и предложения будут высоко оценены. Спасибо

Вы не можете напрямую подключиться к какой-либо БД и не можете выполнять CRUD-операции с Angular. Если вы достигаете CRUD в angular, вам нужно создать API на любом серверном языке, таком как PHP,.net, java, node.js и любой другой. После этого вы можете вызвать API с помощью HttpClient и получить функциональность CRUD. Вы можете узнать больше о Clik здесь, чтобы узнать метод HttPClient для вызова API

Найдите полный структурированный код для начала по ссылке ниже:

Профилирование MongoDB. Часть 1

MongoDB это замечательная NoSQL база данных, которая дает большую гибкость при разработке приложений за счет своего документо-ориентированного способа представления данных. В этой статье я опишу логирование и профилирования ваших решений на базе MongoDB.

Профилирование

Для целей профилирования работы, в MongoDB существует специальная коллекция system.profile. В терминологии MongoDB, system.profile является ограниченной коллекцией (capped collection), потому что её размер ограничен 1Мб. По умолчанию профилирование запросов отключено, и никакой информации о работе системы не сохраняется. Из db.help() нас будут интересовать две команды:

Первая отображает текущий статус профилирования, а вторая помогает его менять. Всего существует три режима, как можно догадаться из подсказки:

, профилирование отключено полность. Это режим по умолчанию, если вы еще не успели настроить профилирование в своей БД, то вы должны увидеть следующее:

1, профилирование медленных запросов. Этот режим я использую на продакшене, потому что он позволяет логировать только запросы, выполнявшиеся дольше определенного порога(threshold). Когда вы устанавливаете этот режим, второй параметр в db.setProfilingLevel становится обязательным и указывает на размер порога срабатывания в миллисекундах. Я использую порог в 100 мс, но это дело вкуса:

2, профилирование всех запроса. Хорошо подходит для разработки, но на продакшене использовать нецелесообразно: старые данные профайлера быстро затираются, а накладные расходы на поддержание столь подробного лога, увеличиваются.

Структура документов в system.profile

Все записи профайлера представляют собой обычные документы со следующим набором основных полей:

  • op, тип операции(insert, query, update, remove, getmore, command)
  • ns, коллекция(а точнее namespace), над которой производится операция
  • millis, время выполнения операции в миллисекундах
  • ts, время(timestamp) операции. Большого значения это не имеет, но это дата окончания выполнения операции.
  • client, IP-адрес или имя хоста, с которого была отправлена команда
  • user, авторизованный пользователь, который выполнил запрос. Если вы не используете авторизацию, то в профайлер будет записана пустая строка.

В дополнение к основным полям, есть ещё поля, специфические для каждого типа запроса. Для поиска(find) это будет сам запрос(query), информация о числе просканированных(nscanned) и возвращенных(nreturned) документов, для изменения(update) это будет число обновленных(nupdated) и перемещённых на диске(nmoved) элементом и т.д. За полным списком полей можно обратиться к документации.

Вот пример для вставки(insert) документа:

Запросы к профайлеру

К коллекции system.profile применимы все те же способы формирования запросов, что и к обычной коллекции. Вот несколько самых ходовых вариантов:

Анализ истории помогает выявить и локализовать неэффективные запросы. Для этого стоит регулярно просматривать самые тяжелы операции на предмет ошибки.

Такой подход я применяю для анализа новых коллекций и пользовательских сценариев, но в определенный момент схема данных и запросы “устаканиваются”, а анализ исторических данных начинает показывать одни и те же цифры, в которых сложно заподозрить проблемы. Другими словами, со временем этот подход перестает приносить свои плоды, потому что проект/модуль переходит из стадии разработки в стадию поддержки.

Логирование

Логи работы системы являются еще одной возможностью проанализировать работу БД на предмет потенциальных проблем. Найти лог не сложно, в /etc/mongodb.conf есть соответствующая настройка для этого:

Лог MongoDB хранит множество информации обо всех аспектах работы системы, но нас будут интересовать только некоторые записи:

Такие записи отражают обращения в БД, которые выполнялись более 100 мс. Сюда могут входить как команды по изменению данных(save, insert, update), так и команды по извлечению или агрегации данных(find, aggregate, mapReduce), например:

В зависимости он того, как организован доступ к БД, в логах могут часто появляться записи об открытии/закрытии соединения с клиентом и общее число подключений:

За логами можно следить в реальном времени, если воспользоваться консольной командой tail :

Таким образом можно отслеживать производительность различных пользовательских сценариев при разработке.

Логи сильно меня выручали, когда я только начинал разбираться с мониторингом и отладкой MongoDB. Если вы только планируете выводить на продакшен решение на базе MongoDB, изучение логов является обязательным пунктом. Правда, если информации слишком много или нужно проанализировать выполнение запросов за предыдущий период времени, лучше обратиться к другому инструменту.

Заключение

В этой части были рассмотрены базовые возможности логирования и профилирования в MongoDB. По своему опыту, могу сказать, что этого достаточно для диагностирования большинства проблем. В следующей части я расскажу о более продвинутых способах профилирования с использованием Aggregation Framework.

Отдых-MongoDB ошибки при добавлении данных с использованием методы поста с использованием angular2

Я использую angular2, отдых и MongoDB для моего проекта иХ выкладывают данные на сервер, используя почту method.Now проблема заключается в том, что я могу размещать данные на сервер, используя данные Почтальона .the становится добавлено к базы данных, как well.But, когда я пытаюсь добавить данные от переднего конца, я получаю ответ, как хорошо с сервера, но данные не получают добавлен в database.I не понимают, почему, потому что, если данные получения добавлены с помощью почтальона, я не понимаю, почему он не получает добавлено от переднего конца

Ниже приведены мои коды

Угловой метод Post

и ответ от сервера в консоли

Ответ <_body: <>, состояние: 200, хорошо: правда, его статус: OK, заголовки: Заголовки . >

Добавить комментарий
Поставьте оценку