Спасибо всем организаторам и причастным! Очень приятно, было увидеть свою статью в списке победителей. Благодраю за столь высокую оценку моего творчества ❤️
Просто формулировка немного неточная получилась, под "существуют" я имел в виду это:
Так вот — планирование горутин происходит на уровне user space, то есть ими управляет планировщик Go (если точнее — Go Runtime), а планирование тредов на уровне kernel space, то есть ими управляет ОС.
Думаю, больше чем 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 у вас тут могут лежать контракты и для других сервисов.
Это я без наезда, если что :) Просто просьба с моей стороны, чтобы проще было ориентироваться в комментариях. Группировка внутри одной ветки помогла бы.
За поправки к статье я благодарен, в любом случае. У вас они, как правило, по делу, но я не всегда успеваю отвечать.
Было бы удобней, если бы вы писали все подобные комментарии в одной ветке, таким образом сгруппировав их. То есть, в ответе к какому-то из своих предыдущих комментариев.
Иначе среди ваших комментариев затеряются те, что от других людей :)
Спасибо всем организаторам и причастным! Очень приятно, было увидеть свою статью в списке победителей. Благодраю за столь высокую оценку моего творчества ❤️
Нет, они попадают в GRQ.
Спасибо за вопрос, это важный момент. Чуть позже добавлю уточнение и в статью.
Дяденька, а вы точно настоящий сварщик..?
Просто формулировка немного неточная получилась, под "существуют" я имел в виду это:
Так устроит?
Внимательно слушаю, что ещё?
Да, но не только оттуда. Как-нибудь руки доберутся, я причешу и скину весь список материалов, которые использовал.
Советую глянуть мой пост на эту тему, станет понятней что есть что. Судя по комментарию, вы сейчас в этом плаваете.
Может, эту статью 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 создать, поправим