Тем не менее когда клиент отключен, процесс должен продолжать собирать данные для истории и графиков.он точно должен так же собирать данные каждую секунду, когда клиентов нет ? или только отображать их каждую секунду когда клиент подключился к нему ?
а надо сверять время на твоём сервере с временем в БД на ЭТОМ же сервере...я понял, спасибо, я это перепроверил ( с локальным временем ), там всё норм, изначально да я не туда смотрел, бывает
const a = moment().utc().toDate();
const b = moment(serverDate).utc().toDate();
const diff = moment(b).diff(a); // это миллисекунды разница между клиентским и серверным временем, я его просто потом везде добавляю при вычислениях, например в таймерах и т.д
Начните с простого - перезапустите MySQL, а затем сверьте время в OS и в MySQL. Убеждён, что они совпадут.это я проверял, они одинаково отображают - на пару секунд вперед, когда я захожу на сайт, мой клиент тупо отстаёт на 4 секунды от серверных секунд
Ага... а то, что от изменения времени в системе и до отображения его на экране могло и больше, чем 2 секунды, пройти - вы не учитываете, да?нет
moment().utc().toDate() - выводит уже 28 секунд, на 3 секунды вперед, хотя весь запрос с клиента на бэк в целом занимает 200мс
timedatectl status
Local time: Tue 2026-01-06 20:47:45 UTC
Universal time: Tue 2026-01-06 20:47:45 UTC
RTC time: Tue 2026-01-06 20:47:46
Time zone: UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: nomoment().utc().toDate() ?moment().utc().toDate() 2026-01-06 20:47:41
disableVerticalSwipe всегда срабатывает без ошибоксудя по видео не срабатывает
import {
initMiniApp,
initSwipeBehavior,
initViewport
} from '@telegram-apps/sdk-react';
(async () => {
const [ miniApp ] = initMiniApp();
const [ swipeBehavior ] = initSwipeBehavior();
const [ viewport ] = initViewport();
const vp = await viewport;
// отключаем свайп если включен
if(swipeBehavior.isVerticalSwipeEnabled){
swipeBehavior.disableVerticalSwipe();
}
vp.expand();
miniApp.ready();
})();
Repository похож на просто замену orm, просто методы для работы с бд, возможно так писали когда-то давно или сейчас так пишут на проектах который например государственный где нельзя юзать какие-то лишние зависимости, и пилят это всё вручную ( моё предположение ), но я обычно юзаю orm и не занимаюсь таким барахлом
привязан ивент или транзакцияименно про транзакцию ( если имеешь ввиду оплату ), думаю это можно пользователю с клиента указать в какую именно игру он хочет оплатить ( всё равно что заполнить форму ), а на бэке проверять есть ли действительно такая и игра и т.д ( айдишник игры мб к примеру )
я вижу вы пытались через цикл сделать наблюдатель, это плохое решение
вы можете заюзать rabbitmq ( хз если ли в rabbitmq уже что-то похожее ) или bullmq
когда с клиента отправляется к примеру запрос на бэк ( начать отслеживать устройство ) , тем временем, на бэке - вам нужно запускать задачу ( создавать задачу в bullmq ) для этого устройства которая сама себя будет порождать при успешном выполнении через , каждые N времени которое указано у настроек проекта
то есть внутри самого обработчика задачи можно написать Bun.sleep(N) - если это пару секунд, если N - это не больше пару секунд, если N будет больше 2-5 секунд, то лучше вообще отложенные задания использовать , эти отложенные задания тоже есть в bullmq, когда задача создается - добавляется запись в Redis
когда клиент захочет остановить опрос, удаляем задачу - то есть удалиться запись из редис, и устройство наблюдатель грубо говоря отключиться
поизучайте bullmq, он мощный