ну мне кажется, с таким активом, не важно на чем, а важно как
и выбор языка не в большем приоритетк (в плане твоих запросов, скорости и т д)

Ребята, на чем обычно пишется бекенд дня мобильной апки?  Если данные могут измениться из другого места и мне нужно  мобильное приложение и отправить новые данные. Вебсокеты?

То, что будет тупить — последнее, о чём стоит задумываться. На Python давно можно успешно писать асинхронный и быстрый нетворкинг (uvloop, httptools, fastapi). Ну и, признаемся, 1000 юзеров — это очень скромные цифры:)

Больше стоит переживать за динамическую типизацию, т.к. проект крупный. Может помочь mypy, но стоит сперва к нему присмотреться.

Ну или сразу взять язык со статической типизацией)

Ну или да:)

Ноду бери

На том что лучше всего знаете

вопрос больше не про язык, а про транспорт. Будет php и laravel  ине я решаю а фирма

Пусть фирма и транспорт решит тогда:)

> Если данные могут измениться из другого места

Тут не понятно, как они меняются? Можно сказать, что хттп запросом можно из апишки новые данные получить

Данные в реалтайм должны обновляться?

да, к тому же мобильное приложение же не будет знать, что эти данные изменились. Допустим из админки.

пуш, сокет (зависит)

пуш уведомления то понятно, это тоже будет. Сокеты просто на ларавеле конечно тот еще гемор.

а кто-то юзал server sent events?

Добрый день. Есть вопрос по размещению логики проверок. Есть Инцидент - некоторый уникальный объект с свойствами, среди которых категория, тип инцидента и другие. Необходимо проверять как доступность самих свойств на изменение в зависимости от прав пользователя, категории и типа инцидента, а также сами доступные значения для категории и типа (пользователю может быть запрещено менять на указанную категорию или тип). И вот тут не совсем понятно где проверки должны быть. С одной стороны это права вроде как, то есть на уровне приложения до юзкейса. Но при изменении инцидента приходят только изменяемые свойства и id инцидента, приходится дозапрашивать категорию и тип, чтобы понять доступны ли свойства. А потом в самом юзкейсе опять (уже через репозиторий) получаем эти инциденты. Получается как-то неоптимально. Если же делать проверку уже полученного из репозитория Инцидента, то функционал проверки прав должен вытаскивать данные из агрегата, проверять и выбрасывать ошибку до сохранения в репозитории, если были затронуты запрещенные поля/значения. Тоже смущает.

Похоже на ACL. Обычно проверка идёт до. И в самом ACL юзаются только айдишники

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

Раньше бекенды wargaming’а были на пайтоне, eve online на пайтоне - вполне себе хайлоад

Интересная информация, спасибо.

Кстати, в плане «одновременности» как раз ева интересный показатель - у них любая отдельная битва всегда на одном шарде (не знаю научился ли кто-нибудь размазывать такое по разным шардам) и в теории количество участников не ограничено искусственно . Ну они магию придумать не смогли, поэтому когда перестают справляться просто замедляют игровое время когда совсем гигантские армады сражаются