Как стать автором
Обновить

Учимся разрабатывать REST API на Go на примере сокращателя ссылок

Уровень сложностиСредний
Время на прочтение30 мин
Количество просмотров50K
Всего голосов 48: ↑47 и ↓1+55
Комментарии40

Комментарии 40

Посмотрел ваше видео, жалко, что нет prometheus метрик и jaegertracing'а. Это довольно несложно делается, зато приносит много пользы.

Это точно будет в отдельном видео про мониторинг, на примере этого же сервиса. Я не хотел, чтобы эта статья / ролик распухали слишком сильно, и без того получилось очень объёмно.


Там также будет разобрана настройка Grafana и Loki, кстати. То есть и метрики, и логи, и алерты будут уходить туда.


Будет ли статья на эту тему, не уверен. Возможно, только видео.

Сейчас рекомендуют больше opentelemetry-go использовать для трэсинга.

Тут все очень по разному говорят. Я в таких случаях обычно опрос у себя в ТГ-канале провожу — что людям больше хочется увидеть в гайде, то и беру для примера.

Спасибо большое! Видео конечно хорошо, но для такого проекта текст лучше!

Все по разному усваивают гайды — кому-то лучше заходит текст, кому-то видео.


Если эта статья хорошо зайдёт, то буду стараться все новые ролики также публиковать в виде постов.

Мне конкретно это видео не зашло, потому что ты увеличивал картинку и при переходах вниз вверх я терялся не понимал куда ты "убежал", то ли в этом файле ты переместился то ли вообще ушел в другой файл

Ну и плюс в России сейчас стало очень печально с продуктами JetBrains, особенно под Linux

В каком смысле увеличивал? В какие-то конкретные моменты, или напротяжении всего видео было слишком крупно?

на протяжении всего видео

Понял. Окей, спасибо. Я такие замечания учитываю, потому что самому сложно понять, насколько это удобно.


Крупный шрифт тут для того, чтобы видео было удобно смотреть на разных устройствах, в том числе на маленьких экранах. Хуже всего, когда автор записывает на каком-нибудь 4к экране, а ты пытаешься смотреть это на 13-дюймовом ноуте или на планшете.


Но можно попробовать в следующий раз как-то плавнее перемещаться по коду и между файлами.

Ну и плюс в России сейчас стало очень печально с продуктами JetBrains, особенно под Linux

Хз, как на линукс, но на винде просто регается новый аккаунт раз в месяц на временную почту и берется триал на месяц (по крайней мере, c PhpStorm и GoLand работает)

На линуксе такая же история, но все время это делать лениво. Мне проще оказалось перейти на Visual Studio Code, благо он бесплатный и есть под линукс

Честно, внимательно прочитал не всё, остановился на константах 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...</зануда>

Да, есть такой момент, я в ролике об этом тоже говорил. Статью старался сделать не слишком огромной, поэтому некоторые моменты пришлось сократить.


Это один из многих важных моментов, которые, вроде бы, нельзя выкидывать. Но если всё это оставлять, то получится не статья, а книга ?

Тут ошибочка закралась

И туда же еще одна (Я не придираюсь а хочу помочь вылизать очень полезный гайд)

А тут не не понял, в чем ошибка? Вроде, всё ок.

В моем скрине все правильно, в статье отсутствует тег у HTTPServer

Понял, спасибо. Поправил тоже.

Еще такое замечание, в приведенном коде иногда отсутствуют импорты, и приходится лазить в гит что бы посмотреть какую именно библиотеку мы подключаем (например в файле sqlite.go и где то выше по тексту мне попадалось). Замечание не критичное, так шероховатость :)

Спасибо, поправил

Если кто то будет писать сей код под Windows то необходимо перед запуском программы во первых установить gcc под Windows (я сделал под tdm-gcc-64) и установить флаг gco_enabled в единичку следующей командой

go env -w CGO_ENABLED=

Иначе вы не сможете работать с sqlite

В save.go еще одна, как мне кажется ошибка, внутри render.JSON вызывается render.JSON

ps

кстати в гите конструкции с обработкой empty request я не вижу

pps

ниже похожая ошибка

Да, это ошибка, поправил. Недостающую обработку empty request тоже добавил.
Спасибо.

Всегда удивляло количество ошибок в гайдах, вы же по идее все это сами пишете, как минимум IDE должно ошибки подсвечивать и ничего не работать. То ли откровенный непроверенный копипаст то ли хз..

Я сначала пишу проект целиком, а потом уже пишу по нему статью. При таком подходе местами приходится воспроизводить некоторые старые куски кода по памяти (например, сначала написали одним способом, потом переписали иначе).


Статью я писал долго, и даже после написания опубликовал далеко не сразу. Параллельно я и проект дорабатывал, что-то улучшал, переделывал. Соответственно, в статье некоторые куски кода тоже надо было обновлять. А мой markdown-редактор, увы, не пытается компилировать куски кода и проверять их на наличие ошибок.


Кроме того, во время написания часто возникают новые мысли, хочется написать какие-то куски кода иначе, что-то забывается и множество других факторов.


Статья получилась очень большая, и лично я удивился бы скорее отсутствию ошибок в ней. Попробуйте написать что-то соразмерное, поймёте о чем я говорю.


Вообще, то о чем вы говорите элементарно проверяется. В статье есть ссылка на видео, в котором я пишу этот же код вживую и намного подробнее объясняю происходящее. Там видно, что всё прекрасно компилируется, запускается. Кроме того, загуглить и найти плагиат в наше время может даже ребёнок. Почему бы вам это не сделать, и не скинуть сразу пруфы и ссылки на оригинал?


Но, конечно, гораздо проще бросаться необоснованными обвинениями в плагиате и воровстве.

Не сдавайся, пиши еще! Видос тоже норм, про увеличение говорили. В целом гайд очень пригодился.

Спасибо, я как раз заканчиваю новую статью — аналогичную этой, но вместо REST API будет gRPC. Видео тоже будет.

Так надо было просто PR создать, поправим

Вот вроде вы закладываетесь под версионирование, но на структуре проекта это по сути никак не отображается. А потом после появления v2, v3 какой план действий по структурированию проекта?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий