Разные вещи же

поцоны, всё хотел спросить

чё вы делаете с ответами со сторонних апи?

сохраняете как-нибудь? не сохраняете? почему?

если сохраняете, то куда и как

Мы только логгируем в отдельный лог файл

я как то к определённому мнению по этому поводу не пришёл, но склоняюсь ближе к тому, что надо все ответы со сторонних апи сохранять

В формате запрос - ответ

вплоть до того чтобы создавать сущность дублирующую штуку со стороннего сервиса

и типа в ней json поле ответ

в принципе да, надо и запрос хранить, хорошая идея

в реляционной?

а связи указываете?

ну типа, user_id который делал запрос и т.д.

я как то к определённому мнению по этому поводу не пришёл, но склоняюсь ближе к тому, что надо все ответы со сторонних апи сохранять

Логи же есть

Можно логировать именно этот неймспейс с дебаг уровнем

Логи же есть

ну просто в хранении ответов профит я вижу не только в том чтобы отдебажить что-то

Логи, потом в эластик загнать для поиска

зависит от апи - от платежек храню жсон в БД

а ещё в том что сегодня нам надо только A, а завтра понадобится B

Не понял

и так можно будет для всех старых запросов его автоматически зафетчить

ну так данные протухнуть могут же

ну например, от сервиса приходит джейсончик { a: 'a', b: 'b' }

сегодня нам нужно только response[:a]

а завтра мы решаем что и response[:b]

Полностью сохраняйте в том виде, в котором приходит ответ

А не только часть

Смысл частями хранить?

ну так данные протухнуть могут же

могут, но так же как и уже сохранённые

Ну так в логе сервера у тебя будет запрос со всеми параметрами и ответ полный

И все

ну это парсить сложнее

Зачем логи задним числом править?

плюс матчить с юзерами

Не вижу проблем

ну я и не предлагаю править, а предлагаю более удобный способ их парсить

Авторизация по токену, сразу создается uid запоса, который везде в логе есть

И все

хорошо, а дальше просто файл парсить?

какие преимущества у этого перед созданием отдельной сущности?

условно, с полями json_b request, json_b response, user_id

и какие у этого могут быть подводные камни

Полнотекстовый поиск дико медленный

То что ты предлагаешь называется кибана

Работает на базе эластика, куда скармливаются текстовые логи

сохраняете как-нибудь? не сохраняете? почему?

логирую с трасировкой

логирую с трасировкой

трасировкой?

мб есть гем какой-нибудь для всего этого удобный?

хотя ответы от платежного гейта храним в бд и работаем с ними потом из пг

трасировкой?

я статью пишу про это сейчас

про логирование ответов со сторонних сервисов?

про трасировку

а про гем не знаешь?

может его имеет смысл запилить

так написать и все

это 2 строки

логгирование параметров, логирование ответов. нафига крутить гем на это?

+ фарадей умеет это из коробки как мидлеваре

ну я думал про таблицы + их привязку к классам условно SomethingRequest и SomethingResponse

ну типа пишешь в консоли `rails generate_third_party_loggable_entity something references:user Создаётся модель SomethingLog. Дальше создаёшь классы где-то внутри кода SomethingRequest и SomethingResponse`

ERROR: S client not available

чёто у меня разметка поехала

ты чето усложняешь себе жизнь

а, нет, модель SomethingResponseLog, далее делаешь так class SomethingResponse < LoggableResponse def initialize(request) @request = request # я предпочитаю такое делать в lazy моде end def to_h ... end

потом у инстанса something_response вызываешь метод log

ну я думал про таблицы + их привязку к классам условно SomethingRequest и SomethingResponse

так зачем это?

который в модель SomethingResponseLog запишет to_h у респонса и реквеста

так зачем это?

можно будет дёргать user.something_response_logs

и внутри их получать недостающие данные условно

при чём в класс модели, SomethingResponseLog, можно будет делегировать логику определения логов

типа def error? response['errors'] end

Тогда ошибки можно будет найти user.something_response_logs.select(&:error?)

лучше уж сразу в elasticsearch кидать или influxdb, чтобы можно было метрики доставать и удобно читать

для юзера

это наверное от требований больше зависит, если тебе нужны логи ради логов, то проще в файл писать, а если ты подразумеваешь дльнейшуюю работу с ними как с моделями, то имеет смысл сделать как ты говоришь

ок, хорошо

а с точки зрения этики/безопасности?

Широ?

Широ?

?

Хотел его поздравить

Такой вопрос - Hash#deep_merge штука хорошая , но тут я столкнулся с тем, что содержимое определенных рутовых ключей дип мержить не надо (надо просто мержить), а все остальные надо дип мержить. Может кто-то уже решал подобное?

Такой вопрос - Hash#deep_merge штука хорошая , но тут я столкнулся с тем, что содержимое определенных рутовых ключей дип мержить не надо (надо просто мержить), а все остальные надо дип мержить. Может кто-то уже решал подобное?

вообщем как то так: def deep_merge(original, second, exclude: []) original.merge(second.slice(*exclude)).deep_merge(second.except(*exclude)) end

вообщем как то так: def deep_merge(original, second, exclude: []) original.merge(second.slice(*exclude)).deep_merge(second.except(*exclude)) end

https://i.imgur.com/ejjcyW1.png

Хотел его поздравить

тут его вроде нет

потому что jwt не сверяется с базой

Храню вайт лист и если распапсился нормально - валидирую остальными полями из бд и ни в чем себе не отказываю

Реально не совсем понятно как жвт с отзывом и сроком жизни управлять на клиентах с постоянным хранением этого токена.

всем привет. подскажите пожалуйста, в чем может быть ошибка? когда запускаю файлы с расширением .feature в RubyMine, появляется ошибка Error running 'file.feature': Feature file 'C' doesnt exist

всем привет. подскажите пожалуйста, в чем может быть ошибка? когда запускаю файлы с расширением .feature в RubyMine, появляется ошибка Error running 'file.feature': Feature file 'C' doesnt exist

где появляется ошибка?

внизу в окошке лога?