Size: a a a

2020 April 10

AD

Alexander Dudaev in pro.elixir
просто не через firebase надо делать?
источник

_

_ in pro.elixir
Просто не используйте остальные продукты firebase,  на сайте в pricing все описано
источник

МБ

Максим Барулин in pro.elixir
Lama Lover
Так а зачем эти функции (не методы)? Они ничего не ускоряют, просто увеличивают количество кода, хотя реализация типа
def get_from_config(param_name) do
 :ets.lookup(:config_table, param_name)
end

Была бы такой же по времени исполнения, а главное - повысила бы читаемость.

Но лучше забудь про это реализацию: хранить конфиги в :ets - это плохая идея. Лучше попробую :persistent_term и доставай оттуда явно. Зачем тебе обёртка в виде функции, которая просто вызывает другую функцию.

Итого:
При иничиализации приложения
Application.get_all_env() |> Enum.each(fn {k, v} -> :persistent_term.put({:my_app_config, k}, v) end)

При доступе к конфигу
:persistent_term.get({:my_app_config, k}) сразу в коде. Без функции обёркти (хотя, если очень хочется, то можно, но только если заинлайнить)
ок, попробую persistent_term. Но вот почему ets плохая идея? Чем он плох?
источник

LL

Lama Lover in pro.elixir
Максим Барулин
ок, попробую persistent_term. Но вот почему ets плохая идея? Чем он плох?
Тем, что если нужен быстрый доступ, то есть :persistent_term, если не нужен быстрый доступ, то можно через Application.fetch_evn!, а если конфиг нужен в генсервере (а это самый частый случай) то лучше всего класть в стейт при инициализации
источник

МБ

Максим Барулин in pro.elixir
прочитал доку по persistent_term, в общем-то понятнее стало
источник

AB

Alex Bubnov in pro.elixir
Пожалуйста, не надо тащить ets и тем более persistent term, когда можно обойтись application env
источник

МБ

Максим Барулин in pro.elixir
Alex Bubnov
Пожалуйста, не надо тащить ets и тем более persistent term, когда можно обойтись application env
Блин, но почему? Чем плохо использование имеющихся инструментов для решения задачи? Чем persistent_term хуже application env?
источник

AB

Alex Bubnov in pro.elixir
Тем, что env это замаскированая специально для конфигурации ets, а persistent term - специализированная тулза для оптимизации, которая в некоторых случаях делает full gc?
источник

МБ

Максим Барулин in pro.elixir
т.е самый правильный вариант выглядит так?
источник

LL

Lama Lover in pro.elixir
Alex Bubnov
Пожалуйста, не надо тащить ets и тем более persistent term, когда можно обойтись application env
Application.get_env - это долго
Суть в этом
источник

LL

Lama Lover in pro.elixir
Когда рантайм конфигурация только на чтение, то использовать :persistent_term - лучшее решение
источник

AB

Alex Bubnov in pro.elixir
На каком rps оно становится долго?
источник

PG

Pïg Grëënëst in pro.elixir
не всегда нужно читать конфигурацию пиздец как быстро
источник

AB

Alex Bubnov in pro.elixir
В конце концов, конфигурацию можно на старте вычитать в локальные стейты
источник

LL

Lama Lover in pro.elixir
Alex Bubnov
На каком rps оно становится долго?
На любом, насколько я помню, Application.get_env смотрит в стейт этого application
источник

LL

Lama Lover in pro.elixir
Alex Bubnov
В конце концов, конфигурацию можно на старте вычитать в локальные стейты
Я это указал как лучшее решение
источник

AB

Alex Bubnov in pro.elixir
Lama Lover
Я это указал как лучшее решение
А, и вправду
источник

LL

Lama Lover in pro.elixir
Pïg Grëënëst
не всегда нужно читать конфигурацию пиздец как быстро
Да, но почему бы не делать это всегда оптимально, учитывая, что это не сложно и никаких функциональных проблем это не создаёт
источник

LL

Lama Lover in pro.elixir
Я же не говорю использовать FastGlobal, который за собой тянет compile_tools
источник

PG

Pïg Grëënëst in pro.elixir
Lama Lover
Да, но почему бы не делать это всегда оптимально, учитывая, что это не сложно и никаких функциональных проблем это не создаёт
full gc тебя не смущает?
источник