Да собсна там не было чего-то такого. После логина создание юзера с правами, потом юзер с токеном (если не путаю) уже для записи. А wal-g на хабре хорошо описан. Были проблемы только с тем чтобы переписать крон на system timers по статье из хабра, не сразу заработало.
Использую wal-g и mini-io. Целостность бекапов можно проверить разворачивая бекапы в копию базы в докере и sql запросом на какие то данные. Если true все ок( либо на тестовый стенд.)
То есть они готовы принять ~10-15 миллионов писем по количеству пользователей? И ручками все проверять?
Допустим они получат 1млн писем и на каждое потратят по минуте - это займет почти два года просто в рабочих часах. Что это за херня? В чем проблема сделать срез и тем у кого меньше 200тр дать спокойно вывести на банки РФ?
документация всегда нужна)) Просто с какого-то момента приходит мысль, что http статусы не имеют преимуществ и становятся какой-то самоцелью, и удобнее разруливать транспорт отдельно от продукта. Ну, я согласен, все от случая к случаю.
Если сервер не может отработать запрос по причине какой то продуктовой логики, следует ли отвечать с http 5xx кодом (и на клиенте ловить ошибки в try catch) или изначально оставить http коды только для транспортных ошибок, а проблемы с логикой оборачивать в свою логику при которой все ответы будут обернуты дополнительным полем со статусом типа {"status":"ok", "response": data}?
Дальний ИК создают уже сами предметы, ближний - отражают.
Да собсна там не было чего-то такого. После логина создание юзера с правами, потом юзер с токеном (если не путаю) уже для записи. А wal-g на хабре хорошо описан. Были проблемы только с тем чтобы переписать крон на system timers по статье из хабра, не сразу заработало.
handler?))
На хабре по ней отличный обзор
Ту лекцию, что я слушал, было сказано обязательно
Видел в каком то мастер-классе по pg опцию, которая заставляет pg использовать контрольные суммы при записи строк для валидации целостности
Использую wal-g и mini-io. Целостность бекапов можно проверить разворачивая бекапы в копию базы в докере и sql запросом на какие то данные. Если true все ок( либо на тестовый стенд.)
.
это swagger, а я про фронт. UI, компоненты, формы, валидация. Интересует связка удобная валидации форм, когда правила из бека легко интегрируются в UI
Фронт есть какой удобный в связке?
в любой непонятной ситуации собирай персональные данные
То есть они готовы принять ~10-15 миллионов писем по количеству пользователей? И ручками все проверять?
Допустим они получат 1млн писем и на каждое потратят по минуте - это займет почти два года просто в рабочих часах. Что это за херня?
В чем проблема сделать срез и тем у кого меньше 200тр дать спокойно вывести на банки РФ?
.
Утекшая база гемотест, например
легаси
документация всегда нужна)) Просто с какого-то момента приходит мысль, что http статусы не имеют преимуществ и становятся какой-то самоцелью, и удобнее разруливать транспорт отдельно от продукта. Ну, я согласен, все от случая к случаю.
Тогда мебельная пленка под дерево с али
Софт тач на диктофоне современного zoom h1 через несколько лет становится липкой смолой
Если сервер не может отработать запрос по причине какой то продуктовой логики, следует ли отвечать с http 5xx кодом (и на клиенте ловить ошибки в try catch) или изначально оставить http коды только для транспортных ошибок, а проблемы с логикой оборачивать в свою логику при которой все ответы будут обернуты дополнительным полем со статусом типа {"status":"ok", "response": data}?
{"status":"error", "description": "баланс тютю"}?
Чувствуется обида, значит статья подсветила что-то важное