И по ключу "ru" выгребает только данные для русского интерфейса:
Fastapi умеет кэшировать данные и пока пользователь не сменит язык - ему будет подгружаться интерфейс из "ru" интерфейса. То есть в шаблонизатор приходит малюсенький обьект только с тем что нужно.
Ну, выше, я вроде уточнил свой вопрос. В дискуссии принято исходить от высшего уровня к нижнему. Архитектура приложения. Сначала интерфейс, потом детали реализации. в данном случае интерфейс(хранение в файлах( пусть даже и в коде) предпочтительнее хранения в базе. Это слишком дорого. Да, в коде - самое быстрое, но чревато проблемами, описанными выше. Ну и хранение в разных файлах противоречит как SOLID так и DRY - не повторяйся. У меня один роутер будет обрабатывать все языки, соответственно если мне нужно поменять что-то, мне нужно поменять что-то в обработчике и в языковом файле, а не в 6 разных файлов для 6-ти языков.
ещё раз повторяю, я не агитировал за хранение текстов интерфейса в базе, а обратил внимание на глупый вопрос "как мне потом обрабатывать это? "
и на вашу текущую реализацию
1 - во-первых с портянкой со всеми языками в одном файле, зачем если нужен только один язык, подгружать сразу все переводы? их надо как минимум разнести по разным файлам для каждого языка отдельно, а как максимум и отдельно для каждого модуля, плюс один общий
2 - во-вторых каждый раз при загрузке этих переводов будет парситься json, это тоже накладные расходы, по-хорошему надо или хранить в отдельных py файлах, чтобы далее сгенерировался байт код pyc или прикрутить компиляцию джейсона в py, а далее в pyc
Вот интересно, что? Это очень дилетанские подход. Хранить прямо в коде можно данные, которые гарантированно никогда не изменятся после выхода в прод. И даже в этом случае это лучше хранить в переменных окружения, вычитывая их из .env файла.
и расходы на чтение файла и на работу интерпретатора одинаковые
языковые файлы, если вы не в курсе, они есть во многих популярных cms (например DLE) и хранятся также, как и у меня в отдельных пхп файлах с объявлениями массивов, в отдельных директориях для каждого языка, они как раз и не изменяются, в вашем интерпретаторе расходы может быть и одинаковые, а в пхп нет, при включённом opcache они компилируются в байт код и никакого парсинга кода программы в дальнейшем не происходит, всё работает очень быстро, более того, даже скомпилированные пхп файлы я храню на рам диске, всё читается из оперативной памяти
PS: и да, если хотите не по дилетантски, используйте gettext https://habr.com/ru/articles/73554/ , а я буду наслаждаться высокой скоростью своего велосипеда
vitaliy11 #:
(json или просто обычный массив в php файле).
вот здесь разница существенная, обычно везде уже включен opcache, поэтому там где он включен, то быстрее будет хранение в пхп файлах, сам так храню, а json требует постоянного парсинга каждый раз
аналогично, со вчерашнего дня
вы самое главное не учитываете, еще раз самое важное: это имеет значение когда вы единственный единоличный пользователь диска, т.е. когда это выделенный сервер. вдс и тем более шаред хостинг - там тыщи пользователей, которые займут ресурсы и будет скорость диска 1 мб/с, я видел как в тарифе было написано гордо про nvme диски, а скорость записи 1 мб/с.
Andrey_One , видимо предыдущие ораторы вас троллят, разница конечно же будет ощутимой, в HDD механика позиционирует считывающую головку, это всегда будет медленнее, чем мгновенный электронный доступ к нужным данным в SSD, кроме того есть колоссальная разница и в случайном доступе к файлам в пользу SSD, несмотря на то, что в HDD применяются кэши, все данные все равно не закэшируешь в их оперативной памяти (обычно до 256 МБ)
это никакая не сложность, чтобы не засорять оперативную память ненужными данными, которые для отрисовки данной страницы не нужны, нужно ввести в указанной таблице поле с идентификатором меню и вытаскивать записи по нему и по языку
PS: Ваш вариант мультиязычности не выдерживает никакой критики - выгребать джейсон со всеми переводами каждый раз при работе программы, чтобы получить только перевод на один язык - это подход программистов, которым для обеспечения работы лендинга выделенного сервера мало
