Boris Korobkov, спасибо! Я закомментировал SendEnv LANG LC_* и это помогло. Т.е. до этого получается что сервер вынужден был запускать процесс в кодировке клиента, а теперь он работает в своей кодировке по-умолчанию?
lexas, спасибо за Ваш ответ! Он заставил меня более внимательно присмотреться к используемым в проекте кодировкам по-умолчанию и задействовать forbidden-apis для поиска подобных мест в проекте.
Да, Вы абсолютно правы.
2 - Я изначально планировал открыть вебсокет и с сервера кидать туда нотификации, но потом как-то в итоге это переросло фактически в использование просто 1 запрос/1 ответ. Потому Rest будет более правильным вариантом.
3 - Спасибо, почитаю про RabbitMQ и про масштабирование систем.
4 - согласен.
Иван, спасибо за ответ!
1 - да, сейчас у меня просто JS на фронтенде.
2 - ну фактически он получился однопоточный, потому что я отправил ответ и не шлю следующий пока не получил ответ по предыдущему. В данный момент у меня один websocket используется, т.е. я открыл соединение, передал по нему что-то, не закрываю пока не получил ответ или оно само не закрылось. Я так понимаю, можно просто открывать несколько соединений параллельно. Правильно понимаю? Или как лучше сделать?
3 - я имел ввиду использование микросервисов для того чтобы получить подобие распределенной системы, хотя наверное в данном случае оно явно лишнее, т.к. один сервис и так сможет обрабатывать множество параллельно приходящих запросов (если распараллеливание сделать до него, например на фронтенде).
4 - Использование уже готовых брокеров сообщений лучше с точки зрения того чтобы не городить самописные очереди сообщений (со всеми вытекающими из самописного решения багами)?