K
На самом деле
F[-_, +_, +_] это сложна, пока ни разу не пригодилсяSize: a a a
2020 May 21
K
IP
ну очевидно ,что 1-я
Просто тогда если следовать паттернам зио, то у сервиса будут поля с типами вида Blocking.Service. Это типо норм?
Oℕ
Просто тогда если следовать паттернам зио, то у сервиса будут поля с типами вида Blocking.Service. Это типо норм?
да
Oℕ
иначе ваша сигнатура раскрывает информацию, что в реализации будет использоваться блокирование
Oℕ
и вы обязаны будете предоставить блокирующий контекст даже чистым реализациям
Oℕ
всё лучше, чем cats.effect.Blocker, это просто ахтунг (это не относится к обсуждению, если что)
Oℕ
Я вообще не понимаю пилквиста, как можно написать конструкцию вроде Blocker, а потом этими же руками в твитер писать политику
IP
иначе ваша сигнатура раскрывает информацию, что в реализации будет использоваться блокирование
Ну да по сути в doobie также - внутри транзактора сидит блокинг контекст и в итоге апи для получения данных со стороны выглядит как не использующее блокировку
Oℕ
Ну да по сути в doobie также - внутри транзактора сидит блокинг контекст и в итоге апи для получения данных со стороны выглядит как не использующее блокировку
Ну и это довольно важно, потому что зачастую тот блокирующй контекст, что вы хотите скормить дуби - это совсем не тот же блокирующий контекст, что вы потом в приложении будете использовать.
Поэтому вы можете для ждбц что-то специализированное выделить на этапе компоновки лэйера, чтобы потом не беспокоиться об этом во время каждого вызова
Поэтому вы можете для ждбц что-то специализированное выделить на этапе компоновки лэйера, чтобы потом не беспокоиться об этом во время каждого вызова
IP
Ну и это довольно важно, потому что зачастую тот блокирующй контекст, что вы хотите скормить дуби - это совсем не тот же блокирующий контекст, что вы потом в приложении будете использовать.
Поэтому вы можете для ждбц что-то специализированное выделить на этапе компоновки лэйера, чтобы потом не беспокоиться об этом во время каждого вызова
Поэтому вы можете для ждбц что-то специализированное выделить на этапе компоновки лэйера, чтобы потом не беспокоиться об этом во время каждого вызова
Да это хорошее замечание, согласен. но относительно контекста блокирующего: я думал что по жизни блокирующего контекста одного на приложение - вполне, поэтому меня напрягали примеры где идет интероп дуби и зио и там новый контекст блокирующий создают под это дело.
Oℕ
Да это хорошее замечание, согласен. но относительно контекста блокирующего: я думал что по жизни блокирующего контекста одного на приложение - вполне, поэтому меня напрягали примеры где идет интероп дуби и зио и там новый контекст блокирующий создают под это дело.
нет, для нормального прода у ждбц должен быть свой отдельный блокирующий контекст
Oℕ
к несчастью
Oℕ
со всеми параметрами вынесенными в конфиг, который можно при деплойменте поменять
IP
Т. Е отдельный для ждбц, отдельный для фс. Я думал что они там все анбаунд и тип без ограничения общности два анбаундных эквивалентны одному андбаундному
IP
Просто наверное мой прокол в том что для ждбц он не анбаундный?
Oℕ
Просто наверное мой прокол в том что для ждбц он не анбаундный?
да
XX
т.е. в качестве R в таких операциях предполагается использовать не Has, который смешается с основным, а просто какое-то данные на одноразовый provide?
А если использовать без Has, просто какие-то данные? Ну вот примерно так же как tofu.Env. Вполне же нормально тогда в R ложатся всякие contextId, correlationId и т.п.?
Oℕ
X X
А если использовать без Has, просто какие-то данные? Ну вот примерно так же как tofu.Env. Вполне же нормально тогда в R ложатся всякие contextId, correlationId и т.п.?
Вот их логично в Has