Подготовить описание сервиса логирования

[sadmadrus]

Сервис должен принимать на вход тип события, описание (ход, старт сессии, приостановка сессии,), идентификатор сессии, временную метку

[Valentina-Khoruzhaia]

Сделала набросок по сервису логирования, готова к дождю из тапок :)

Сервис должен принимать на вход, записывать в БД, извлекать из БД и отдавать обратно по запросу: событие, описание(ход, старт сессии, окончание сессии, завершение сессии), идентификатор сессии, временную метку.

Формат данных:
Для сессии:
[идентификатор сессии | временная метка | открытие сессии]
[идентификатор сессии | временная метка | закрытие сессии]
Для хода:
[идентификатор сессии | время хода | фигура и цвет | UsFEN стартовая точка | UsFEN конечная точка]

//Другие данные?
///Как лучше записывать смену фигуры, если например пешка стала королевой - в графе фигура и цвет в формате было -> стало, или как-то ещё? Или делать две графы со значениями фигуры - на начало хода и после? Склоняюсь ко второму варианту.

Временные метки по формату должны соответствовать другим сервисам, в том числе в соответствии с решением по #23.
Предполагаю, что формата Юникс должно быть достаточно, и нужно именно решить вопрос с задержкой, нужен какой-то источник мастер-клока для ориентира. Можно с её учетом добавить графу длительности хода.

API - put и get, первый для передачи данных из БД, второй для получения данных от сервиса валидации (https://github.com/sadmadrus/chessBox/blob/move-validation/VALIDATION.md).

Header с ответами 200 (успех) и 403 (неуспех) для проверки запросов к/от сервиса на ошибки. В теле ответа на запрос - значения из базы данных в формате json.

////Тут кстати возникает вопрос, кто ставит временную метку, сервис логирования, или сервис валидации хода?

[loskutovanl]

Мне смутно казалось что где-то обсуждали, что в качестве истории партии хотим записывать именно ходы а не состояние доски?
Наверное так будет занимать меньше места в БД?

[Valentina-Khoruzhaia]

@loskutovanl мне думалось, что сервис будет извлекать эту информацию из отклика сервиса валидации, брать первую и последнюю клетку хода? Или можно как-то короче это делать?

[nekr0z]

КМК, для логирования хода как такового (изменения позиции) достаточно алгебраической формы — она позволит достоверно и однозначно восстановить позицию после любого хода, и при этом займёт сильно меньше места, чем UsFEN.

[Valentina-Khoruzhaia]

Да, действительно, не подумала об этом, спасибо, @nekr0z!
Соответственно выходит, что нужно будет добавить в сервисе функцию переформатирования из UsFEN в алгебраическую форму и только после этого отправлять в БД, или я в неверном направлении мыслю?

[nekr0z]

нужно будет добавить в сервисе функцию переформатирования из UsFEN в алгебраическую форму

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

[Valentina-Khoruzhaia]

нужно будет добавить в сервисе функцию переформатирования из UsFEN в алгебраическую форму

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

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

[loskutovanl]

нужно будет добавить в сервисе функцию переформатирования из UsFEN в алгебраическую форму

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

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

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

[nekr0z]

на стороне клиента будет прописана логика обращения в разные сервисы

А что мы здесь называем «клиентом»? Потому что если клиент — это графическая приложенька, которую конечный пользователь запустил на своём телефоне, то заставлять её понимать, где у нас что происходит, и из каких микросервисов наша система состоит — это просто негуманно.

Должна быть одна точка, один «торчащий наружу» интерфейс, который общается с пользователем (в смысле, с приложением-клиентом), я как раз в #3 именно про API этого «наружного» интерфейса и поднимал вопрос.

Отдельный, кстати, вопрос: кто «с нашей стороны», т.е. изнутри системы, будет этот наружный интерфейс обеспечивать: сервис сессий? отдельный интерфейсный сервис, который будет сам дёргать нужные микросервисы, т.е быть «клиентом» в этом, внутреннем смысле?

[loskutovanl]

на стороне клиента будет прописана логика обращения в разные сервисы

А что мы здесь называем «клиентом»? Потому что если клиент — это графическая приложенька, которую конечный пользователь запустил на своём телефоне, то заставлять её понимать, где у нас что происходит, и из каких микросервисов наша система состоит — это просто негуманно.

Должна быть одна точка, один «торчащий наружу» интерфейс, который общается с пользователем (в смысле, с приложением-клиентом), я как раз в #3 именно про API этого «наружного» интерфейса и поднимал вопрос.

Отдельный, кстати, вопрос: кто «с нашей стороны», т.е. изнутри системы, будет этот наружный интерфейс обеспечивать: сервис сессий? отдельный интерфейсный сервис, который будет сам дёргать нужные микросервисы, т.е быть «клиентом» в этом, внутреннем смысле?

Я представляла что-то вроде app.Run где прописана логика по обращению к всем микросервисам. По аналогии с тем как в go-clean-template сделано.

Но мне не хватает знаний и навыков аргументированно спорить по этой теме

[sadmadrus]

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

[nekr0z]

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

Но при этом остальные сервисы «внутри» общаются не только с ним, а — в основном — между собой, правильно? Иначе это не совсем микросервисная архитектура…