Дно? ДНИЩЕ. Просто каждый день падает на половину. До конца дня у меня 3 часа, а заработок 43 рубля при трафике в 1100 хостов. и 3500 видимых просмотров.
Переходы с яндекса 51%.
Блок Лента вообще ничего почти не дает. cpmv там упал с 700 до 64. cpmv обычных блоков упал до 17.
Клики как с самого утра 37 так и застыли на 37. Вообще не прибавляется.
Нет, я думал ты знаком с питон. Приведенный код один раз обращается к файлу, получает нужные данные по ключу. Потом json конвертируется в питоновский обьект типа "словарь"(dict), если не ошибаюсь, это аналог пхпэшного array, и уже в байткоде путешествует дальше. То есть ничего не разрастется. добавлю в json строку иеню - скомпилируется и буде использована. При этом мне не надо лезть руками в код-файлы, все можно реализовать через пользовательский интерфейс
И по ключу "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 требует постоянного парсинга каждый раз
