гугл таблицы не лучшая реализация БД)))
Может стоит вынести весь товар в отдельную БД поддерживающую блокировки и транзакции а гугл таблицу использовать только как средство отображения?
naruto3333, а вот это уже пример (достаточно запутанный и лапшеобразный) событийной модели с ws транспортом двухстороннего обмена данными (событиями) между клиентами и сервером (не смотрите все то что там связанно с кластерами, смотрите то что связанно с вэбсокетами, а лучше начните распутывать с кода клиентской части и затем уже лезьте в app.js ))))
Сразу предупреждаю, это в общем то велосипед, для таких целей принято использовать не свои самописные модульки а что то типа socket.io с его достаточно широкими возможностями
naruto3333, нет не получается. На сервере вся ваша викторина это просто данные в БД привязанные к определенному ID игры и простейший CRUD для доступа к ним. Если клиенты отвалились и никогда не зашли в викторину то просто эти данные надо подчистить (или оставить как незавершенные игры для статистики). Подчистить можно по крону (отдельным приложением, запускаемым например раз в сутки) или уже таймеру на самом сервере (тут сложностей не возникнет я думаю).
naruto3333, проблема вашего вопроса в том, что он очень общий, на каждый пункт можно придумать десятки принципиально разных реализаций, при этом требующих различных архитектурных подходов. Ответить конкретикой на ваш вопрос нельзя, а если даже сделать решение, не факт что оно попадет в зону вашего видения и не будет вами отвергнуто. Вот скажите, оно мне (или кому еще) надо? Писать достаточно много кода чтобы вы потом либо сказали что не подходит/не разобрались, либо начали бомбить в комментах кучей уточняющих вопросов и просьб по типу "Так мне не подходит, нужно по другому, дайте мне ....?" или "а вот тут не могли бы вы помочь привязать слона к банану?"
naruto3333, вот вам 1 из множества вариантов:
Создавайте таймеры на клиентах, и по истечении заданных таймаутов запрашивайте данные у сервера (по http или ws) а на сервере просто ведите контроль времени по временным меткам (timestamp-ам).
Когда досконально разберетесь с этим, поймете и усвоите, увидите минусы и плюсы выбранных подходов и стека технологий, приходите сюда, и задавайте уже конкретные вопросы, с примерами кода и описанием выбранной/придуманной вами архитектуры, просите совета как сделать лучше, спрашивайте (если не найдете в интернете сами) какие есть альтернативы выбранному вами подходу и в чем их плюсы/минусы, изучайте то что вам посоветуют, составляйте свое мнение и выбирайте тот путь который вам понравится больше .
Они (правильные вопросы) к тому моменту а вас точно появятся.
если у вас одновременно будет небольшое количество викторин и пользователей, ну скажем до 1000 (число взято с потолка и зависит от многих факторов), то вам вообще можно не париться об архитектуре и реализации, пишите как видите, в процессе приобретете бесценный опыт и понимание где вы накосячили как в архитектуре так и в реализации (коде). После того как несколько раз перепишите все с нуля можете претендовать на юниора фулстак))))
сделал вот такую вот фигню https://www.npmjs.com/package/msg-router и теперь думаю как дальше в этом модуле правильно развести роуты, контроллеры, модель данных, бизнес-логика, orm, dto и прочее.
