Комментарии 40
Посмотрел ваше видео, жалко, что нет prometheus метрик и jaegertracing'а. Это довольно несложно делается, зато приносит много пользы.
Это точно будет в отдельном видео про мониторинг, на примере этого же сервиса. Я не хотел, чтобы эта статья / ролик распухали слишком сильно, и без того получилось очень объёмно.
Там также будет разобрана настройка Grafana и Loki, кстати. То есть и метрики, и логи, и алерты будут уходить туда.
Будет ли статья на эту тему, не уверен. Возможно, только видео.
Сейчас рекомендуют больше opentelemetry-go использовать для трэсинга.
Спасибо большое! Видео конечно хорошо, но для такого проекта текст лучше!
Все по разному усваивают гайды — кому-то лучше заходит текст, кому-то видео.
Если эта статья хорошо зайдёт, то буду стараться все новые ролики также публиковать в виде постов.
Мне конкретно это видео не зашло, потому что ты увеличивал картинку и при переходах вниз вверх я терялся не понимал куда ты "убежал", то ли в этом файле ты переместился то ли вообще ушел в другой файл
Ну и плюс в России сейчас стало очень печально с продуктами JetBrains, особенно под Linux
В каком смысле увеличивал? В какие-то конкретные моменты, или напротяжении всего видео было слишком крупно?
на протяжении всего видео
Понял. Окей, спасибо. Я такие замечания учитываю, потому что самому сложно понять, насколько это удобно.
Крупный шрифт тут для того, чтобы видео было удобно смотреть на разных устройствах, в том числе на маленьких экранах. Хуже всего, когда автор записывает на каком-нибудь 4к экране, а ты пытаешься смотреть это на 13-дюймовом ноуте или на планшете.
Но можно попробовать в следующий раз как-то плавнее перемещаться по коду и между файлами.
Ну и плюс в России сейчас стало очень печально с продуктами JetBrains, особенно под Linux
Хз, как на линукс, но на винде просто регается новый аккаунт раз в месяц на временную почту и берется триал на месяц (по крайней мере, c PhpStorm и GoLand работает)
Честно, внимательно прочитал не всё, остановился на константах env, local, prod... Это не вписывается в методологию разработки облачных приложений и я бы не рекомендовал так делать. Вместо if env prod, лучше поставить конфигурацию из env переменных или config файла, это позволит запускать сервис на любых окружениях с любой конфигурацией. Это может быть полезно, например при разворачивании окружения для нагрузочного тестирования или интеграционного. https://12factor.net/config
Опять же с моей скромной точки зрения, разработку сервиса стоит начинать с паттерна graceful shutdown
Очень зря вы не читали внимательно, потому что именно так у меня и сделано — конфиуграцию я беру из конфиг файла, и объясняю как брать из переменных окружения (тут уже на выбор читателя). В названных вами константах хранятся лишь значения, с которыми мы сравниваем то, что получили из конфига.
А место, в котором я проверяю текущее окружение (if env prod) — это просто сборка логгера, который немного отличается в разных окружениях. Тип текущего окружения берётся всё из того же конфига.
graceful shutdown — тут да, стоило его упомянуть. Но не беда, расскажу в следующем посте / ролике.
Я как раз и говорю о том, что группировать настройки по типам окружения в коде плохая затея. Потому что количество окружений может расти независимо от разработчика, например latest, release, qa, stress-test, dima-local, slava-docker-qa... Передавайте настойки логгера так же через env, а файл config.yaml, можно использовать как default values, если настроек очень много. В оркестраторах типа k8s, обычно default values, опрсаывется в helm chart.
Окей, теперь понял, что вы имели ввиду. Да, это имеет смысл, и в рабочих проектах я именно так и делаю.
В этом проекте решил немного упростить, т.к. это пет-проект — тут и три окружения то вряд ли наберется, скорее только локал и прод. Но, возможно, даже в этом случае стоило явно передавать параметры логгера, для прозрачности.
Чего ещё не хватает для Graceful Shutdown? Все функции sql-lite имеют двойников с контекстом, например: .Exec вызывает .ExecContext с базовым context.Background(). У меня не хватило ума реализовать nested-контекст для стораджа и для веб-сервера. Как оно сейчас работает: создаю контекст с таймаутом, затем ожидаю srv.Shutdown(ctx) и отменяю контекст в defer cancel() либо подаю по таймауту сигнал <-ctx.Done() для прерывания Shutdown. Правильно? Пока не смог чётко сформулировать, для чего мне nested-контекст. А правильная постановка вопроса - половина решения.
<зануда>Если сгенерированный alias совпадет с существующим, пользователь получит неправильный и негативный пользовательский опыт - он ничего плохого не делал, а ошибочка вышла. Но тут дилемма - проверять наличие до бесконечности или как-то реализовывать гарантию уникальности нового alias'а, при этом, конечно, не потеряв его случайность. Да и транзакции явно не хватает (даже без SELECT) - random-то у нас pseudo хоть и nano, два одновременных запроса могут и... Да и alias не плохо было бы sanitise...</зануда>
Тут ошибочка закралась
Если кто то будет писать сей код под Windows то необходимо перед запуском программы во первых установить gcc под Windows (я сделал под tdm-gcc-64) и установить флаг gco_enabled в единичку следующей командой
go env -w CGO_ENABLED=
Иначе вы не сможете работать с sqlite
В save.go еще одна, как мне кажется ошибка, внутри render.JSON вызывается render.JSON
ps
кстати в гите конструкции с обработкой empty request я не вижу
pps
ниже похожая ошибка
Всегда удивляло количество ошибок в гайдах, вы же по идее все это сами пишете, как минимум IDE должно ошибки подсвечивать и ничего не работать. То ли откровенный непроверенный копипаст то ли хз..
Я сначала пишу проект целиком, а потом уже пишу по нему статью. При таком подходе местами приходится воспроизводить некоторые старые куски кода по памяти (например, сначала написали одним способом, потом переписали иначе).
Статью я писал долго, и даже после написания опубликовал далеко не сразу. Параллельно я и проект дорабатывал, что-то улучшал, переделывал. Соответственно, в статье некоторые куски кода тоже надо было обновлять. А мой markdown-редактор, увы, не пытается компилировать куски кода и проверять их на наличие ошибок.
Кроме того, во время написания часто возникают новые мысли, хочется написать какие-то куски кода иначе, что-то забывается и множество других факторов.
Статья получилась очень большая, и лично я удивился бы скорее отсутствию ошибок в ней. Попробуйте написать что-то соразмерное, поймёте о чем я говорю.
Вообще, то о чем вы говорите элементарно проверяется. В статье есть ссылка на видео, в котором я пишу этот же код вживую и намного подробнее объясняю происходящее. Там видно, что всё прекрасно компилируется, запускается. Кроме того, загуглить и найти плагиат в наше время может даже ребёнок. Почему бы вам это не сделать, и не скинуть сразу пруфы и ссылки на оригинал?
Но, конечно, гораздо проще бросаться необоснованными обвинениями в плагиате и воровстве.
Не сдавайся, пиши еще! Видос тоже норм, про увеличение говорили. В целом гайд очень пригодился.
Исходники исправлений: https://github.com/comerc/url-shortener
Вот вроде вы закладываетесь под версионирование, но на структуре проекта это по сути никак не отображается. А потом после появления v2, v3 какой план действий по структурированию проекта?
Учимся разрабатывать REST API на Go на примере сокращателя ссылок