Что делают сервисы?
Сервисы предназначены для хранения и получения данных, которые после будут использованы в контроллерах - документация NestJS
Почти все сервисы содержат одинаковый набор асинхронных методов для получения данных, которые будут описаны позже.
Прежде чем перейти к этим методам нужно понять, каким образом происходит взаимодействие с базой данных. Связь с базой данных обеспечит репозиторий, который подключается с помощью декоратора @InjectRepository(Сущность) в конструкторе класса
Репозиторий позволяет работать с вашими сущностями. Найти, вставить, обновить, удалить и т.д - класс Repository
Подробную информацию можно взять в самом классе Repository, где каждый метод подробно описан
Сервисы и методы
Как и говорилось выше - почти во всех сервисах одинаковый набор методов. Это позволяет легче поддерживать приложение. При этом имена методов должны передавать суть того, что они делают (капитан очевидность).
Основные методы: getAll, getById, create, patch, delete, restore
Скорее всего у некоторых из вас возник вопрос: Почему patch, а не update?
Как уже говорилось - я начинающий разработчик. В поисках информации о том, какой должен быть REST API я узнал, что PATCH и PUT отличаются тем, что PUT делает полную замену (т.е на сервер должны прилетать все поля), а PATCH частичную замену (что пришло, то и заменил). Именно поэтому я использую patch, как в контроллере (об этом в будущем), так и в сервисе.
Visit - не такой как все!
Модуль Visit отличается от всех остальных как набором методов, так и их функционалом. Возьмём в пример метод find. Принимает начальную и конечную даты, а так же посетителя. Возвращает же посещения в указанном диапазоне (если не указан - все посещения до нынешней даты)
Но это не единственное отличие от других. Метод patch отсутствует, потому что проще удалить посещение и добавить новое. В сущности посещений нет ни заголовка, ни описания, в отличие от группы и типа посетителя.
Контроллеры
Подключение сервисов
В конструктор каждого контроллера подключается сервис и с его помощью происходит взаимодействие с сервером.
Прощу заметить, что имена методов контроллера соответствуют именам методов сервисов
Получение данных для взаимодействия с сервисом
- Где же брать данные, которые будут переданы в сервисы?
- @Query, @Body, @Param!
Эти декораторы позволяют получать данные с клиента.
@Param - принимает данные из параметров, которые указаны в запросе
@Body - принимает данные которые указаны в Body запроса
@Query - принимает данные из строки запроса
- Что за relations?
Приведу пример:
- "Хм... Нужно вывести группу у этого пользователя. Придётся делать запрос и получать типы и посещения, которых может быть огромное количество".
- "Не волнуйся, у меня есть @Query! Сделай вот так: localhost:3000/visitors?relations[]=group"
- "Вау, спасибо тебе бекенд разработчик, но не мог бы ты добавить GraphQL?"
- "Нет ;)"
Вот таким необычным способом я частично решил проблему избытка данных с сервера
Swagger
Одинаковые названия методов, следование принципам REST - всё это конечно хорошо, но лучше сделать ко всему этому документацию. На помощь приходит Swagger
С помощью него можно легко документировать наш API.
Доступ к Swagger лежит по пути localhost:3000/api
Послесловие
В следующем выпуске я затрону клиентскую часть, где подробно опишу архитектуру React приложения и стек технологий. Если вы хотите подробное описание какого-либо момент - просто напишите об этом и я с радостью это сделаю
