Думаю, больше чем 2 минуты, с учетом того что автоматический деплой придётся чуток усложнить. Плюс поддержка в долгосрочной переспективе. Плюс дампы и бэкапы..
Но не суть - даже если для этого достаточно бороду почесать, в чем профит то?
Мой опыт научил меня избавляться от любых излишних сложностей. Нам нужна база - какая? Postgres? Окей. А можем проще? Например, sqlite. Супер, берём её. А можем вообще от БД отказаться? Идеально! :D
Сложность проекта часто складывается не только из очень сложных компонентов и решений, но и из множества таких вот мелочей.
А что нам даст наличие postgres вместо sqlite? Да, postgres поставить и использовать не супер сложно, но, всё же, её надо будет:
Завести: описать в docker-compose, в конфиге приложения, в целом правильно сконфигурировать
Запустить: обязательно придется иметь докер на удалённой машине
Поддерживать и мониторить: если упадёт, то приложение сломается
Отдавать чуть больше ресурсов: повышаются минимальные требования к серверу
Сложнее делать дампы и бэкапы: в случае sqlite достаточно просто скопировать один файл
Это навскидку, список можно продолжить. Проблемы не критичные, конечно, но какой профит наличие postgres даёт взамен? При условии, что у нас пет-проект.
Я бы сказал даже так, sqlite это не компромисс в стиле "для пет-проекта сойдёт", это наиболее предпочтительный вариант. Не нужно усложнять себе жизнь раньше времене. При необходимости вы всегда сможете переехать на любую другую СУБД - наш код позволяет это сделать без проблем, достаточно лишь написать новую реализацию Storage.
Ошибки могут возникнуть и при работе с переменными окружения - они могут окзаться пустыми и не валидными. Это частично решает проблему, конечно, но на мой взгляд, эти усилия того не стоят.
Ошибки инициализации конфига в логах нам и не нужны, т.к. наше приложение без конфига вообще не запустится, а такое поведение тоже нужно уметь мониторить.
По поводу первого варианта - я тоже думаю, что проблема на стороне task. Но если сделать вот так, то будет работать и через него:
protoc -I proto proto/**/*.proto --go_out=./gen/go/ --go_opt=paths=source_relative --go-grpc_out=./gen/go/ --go-grpc_opt=paths=source_relative
Тут я убрал sso из пути, указал общий путь до protos. Такой вариант и в целом правильней, т.к. помимо sso у вас тут могут лежать контракты и для других сервисов.
Это я без наезда, если что :) Просто просьба с моей стороны, чтобы проще было ориентироваться в комментариях. Группировка внутри одной ветки помогла бы.
За поправки к статье я благодарен, в любом случае. У вас они, как правило, по делу, но я не всегда успеваю отвечать.
Было бы удобней, если бы вы писали все подобные комментарии в одной ветке, таким образом сгруппировав их. То есть, в ответе к какому-то из своих предыдущих комментариев.
Иначе среди ваших комментариев затеряются те, что от других людей :)
Возможно, makefile гибче, но мне больше нравится формат и синтаксис taskfile, и я пока не упирался ни разу в предел его возможностей
Миграции у меня не в internal, а в корне лежат. Похоже, вы ошиблись. Ну или у меня где-то опечатка (где?)
Мне slog очень понравился, и в него можно обернуть и тот же zap при желании. В видео я объяснял - slog хорош тем, что он универсален. Если использовать zap, то будет очень сложно в будущем переехать на что-то другое.
Я сначала пишу проект целиком, а потом уже пишу по нему статью. При таком подходе местами приходится воспроизводить некоторые старые куски кода по памяти (например, сначала написали одним способом, потом переписали иначе).
Статью я писал долго, и даже после написания опубликовал далеко не сразу. Параллельно я и проект дорабатывал, что-то улучшал, переделывал. Соответственно, в статье некоторые куски кода тоже надо было обновлять. А мой markdown-редактор, увы, не пытается компилировать куски кода и проверять их на наличие ошибок.
Кроме того, во время написания часто возникают новые мысли, хочется написать какие-то куски кода иначе, что-то забывается и множество других факторов.
Статья получилась очень большая, и лично я удивился бы скорее отсутствию ошибок в ней. Попробуйте написать что-то соразмерное, поймёте о чем я говорю.
Вообще, то о чем вы говорите элементарно проверяется. В статье есть ссылка на видео, в котором я пишу этот же код вживую и намного подробнее объясняю происходящее. Там видно, что всё прекрасно компилируется, запускается. Кроме того, загуглить и найти плагиат в наше время может даже ребёнок. Почему бы вам это не сделать, и не скинуть сразу пруфы и ссылки на оригинал?
Но, конечно, гораздо проще бросаться необоснованными обвинениями в плагиате и воровстве.
Может, эту статью ChatGPT написал?)
Думаю, больше чем 2 минуты, с учетом того что автоматический деплой придётся чуток усложнить. Плюс поддержка в долгосрочной переспективе. Плюс дампы и бэкапы..
Но не суть - даже если для этого достаточно бороду почесать, в чем профит то?
Мой опыт научил меня избавляться от любых излишних сложностей. Нам нужна база - какая? Postgres? Окей. А можем проще? Например, sqlite. Супер, берём её. А можем вообще от БД отказаться? Идеально! :D
Сложность проекта часто складывается не только из очень сложных компонентов и решений, но и из множества таких вот мелочей.
А что нам даст наличие postgres вместо sqlite? Да, postgres поставить и использовать не супер сложно, но, всё же, её надо будет:
Завести: описать в docker-compose, в конфиге приложения, в целом правильно сконфигурировать
Запустить: обязательно придется иметь докер на удалённой машине
Поддерживать и мониторить: если упадёт, то приложение сломается
Отдавать чуть больше ресурсов: повышаются минимальные требования к серверу
Сложнее делать дампы и бэкапы: в случае sqlite достаточно просто скопировать один файл
Это навскидку, список можно продолжить. Проблемы не критичные, конечно, но какой профит наличие postgres даёт взамен? При условии, что у нас пет-проект.
Я бы сказал даже так, sqlite это не компромисс в стиле "для пет-проекта сойдёт", это наиболее предпочтительный вариант. Не нужно усложнять себе жизнь раньше времене. При необходимости вы всегда сможете переехать на любую другую СУБД - наш код позволяет это сделать без проблем, достаточно лишь написать новую реализацию Storage.
Ни разу не встречался с подобными комментариями в рабочих проектах, и проблемой это не становилось. Обычно IDE с этим справляется неплохо.
Если и добавлять такое в игнор, то я бы посоветовал
.git/info/exclude, тогда не придется коммитить это вместе с.gitignoreИначе каждый разработчик проекта будет коммитить в gitignore свои личные локальные файлы.
Ошибки могут возникнуть и при работе с переменными окружения - они могут окзаться пустыми и не валидными. Это частично решает проблему, конечно, но на мой взгляд, эти усилия того не стоят.
Ошибки инициализации конфига в логах нам и не нужны, т.к. наше приложение без конфига вообще не запустится, а такое поведение тоже нужно уметь мониторить.
По поводу первого варианта - я тоже думаю, что проблема на стороне task. Но если сделать вот так, то будет работать и через него:
Тут я убрал
ssoиз пути, указал общий путь до protos. Такой вариант и в целом правильней, т.к. помимо sso у вас тут могут лежать контракты и для других сервисов.Это я без наезда, если что :) Просто просьба с моей стороны, чтобы проще было ориентироваться в комментариях. Группировка внутри одной ветки помогла бы.
За поправки к статье я благодарен, в любом случае. У вас они, как правило, по делу, но я не всегда успеваю отвечать.
Интерфейс Auth - это интерфейс для сервисного слоя, не для gRPC-сервера. То есть, это уже бизнес-логика, а не хэндлеры.
Ну так это в исходниках) Где-то недоглядел, да. Копипастил из предыдущего проекта.
Но в статье такого нет.
Было бы удобней, если бы вы писали все подобные комментарии в одной ветке, таким образом сгруппировав их. То есть, в ответе к какому-то из своих предыдущих комментариев.
Иначе среди ваших комментариев затеряются те, что от других людей :)
Так у меня и используется "log/slog"
golang.org/x/exp/slogя использовал в прошлой статье, тогда еще не было 1.21Спасибо, добавил в статью
Так надо было просто PR создать, поправим
Спасибо, рад что понравилось :)
Возможно, makefile гибче, но мне больше нравится формат и синтаксис taskfile, и я пока не упирался ни разу в предел его возможностей
Миграции у меня не в internal, а в корне лежат. Похоже, вы ошиблись. Ну или у меня где-то опечатка (где?)
Мне slog очень понравился, и в него можно обернуть и тот же zap при желании. В видео я объяснял - slog хорош тем, что он универсален. Если использовать zap, то будет очень сложно в будущем переехать на что-то другое.
Спасибо, я как раз заканчиваю новую статью — аналогичную этой, но вместо REST API будет gRPC. Видео тоже будет.
Я сначала пишу проект целиком, а потом уже пишу по нему статью. При таком подходе местами приходится воспроизводить некоторые старые куски кода по памяти (например, сначала написали одним способом, потом переписали иначе).
Статью я писал долго, и даже после написания опубликовал далеко не сразу. Параллельно я и проект дорабатывал, что-то улучшал, переделывал. Соответственно, в статье некоторые куски кода тоже надо было обновлять. А мой markdown-редактор, увы, не пытается компилировать куски кода и проверять их на наличие ошибок.
Кроме того, во время написания часто возникают новые мысли, хочется написать какие-то куски кода иначе, что-то забывается и множество других факторов.
Статья получилась очень большая, и лично я удивился бы скорее отсутствию ошибок в ней. Попробуйте написать что-то соразмерное, поймёте о чем я говорю.
Вообще, то о чем вы говорите элементарно проверяется. В статье есть ссылка на видео, в котором я пишу этот же код вживую и намного подробнее объясняю происходящее. Там видно, что всё прекрасно компилируется, запускается. Кроме того, загуглить и найти плагиат в наше время может даже ребёнок. Почему бы вам это не сделать, и не скинуть сразу пруфы и ссылки на оригинал?
Но, конечно, гораздо проще бросаться необоснованными обвинениями в плагиате и воровстве.
Да, это ошибка, поправил. Недостающую обработку empty request тоже добавил.
Спасибо.
Понял, спасибо. Поправил тоже.
Да, есть такой момент, я в ролике об этом тоже говорил. Статью старался сделать не слишком огромной, поэтому некоторые моменты пришлось сократить.
Это один из многих важных моментов, которые, вроде бы, нельзя выкидывать. Но если всё это оставлять, то получится не статья, а книга ?