Реализация API Блогера, со следующим функционалом:

1. Полноценная авторизация и регистрация. Работа с почтовыми ящиками(nodeMailer) и кодами активации учетной записи(uuid). Работа с шифрованием паролей пользователя(bcrypt). Работа с различными сессиями пользователя. Работа с Access и Refresh токенами(jwt)
2. Реализованы роли superAdmin и blogger, а также публичная часть
• superAdmin может - банить/разбанить блог(все посты такого блога не отображаются в публичной части)
• superAdmin может - привязать юзера к блогу(если у блога нету владельца)
• superAdmin может - банить/разбанить юзера(забаненный не может логинится, все сессии становятся не валидными, все посты, комментарии и лайки не видны и не подсчитываются)
• superAdmin может - создавать и удалять юзеров
• superAdmin может - получать расширенную информацию о всех блогах и юзерах
• blogger может - CRUD блога и постов
• blogger может - банить/разбанить любого пользователя для каждого из своих блогов(забаненный не может комментировать посты того блога для которого он забанен)
• blogger может - получать информацию о забаненных пользователях, для каждого из своих блогов
• blogger может - получать информацию о своих блогах и постах, а также одним запросов получать все комментарии которые относятся к его блогам и постам
• Публичная часть - CRUD комментариев
• Публичная часть - Возможность ставить лайки и дизлайки комментариям, а также отменять их
• Публичная часть - Возможность получать все комментарии и если пользователь авторизован видеть свою реакцию на них
• Публичная часть - Возможность ставить лайки и дизлайки постам, а также отменять их
• Публичная часть - Возможность получать все посты и если пользователь авторизован видеть свою реакцию на них, а также последних 3 пользователей поставивших Like
• Публичная часть - Возможность получать информацию о всех блогах, о себе и своих сессиях(если авторизован)
3. Все GET запросы на получение массива данных, поддерживают пагинацию, которую можно задавать через URI параметры
4. Весь проект, на всех стадиях проводит валидацию входящих данных(dto, class-validator) и запрограммированы исключения в случае если данные неправильные(400), не найдены(404), защищены(401), или пользователь пытается работать не со своими данными(403)

Nest, mongoDB, mongoose, typeScript, cqrs, jwt, bcrypt, jest, supertest

1. Весь проект реализован на Nest и TypeScript(причем any в коде вы скорее всего не найдете)
2. Авторизация и регистрация сделана через nodemailer, через gmail transport со всем стеком восстановления пароля и почты, повторной отправки кода и проверкой на уникальности логина и почты при регистрации
3. Исключения улетают на фронт, определенного вида, реализовал с помощью настройки exception фильтра
4. Весь проект реализован в логически выстроенных раздельных модулях с минимальной завязкой между собой, никаких циклических зависимостей или избыточнх модулей
5. Все сервисы раздроблены на отдельные use-cases, через commandBus
6. Защищенность ендпоинтов, реализована через локальные стратегии Nest, Local(для начальной авторизации), Access, Refresh, Basic(для superAdmin). Также есть Quest, это мой самодельный костыль для реализации логики получения реакции на пост или коммент пользователя зашедшего с токеном на незащещенный ендпоинт. Таким образом если у пользователя есть токен, то покажется его реакция, если пользователь не авторизован, то покажется None. Мне просто хотелось, чтобы все было реализовано через стратегии
7. Access токен отдается в качестве response, а Refresh зашивается в Cookie not only, время жизни 10 минут и 10 часов соответственно
8. Защита от DDOS, реализована через встроенный throttler от Nest, не больше 5 запросов за 10 секунд и стоит только на ендпоинтах связанными с почтой и отправкой писем
9. Работа со скрытыми данными, настройками и паролями, реализована через файл config и env файл локально и удаленно
10. Есть тесты покрывающие часть логики в основном e2e
11. Работа над проектом велась, по предоставленной Swagger документации из которой взяты все требования к входящим данным и эти требования проверяются на уровне dto(с помощью стандартных декораторов, а также самописных валидирующих классах) и на уровне БД
12. В проекте реализован обычный repository, для внутренней работы связанной больше с CRUD операциями, а также реализован queryRepository для более быстрой работы GET запросов напрямую, обходя дополнительную логику сервисов и use-cases.
13. Так как это Mongoose, работа организована со всеми плюсами данного подхода, работа с моделями mongoose, работа с entity и методами entity. Все коллекции разбиты логически, лишних коллекций практически нету. К примеру в постах, все лайки хранятся в массиве с привязкой к конкретному посту, а дальше берутся оттуда и обрабатываются. Сессии юзера, привязаны непосредственно к юзеру. Если необходимо в одном модуле работать с разными моделями, во избежании циклических зависимостей, запросы проходят через Auth модуль, репозиторий которого имеет доступ ко всем коллекциям. Сложные запросы, очень тяжело обрабатывать, так как приходится писать много лишнего кода, для обработки информации в основном методами массивов JS.
14. Код полностью асинхронный(async/await) и легкочитаемый, структура папок выбрана мной исходя из практик подобных проектов других более опытных разработчиков.