Чтоб не забывать запускать кодоген, часто достаточно не хранить сгенерированные файлы под гитом, и писать тесты ;) В общем и целом, выбрали бы вы дорожку с генерацией кода - ваш покорный (и, уверен, много кто еще) прониклись и глубже бы стали смотреть ваш проект. И сравнивать его с sqlc, разумеется :D
Но магия ключей мап, и оверхед на запуск как минимум для меня выглядят как редфлаги, заставляющие пройти мимо :(
Вы наверняка рассматривали вероятность использования кодогена, чтоб не зависеть от магических ключей мапы и не иметь оверхеда на запуск, когда надо добро все прочитать да распарсить. Почему вместо генерации обертки над sql в виде как раз go кода отказались? Ведь такой подход выглядел бы логичнее, строже, и гибче?
В дополнение, крайние несколько лет являюсь адептом секты "config-less", когда все что нужно сконфигурировать - должно иметь cli/env ручки для этого, и знаете - этот подход более чем жизнеспособен! И строгие правила, и валидация, и генерация документации из этого кода - прям хорошо. Да что уж говорить - великий и могучий Traefik и тот умеет себя конфигурировать флагами без сильной боли ниже поясницы (если понимаешь что делаешь), а он тот еще комбаин.
Ну и раз уж мы здесь, то крохотный совет - лучше не использовать hub.docker.com как единственное место, где живет образ. ghcr.io + quay.io (в дополнение в hub-у) есть наше все, да и крайнее падение hub-а показало кто делает мирроринг, а кто нет ;)
ctrl+f "max" ничего не показал, у вас именно separate repository а не форк (но в ридми есть ссылка, правда), да и структура репозитория не мэтчится с оригинальным даже визуально, отсюда и поспешный вывод :)
Как-то мне приходилось собирать проект на ноде, который в зависимоятях тянул пакет что использует python, который через свое подобие FFI запускал функции из rust. А потом его надо было собрать под arm или какая-то из зависимостей обновилась, но не ее зависимость.. Ад был тот еще. Да и не только с нодовыми проектами в такое влетал.
Позиция заключается в том, что "если ты можешь - это не значит что ты должен" + Hell is paved with good intentions. Если ты хочешь делать что-то подобное то, скорее всего, твоя дорога сворачивает не туда. Да, ваш проект крохотный, но импакт и пример другим заставит их думать "ну норм же, вон, другие так делают".
Очень много инструментов использует подобный подход
Скорее всего тех, где просто нет возможности иначе. Вот нет её. Вот совсем. Ну невозможно иначе. Никак, ваапще. Если есть хоть малейшая возможность не раздувать зависимости - не надо делать этого. Пардон, но вы имеете желание ради парсинга строк и сисколов создания директорий/записи файлов, в которые нода умеет прекрасно - тянуть целиком компилятор другого языка с исходниками собственной тулы, да компилить на целевой тачке во время установки зависимостей. Неужели этого не смущает по умолчанию? ;)
Занятно! Вот только ничего что ваш npm пакет весит ~200Mb (из-за того что все возможные комбинации бинарей в нем), да и как-то органичнее было бы для npm сделать свой велосипед проект на node, чтоб "одна среда, один язык" да без внешних зависимостей.. Как мне кажется, как иследдовательская работа - прикольно! Как тула чтоб кому-то посоветовать - врятли.
.dockerignore must-have, и, более того, примерно такого вида:
## Ignore everything
*
## Except the following files and directories
!/cmd
!/internal
!/go.*
Таким образом в контексте демона будет только то что надо, он не будет "пухнуть", и кэширование слоев (а демон инвалидирует кэш слоев если контект был изменен) вернется в чат.
podman вместо docker есть бро, с его киллер-фичей --cache-from и --cache-to. Просто почитайте за него, он вам наверняка понравится.
Не покидает ощущение попытки сделать из того, что вполне себе может оставаться простым - сложным, "по книжкам, как деды завещали". Возможно, ощущение ошибочное, но если перед всеми другими призмами смотреть на код через призму KIS(s) - он заиграет совсем другими красками (но это не точно)
Однако при работе с Redis важно не забывать про ещё одно его отличительное свойство: он однопоточный
Разрешите спросить - а играли ли в keydb или иные имплементации "redis-протокола"? Если нет - то почему, если в вашем случае redis является явным bottleneck-ом?
Мне вот всегда было интересно, чем же руководствуются те, что генерируют спецификацию из кода? Ведь спецификация есть нечто иное, как контракт для взаимодействия между системами, т.е. она должна являться источником истины, а не наоборот.
В реальном мире это можно представить как взаимоотношение, например, клиента и банка. Условия, на которых банк оказываем услуги (не обнуляет ваши счета, начисляет проценты по вкладам и так далее) зависели бы от того, как банк фактически обходится с вашими средствами, а не от того, на каких условиях вы заключили с ним контракт (договор, условия обслуживая и т.п.).
Борис, вы безусловно большой молодец, что разобрались со своим кейсом и поделились опытом! Но мне вот просто интересно - почему бы не описать спецификацию в yaml/json формате, и из неё уже сгенерировать код под Echo сервер используя, например, deepmap/oapi-codegen? Вносить изменения будет так же просто - изменили спеку (контракт), сгенерировали соответствующий код, поправили имплементацию. Но правило источника истины в этом случае сохраняется, и бережёт вас же от обратно-несовместимых изменений, и значительно упрощает ревью. Да и кода будет меньше, и поддерживать 3rd party решение вам не придётся.
Для однотипных проектов давно придуман boilerplate, но придумать проблему и мужественно ее решить - тоже отдельный вид искусства, согласен (извиняюсь за токсичность)
Чтоб не забывать запускать кодоген, часто достаточно не хранить сгенерированные файлы под гитом, и писать тесты ;)
В общем и целом, выбрали бы вы дорожку с генерацией кода - ваш покорный (и, уверен, много кто еще) прониклись и глубже бы стали смотреть ваш проект. И сравнивать его с sqlc, разумеется :D
Но магия ключей мап, и оверхед на запуск как минимум для меня выглядят как редфлаги, заставляющие пройти мимо :(
Удачи с проектом, не бойтесь экспериментировать!
Вы наверняка рассматривали вероятность использования кодогена, чтоб не зависеть от магических ключей мапы и не иметь оверхеда на запуск, когда надо добро все прочитать да распарсить. Почему вместо генерации обертки над sql в виде как раз go кода отказались? Ведь такой подход выглядел бы логичнее, строже, и гибче?
Нет CI
Нет тестов
Комментарии в коде на русском языке
Раздувает зависимости (мне не нужна монго в моем проекте, но заюзав ваш пакет - клиент для монги все равно будет тянуться), идеал - 0 зависимостей
Когда напишите тесты, увидите где у вас гонки (даже в stderr/stdout нельзя писать без синхронизации)
Удачи с проектом!
В дополнение, крайние несколько лет являюсь адептом секты "config-less", когда все что нужно сконфигурировать - должно иметь cli/env ручки для этого, и знаете - этот подход более чем жизнеспособен! И строгие правила, и валидация, и генерация документации из этого кода - прям хорошо. Да что уж говорить - великий и могучий Traefik и тот умеет себя конфигурировать флагами без сильной боли ниже поясницы (если понимаешь что делаешь), а он тот еще комбаин.
Ну и раз уж мы здесь, то крохотный совет - лучше не использовать hub.docker.com как единственное место, где живет образ. ghcr.io + quay.io (в дополнение в hub-у) есть наше все, да и крайнее падение hub-а показало кто делает мирроринг, а кто нет ;)
ctrl+f "max" ничего не показал, у вас именно separate repository а не форк (но в ридми есть ссылка, правда), да и структура репозитория не мэтчится с оригинальным даже визуально, отсюда и поспешный вывод :)
Просто оставлю это здесь - https://github.com/crazy-max/swarm-cronjob
Как-то мне приходилось собирать проект на ноде, который в зависимоятях тянул пакет что использует python, который через свое подобие FFI запускал функции из rust. А потом его надо было собрать под arm или какая-то из зависимостей обновилась, но не ее зависимость.. Ад был тот еще. Да и не только с нодовыми проектами в такое влетал.
Позиция заключается в том, что "если ты можешь - это не значит что ты должен" + Hell is paved with good intentions. Если ты хочешь делать что-то подобное то, скорее всего, твоя дорога сворачивает не туда. Да, ваш проект крохотный, но импакт и пример другим заставит их думать "ну норм же, вон, другие так делают".
Скорее всего тех, где просто нет возможности иначе. Вот нет её. Вот совсем. Ну невозможно иначе. Никак, ваапще. Если есть хоть малейшая возможность не раздувать зависимости - не надо делать этого. Пардон, но вы имеете желание ради парсинга строк и сисколов создания директорий/записи файлов, в которые нода умеет прекрасно - тянуть целиком компилятор другого языка с исходниками собственной тулы, да компилить на целевой тачке во время установки зависимостей. Неужели этого не смущает по умолчанию? ;)
Пожалуйста, не надо так делать :( Хотя, npm-экосистему уже врятли что-то спасет..
Занятно! Вот только ничего что ваш npm пакет весит ~200Mb (из-за того что все возможные комбинации бинарей в нем), да и как-то органичнее было бы для npm сделать свой
велосипедпроект на node, чтоб "одна среда, один язык" да без внешних зависимостей.. Как мне кажется, как иследдовательская работа - прикольно! Как тула чтоб кому-то посоветовать - врятли.Разрешите добавить свои 50 центов:
.dockerignoremust-have, и, более того, примерно такого вида:podmanвместоdockerесть бро, с его киллер-фичей--cache-fromи--cache-to. Просто почитайте за него, он вам наверняка понравится.Не покидает ощущение попытки сделать из того, что вполне себе может оставаться простым - сложным, "по книжкам, как деды завещали". Возможно, ощущение ошибочное, но если перед всеми другими призмами смотреть на код через призму KIS(s) - он заиграет совсем другими красками (но это не точно)
Прошу не считать этот коментарий слишком токсичным (а он будет токсичным), но:
Каждый разработчик должен написать свой фреймворк, ровно как и то, что он должен его никому не показывать
Документации считаем что нет
Ровно как и юнит тестов
Контекста (
context.Context) тоже нет - только по этому критерию сразу мимо кассыАвтоматические миграции имеют свою цену, и платить ее придется (по закону Мерфи) вот ровно тогда, когда на это совсем не будет бюджета
Constrains, returning, etc...
Вы проделали классную исследовательскую работу, но собирать фидбэк таким образом - стоит ли?
Просто оставлю это здесь - renovatebot для gitlab, и dependabot для github
а можно подробнее - на сколько медленее? на конкурентную или эксклюзивную запись? или чтение? тут же столько граней у этого вопроса :)
мастер+слейвы !== многопоточный доступ к данным, проблема то все равно остается, хоть и в менее концентрированном виде, на мой скромный взгляд...
Разрешите спросить - а играли ли в keydb или иные имплементации "redis-протокола"? Если нет - то почему, если в вашем случае redis является явным bottleneck-ом?
А это не зона ли ответственности E2E тестов, разве?
Мне вот всегда было интересно, чем же руководствуются те, что генерируют спецификацию из кода? Ведь спецификация есть нечто иное, как контракт для взаимодействия между системами, т.е. она должна являться источником истины, а не наоборот.
В реальном мире это можно представить как взаимоотношение, например, клиента и банка. Условия, на которых банк оказываем услуги (не обнуляет ваши счета, начисляет проценты по вкладам и так далее) зависели бы от того, как банк фактически обходится с вашими средствами, а не от того, на каких условиях вы заключили с ним контракт (договор, условия обслуживая и т.п.).
Борис, вы безусловно большой молодец, что разобрались со своим кейсом и поделились опытом! Но мне вот просто интересно - почему бы не описать спецификацию в yaml/json формате, и из неё уже сгенерировать код под Echo сервер используя, например, deepmap/oapi-codegen? Вносить изменения будет так же просто - изменили спеку (контракт), сгенерировали соответствующий код, поправили имплементацию. Но правило источника истины в этом случае сохраняется, и бережёт вас же от обратно-несовместимых изменений, и значительно упрощает ревью. Да и кода будет меньше, и поддерживать 3rd party решение вам не придётся.
Для однотипных проектов давно придуман boilerplate, но придумать проблему и мужественно ее решить - тоже отдельный вид искусства, согласен (извиняюсь за токсичность)
И еще одна крохотная ремарка - не используйте bash, там где без него "ну никак". В частности, в
restartSwapон ну совсем лишний