Roman K

Петь перестали

Взять лучше такой, на котором не залипает клавиатура

1. Пользователь открыл страницу и ушёл заваривать кофе. Потом забыл о странице и ушёл в лес на неделю. Вернулся спустя неделю, закрыл страницу. Сколько времени он провёл?
2. Пользователь открыл страницу, проскроллил до середины за 10 секунд, переключился на другую, поработал там 30 минут, вернулся к твоей странице, посмотрел 5 секунд, закрыл её. Сколько времени он провёл?
3. Всё тоже самое, только у пользователя стоит аддон, который выгружает вкладки из памяти.
4. То же самое, что пункт №2, только это происходит на мобиле, он не выгружает браузер из памяти сутки, после чего телефон садится, после чего, спустя 12 часов, телефон снова включается и пользователь запускает браузер, вкладка с твоим сайтом всё ещё болтается в фоне
5. Пользователь открыл страницу, но читает он со скоростью 1 буква в минуту и так он просидел 24 часа, после чего проскроллил ещё на страницу вниз и принялся читать новую порцию инфы. Сколько времени он проведёт суммарно после того, как дочитает эту порцию инфы?

Мне кажется (я могу ошибаться), что если при получении каждого нового сообщения сохранять его в базу (что-то типа ChatModel.findByIdAndUpdate(chat._id)), то это будет сильно нагружать процессор.

Зависит от способа организации данных, от самих данных, от нагрузки. Одно дело, когда одновременно ведут диалог 10 человек и другое, когда 10 миллионов.

Можно делать по-другому: записывать все прилетающие сообщения в переменную. Затем каждые, например, N сообщений делать апдейт поля в базе, конкатинируя получившуюся строку с уже хранящейся.

1. Это ненадёжно. Например, у тебя работает 15 разработчиков, каждый из них деплоит 2 раза в день в течении рабочего дня. Итого, каждые ~16 минут у всех теряется несколько рандомных сообщений.
2. Ты хочешь сохранять каждые N сообщений. Представь, что я написал N-1 сообщений и потерялся на год. Уж за год сервер точно один раз передеплоят и все мои сообщения потеряются. Здесь нужны таймеры

В общем, посоветуйте хороший способ реализации быстрого и не слишком затратного способа сохранять историю чата

Установить rocketchat/mattermost/etc.

А если серьёзно, то проводи нагрузочные тесты. Если юзеров будет 1.5 землекопа — сделай просто "как-нибудь". Вот когда миллионы юзеров будут, тогда приходи... А стоп, когда у тебя будут миллионы юзеров, у тебя хватит денег нанять людей, которые перепишут как надо

Ну допустим, измени код

но толкового примера не нашел

Потому что его не может существовать физически. JSON нельзя просто склеить. Например, в файле 1.json будет [1,2,3], а в 2.json будет [4,5,6]. Они как должно склеиться? Как [1,2,3,4,5,6] или как [[1,2,3], [4,5,6]]? Если в файле 1.json будет null, а в 2.json будет "2" — как их склеить? Это вообще невозможно. Если в 1.json будет {"a": [1,2,3], "b": 2}, а в 2.json будет {"a": [4], "c": 3}, результат должен быть {"a": [1,2,3,4], "b": 2, "c": 3} или {"a": [4], "b": 2, "c": 3} или [{"a": [1,2,3], "b": 2}, {"a": [4], "c": 3}] или {"a": [[1,2,3], [4]], "b": 2, "c": 3} или как?

Для конкретного формата JSON нужно установить правила мержа, которые удовлетворяют твоим требованиям.

Если последняя страница содержит полностью идентичные ссылки, что и предыдущая — предыдущая была последней

Закрытие канала jobs делает выход из цикла for j := range jobs, функция заканчивается, горутина убивается. В чём вопрос?

Слава Гвидо, нет

Идеологически нет ничего плохого в том, чтобы бросить ошибку в async функции. Она корректно разрушит флоу кода, если промис async функции вызывающая сторона await'ит. и не отловила Другое дело, что в JS промис можно не await'ить, бросание эксепшенов довольно дорогое (по времени) и вообще, эксепшены — это те же goto, только чуть более предсказуемые. Лучше кидаться rust-like контейнерами Result[T, E]. К тому же, их можно типизировать в TS, в отличии от эксепшенов

Что такое "концепция асинхронности" и что асинхронного в твоём коде (кроме ничего)? Ты просто натыкал async def в рандомных местах.

import string, itertools

itertools.combinations_with_replacement(string.digits + string.ascii_lowercase[:11], 3)

1. Goland, а не Golang. Golang — это язык, а то, что от JetBrains — IDE с именем Goland
2. Изучать синтаксис SQL. Никакого отношения к Golan(d|g) "ошибка" не имеет
3.

Дальше будут сложнее запросы?

То, что ты написал — самый элементарный запрос. Проще только SELECT 1; Очевидно, будут сложнее

set(кто в первом списке) - set(кто во втором списке)