Added docs initial state

lleokaganov commented 3 months ago

Мне кажется, имеется непонимание, как работает плагин. У плагина всего один вопрос: оплачен ли заказ номер 133? Этот запрос плагин задании демону много раз - до отправки денег, после отправки, при ручном перечислении, после любой перезагрузки страницы при каждой новой попытке... У плагина нет информации, делал ли он этот запрос прежде - страницу могли перегрузить и все запустить по-новой.

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

Делать вместо одного запроса два разных "создать" и после "узнать" бессмысленно: плагин всё будет делать как в первый раз, посылать их подряд. Только удвоится нагрузка на сеть и риск глюков.

Прошу вернуть архитектуру к единому запросу.

Также мне видится неправильным создание голема из формата JSON с примесью ошибок протокола HTTP. Ошибки HTTP предназначены для другого уровня, их сложно обрабатывать (JS так и вообще бы не смог получить такой JSON без адских костылей). Код ошибки и поле "error" должны содержаться в самом JSON, при этом серверный ответ демона должен быть всегда и в любом случае OK 200, так как пакет доставлен успешно и сбоев на транспортном уровне нет.

Slesarew commented 3 months ago

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

мы контролируем сигнальный стак магазина (в общем случае это не так)
магазин будет как-то обрабатывать эти ошибки (лол нет конечно, терпеливый юзер выкинет нахуй наш стак на второй ошибке и всё)
в магазине можно реализовать сложную логику (ну можно но в каждом свою, значит не надо на это рассчитывать в унифицированном узле)

Мне охеренно нравится дизайн @kirushik , в котором транза формируется на стороне магазина. Только возвращать тогда её надо не жесоном, а прямо скейловой котлеткой. Тогда счёт всё ещё может оплачивать фронтенд, и по-моему это правильно, просто формирование заказа произойдёт в одном единственном месте на все плагины и приедет в плагин уже гексострокой. Это решит кучу проблем о которых вы ещё не подозреваете даже потому что они только собираются случиться этой весной или летом. И хорошо бы съехать с субкст на наш субстратоклиент к этому моменту, что будет по идее просто.

Соответственно, из (1) так же следует, что запросы хорошо бы просто завернуть в жейсоны с каким-то унифицированным верхом.

Потому что наш демон таки нифига не сервер, потому что его клиенты - не клиенты, а чужой код сомнительного качества с нашим великолепным плагином ограниченным неопределёнными обстоятельствами.

Тогда мы возвращаемся к единому запросу

{
  order: id
  price: f64
}

и единому ответу

{
  order: id
  status: waiting {
    wss: string
    transaction: string
    recipient: string
  }
}

или

{
  order: id
  status: paid
}

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

если демон шлёт ошибку, он просто шлёт "йа обосралос" 500, а если кому надо дебажить - велкам в консоль демона куда он будет подробно объяснять, какая консистенция температура и количество и есть ли кровавые выделения

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

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

Slesarew commented 3 months ago

да хер мы транзу соберём так - нужен же нонс для этого нужно знать номер аккаунта посылателя. Посылать в демона номер аккаунта посылателя?

{
  order: id
  price: f64
  account: option<string>
}

и возвращать соответтсвенно если есть аккаунт то транзу а если нет его то адрес. Так можно фронтом вилять?

Alzymologist / Kalatori-backend

Added docs initial state #5