Писать вручную rest api на чем то вроде gin , а затем натягивать на него доку на не проверяемом птичьем мета-языке в комментариях для swag - это ужасный совет. Пж не делайте так никогда. Разрабатывайте rest api от спеки с использованием go-swagger и коллеги скажут вам спасибо.
а ещё у вас в коде (меня только гошный интересует) оч много антипатернов. Вы судя по всему забили на чистую архитектуру и некоторые 12 factor apps, логи в стдаут например. Поэтому выглядит гошная часть не очень
Всё что вы описали - слабо аргументировано вызывает много вопросов. Например, вы пишете Преимуществом собственного типа ошибки стала легкость, с которой мы могли писать тесты, зависящие от ошибок, а также писать чувствительный к ошибкам код вне тестов.
Но в Go ошибки обычно передаются через fmt.Errorf("%w .....") и наследование публичного объекта-ошибки. И как бы этого достаточно и для тестов зависящих от ошибок, и для собственно обработки ошибок, и для преобразовывания ошибки в HTTP-статус, и даже для расчёта сообщения для пользователя. В вашем примере можно было было бы просто обернуть ошибку и прокинуть на верх, либо вообще ни как её не обрабатывать. И затем на самом верху стека, в хендлере, сделать проверку if errors.Is(err, pgx.ErrNoRows) {
Поэтому Ваш собственный тип ошибки выглядит как не нужное усложнение. По крайней мере на таком уровне аргументации.
Далее, вы пишете про graylog и говорите что прикрепляете к ошибке стек трейс чтобы удовлетворить greylog-у. Но greylog вовсе не самое распространённо и далеко не самое лучшее решение, есть другие, и большинство из них вообще не предполагает наличия стек-трейса для сообщения в журнал. Для стектрейсов есть sentry, которая позволяет программисту вообще не иметь дело со стек трейсами и ничего про них не знать.
Писать вручную rest api на чем то вроде gin , а затем натягивать на него доку на не проверяемом птичьем мета-языке в комментариях для swag - это ужасный совет. Пж не делайте так никогда. Разрабатывайте rest api от спеки с использованием go-swagger и коллеги скажут вам спасибо.
а ещё у вас в коде (меня только гошный интересует) оч много антипатернов. Вы судя по всему забили на чистую архитектуру и некоторые 12 factor apps, логи в стдаут например. Поэтому выглядит гошная часть не очень
Всё что вы описали - слабо аргументировано вызывает много вопросов. Например, вы пишете
Преимуществом собственного типа ошибки стала легкость, с которой мы могли писать тесты, зависящие от ошибок, а также писать чувствительный к ошибкам код вне тестов.
Но в Go ошибки обычно передаются через fmt.Errorf("%w .....") и наследование публичного объекта-ошибки. И как бы этого достаточно и для тестов зависящих от ошибок, и для собственно обработки ошибок, и для преобразовывания ошибки в HTTP-статус, и даже для расчёта сообщения для пользователя. В вашем примере можно было было бы просто обернуть ошибку и прокинуть на верх, либо вообще ни как её не обрабатывать. И затем на самом верху стека, в хендлере, сделать проверку
if errors.Is(err, pgx.ErrNoRows) {Поэтому Ваш собственный тип ошибки выглядит как не нужное усложнение. По крайней мере на таком уровне аргументации.
Далее, вы пишете про graylog и говорите что прикрепляете к ошибке стек трейс чтобы удовлетворить greylog-у. Но greylog вовсе не самое распространённо и далеко не самое лучшее решение, есть другие, и большинство из них вообще не предполагает наличия стек-трейса для сообщения в журнал. Для стектрейсов есть sentry, которая позволяет программисту вообще не иметь дело со стек трейсами и ничего про них не знать.
Спасибо, полезный для меня материал. Так можно собственно любой erst-api сервис задеплоить, не только телеграм-бот