ActiveSupport::Concern требует, чтобы был установлен ActiveSupport, а если проект не на рельсах, то не всегда он и нужен. Явно уж, только ради Concerns таскать его за собой не стоит.
Ну во-первых, манки-патчинг — это зло. Переписывать методы напрямую пример плохого тона.
В случае, если надо что-то переписать, есть несколько подходов:
1. Отнаследоваться от класса, который надо переписать и в нем дописать нужную логику.
2. Использовать цепочку алиасов.
И в том и в другом случае можно вывести всю необходимую информацию для дебага.
Для патчинга не использутся какие-либо методы, просто поверх включенных классов накладываются классы, которые смердживаются с базовыми и или переписывают методы или добавляют. Переписывать там, в общем-то, нечего.
Как по мне, так манкипатчить stdlib — это полная ярость. Что мешает отнаследоваться от базовых классов?
На самом деле, это легко детектится через caller() метод, там в цепочке сразу бы вылезло, откуда уши растут.
Смотрю я на наши графики в newrelic, и странное дело: на самых загруженных контроллерах база отъедает от рендеринга от силы процентов 20. Больше всего времени занимает сама обработка запроса, я так полагаю rack'ом.
Поэтому в моменте с затратными операциями я не соглашусь — не все так радужно в нашем королевстве, тупит руби сам по себе знатно.
NoSQL — как раз не проблема.
Нет, в принципе, если использовать вместо AR, то может и проблема. Но это уже вопрос к разработчику — зачем использовать для CRUD задач NoSQL.
В остальном же, выпиливается AR в 4 строчки.
Стоповер авиакомпании, предлагающие перелет со стыковками, как правило, стараются не предлагать.
А если брать сегменты отдельно, то выходит, как правило, дороже.
Есть смысл так искать на лоукостерах, но их в этой системе нет.
Я бы предостерег от использования. В крупном проекте последнее место, где будут искать какую-то БЛ — это экшны. Видимо автор не смог побороть искушения встроить педали туда, где они, в общем-то, не нужны.
Что меня смутило, так это асинхронные экшены. Насколько я помню, на экшны не должна ложиться задача производить какие-либо операции, кроме как диспатчить самих себя. В примерах же видно, что экшн может выполнять действие и возвращать промис. Но ведь именно этим должен заниматься store, разве нет?
Очень специфичный подход. Во-первых, в таком случае доступность данных немоментальная. Во-вторых, небезопасная — пока данные не попали в базу и не расползлись по репликам, можно потерять файл дампа. В-третьих, это двойная работа, причем сливание потока в файл — это доп. нагрузка на IO.
Одним словом, все это как минимум странно, хотя и не лишено права на жизнь.
В случае, если надо что-то переписать, есть несколько подходов:
1. Отнаследоваться от класса, который надо переписать и в нем дописать нужную логику.
2. Использовать цепочку алиасов.
И в том и в другом случае можно вывести всю необходимую информацию для дебага.
Для патчинга не использутся какие-либо методы, просто поверх включенных классов накладываются классы, которые смердживаются с базовыми и или переписывают методы или добавляют. Переписывать там, в общем-то, нечего.
На самом деле, это легко детектится через caller() метод, там в цепочке сразу бы вылезло, откуда уши растут.
Поэтому в моменте с затратными операциями я не соглашусь — не все так радужно в нашем королевстве, тупит руби сам по себе знатно.
Нет, в принципе, если использовать вместо AR, то может и проблема. Но это уже вопрос к разработчику — зачем использовать для CRUD задач NoSQL.
В остальном же, выпиливается AR в 4 строчки.
А что, греп отменили?
А если брать сегменты отдельно, то выходит, как правило, дороже.
Есть смысл так искать на лоукостерах, но их в этой системе нет.
вот этот например
Одним словом, все это как минимум странно, хотя и не лишено права на жизнь.