## Ответы на вопросы ШМБ от 16.01.2020

### 1. Описание тестов, схема/правила написания, как запускать.
Тесты запускаются следующей командой

dotnet.exe test Tests\Compass.Tests

На teamcity добавляются параметры

dotnet.exe test Tests\Compass.Tests /p:CollectCoverage=true /p:CoverletOutputFormat=teamcity

В папке Tests\Compass.Tests следующие тесты

/EntityHelperTests - тесты на хелперы для сущностей бд
/GraphQLTests - здесь хранятся все тесты на graphql api
/Modules - здесь все что относится к rest api
/NotificationServiceTests - это тесты сервиса нотификаций
/ViewTests - это тесты на view которые лежат в бд

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

Для моков используется библиотека Moq.

### 2. Пошаговое/подробное описание авторизации.
#### AccountController

`Login` - основной ресурс выполняющий аутентификацию по логину/паролю, прописывает токен в куки

`ExternalLogin` - точка входа для авторизации через соцсети, далее следуя процедуре oauth соцсеть делает редирект на `ExternalLoginCallback`

`ExternalLoginCallback` - завершает процедуру аутентификации через соцсети, прописывает токен в куки

`CreateOAuthAccountCode`, `OAuthExchangeCode` - это наша примитивная реализация протокола `OAuth`, чтобы позволить сторонним сервисам (в том числе и нашим) авторизоваться через сайт КЦ. Насколько мне известно эти ресурсы пока не используются. `OAuthExchangeCode` вызывается без авторизации т.к. этот ресурс будет вызывать стороннее приложение которое не имеет токена пользователя, но имеет его одноразовый авторизационный код.

### 3. Описание работы текущего оператора платежей.

Используем яндекс кассу. Документация с из api здесь https://kassa.yandex.ru/developers/using-api/basics

Наша реализация находится в классах

`PaymentPublicMutation` - мутация graphql с которой начинается процедура оплаты

`PaymentPublicInsertOperation` - операция которая создает оплату в бд

`PaymentPublicPostInsertOperation` - операция которая реализует всю дальнейшую логику после вставки оплаты в бд. В том числе она запускает `PaymentPublicYandexRequestOperation`

`PaymentPublicYandexRequestOperation` - реализует непосредственное обращение к кассе и обновляет оплату в бд

`OrderController.CaptureYandexPayment` - принимает обратные вызовы от Кассы к нашему серверу с информацией об изменении состояния платежа.

Выдача кассовых чеков реализована через сервис https://developers.cloudpayments.ru/.

### 4. Подключение нового оператора платежей.

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

Чтобы добавить другой шлюз нужно дополнить таблицу `Payment`, `PaymentProvider` под потребности этого шлюза, и реализовать необходимые методы в `GraphQl` API и методы обратного вызова от шлюза к серверу, которые он требует, а так же необходимо доработать интерфейс сайта и админку.

### 5. Общая схема работы сайта.
Общая схема примерно следующая


Showcase - это скрипты которые встраиваются на сайт ШМБ и отрисовывают курсы в соответствии с заданными настройками.

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

Hangfire - часть сервиса api, используется для фоновых задач и задач которые нужно запускать по расписанию. Например рассылки писем.

### 6. Схема работы UI.
UI написан на React. Для ШМБ используется js скрипт который рендерит курсы ШМБ в соответствии с заданными настройками.

### 7. Схемы работы Back.

См пункт. 5

### 8. Описание сервисов.

См пункт. 5

### 9. Описание схемы хранения (БД).

Не очень понятен вопрос. Схему бд можно посмотреть через стандартные инструменты (например DataGrip от JetBrains или MSSQL Managment Studio).

Вцелом все сущности базы данных лежат здесь - `src\Compass.Data\Entities`

### 11. Зачем нужны (какую проблему решают) вью в БД?

View в базе данных решают проблему N+1 для graphql запросов, они были созданы для оптимизации кол-ва запросов в БД.

### 12. Причина использования autofac, чего не хватило в стандартном контейнере.

Так исторически сложилось, когда начинался проект в dotnet не было своей реализации контейнеров, популярными в то время были autofac и unity.

### 13. Причина использования для доступа к данным LinqToDB, почему не более распространенные энтити или дапер.

Так исторически сложилось, когда начинался проект не было EF Core, а в EF на тот момент был ужасный механизм миграций, с которым постоянно были проблемы при командной разработке, + в качестве БД рассматривали postgres. EF тогда поддерживал только MS SQL.

### 14. Какую задачу решает прокся в UI.

Имеется ввиду normalize proxy?

### 15. На какую нагрузку рассчитано решение?

Решение более менее держит нагрузку 26 rps. Это ~ 150 активных пользователей на сайте (точных метрик нет, расчет основан на данных из GA и не учитывает витрины). Пока что этого хватает. Есть известная область оптимизации, все решения мы описываем в задачах, к сожалению пока некому этим заниматься.

### 17. Закладывалась ли возможность горизонтального масштабирования? Если да, то описание.

Не измеряли, текущее решение было сделано давно, хотим перенести хостинг картинок на S3 совместимое хранилище.