А вообще, как верно заметили выше, select для мелких задачек - топ. И считывание с канала туда, и ловилку sigterm для graceful завершения)

О, про sigterm тема классная, но если по чистой архитектуре пилить, тут уже вопрос, какую прослойку сделать)

Если бд монга можно контекст to do выбрать, правда нет гарантии что после записи сразу чтение прокнет.
Для постгри или мускула, хм, очереди, да, но тож могут переполниться :(
Я обычно сигналы тож на каналах пилю, мы на работе в докер пихаем, оно иногда падает и хоть перед падением успеваю скинуть очередь)

https://github.com/gorilla/websocket/tree/master/examples/chat
Вот тут можно посмотреть)

У меня там прослойка вызывается, которая в транзакцию все запросы заворачивает используя Unit Of Work, короче архитектуры полные штаны, сижу вожусь теперь.

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

Да, спасибо, гляну)

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

Хорошо, спасибо) Сейчас просто после достаточно долгой работы на пыхе, где всё приложение живёт только на время запроса тяжеловато на Go переходить, намного больше таких спорных моментов

То чувство, когда на эрланге такая задачка решается строчки в три, если пренебречь красотой синтаксиса

А что под капотом происходит?

Даже в одну при желании, что-то типа
SomeFunction() -> receive AnyShit -> do(AnyShit), SomeFunction() end end.

А внутри у ней неонка виртуалка jit с 100500% оверхеда

Ни, ну эрланг зато офигенно удобен для апдейтов, да и те ж чат серваки на xmpp не зря робят, тож используем на проде для онлайн игруль

Угу... В этом и проблема, потому что у меня тут сервис, к которому могут обратиться два клиента одновременно, и мне нужно сходить к базе, получить инфу, и исходя из полученной информации записать в неё. Можно решить банальной блокировкой базы, на время выполнения запроса, но вот только тут много оверхеда придётся пилить и не совсем бизнес-логике будет соответствовать. Имхо же поставить таск в очередь и выполнять такие таски по одному, будет наилучшим решением, а сам же Erlang вроде однопоточный, поэтому такой проблемы в нем похоже не будет

>Erlang
>Однопоточный
Чёт ору

Хз, не знаю про него)

Он в многопоток мог ещё когда си# пешком под стол ходил

Ну C# это вообще отдельная история, особо непонятно выглядит, когда его тащат как бэкэнд

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

Го создали потому что хотели, чтобы эрланг мог в математику 😂