Всем привет, актуальна ли экосистема для го, как, например laravel&vue в php?

если у вас бинарь - какие у вас зависимости кроме ОС?

Всем привет, актуальна ли экосистема для го, как, например laravel&vue в php?

нет, все зависимости система тянет в себя

на совсем голых дистрибутивах, у нас например, требуется -installsuffix cgo

странный вопрос и ещё более странный ответ

странный вопрос и ещё более странный ответ

чем странный?

я сам лично не дошел, но говорят в докере на чистой OS не взлетело, из за либ

чем странный?

что за "экосистема laravel&vue" и при чём тут зависимости?

они сами по себе не стартуют, им вебсервер например желательно по пыху в частности

js тянет за собой как правило npm менеджер пакетов

Всем привет, актуальна ли экосистема для го, как, например laravel&vue в php?

А можно уточнить вопрос? ЧТО подразумевается под экосистемой?

Я так понял, если имелов в виду готовый каркас GO+React, то нет, таке есть (все включено, включая изоморфную, серверную генерацию страниц на JS)

Go+Vue я не видел. Но и видеть не хочу.

А можно уточнить вопрос? ЧТО подразумевается под экосистемой?

я думаю он про набор интепрераторов и прочего говна которое ездит

Боже, что за идиотизм пихать бекэнд и фронтенд в одну репу

Они меняются и деплоятся независимо друг от друга

Боже, что за идиотизм пихать бекэнд и фронтенд в одну репу

В том примере который я видел, репы разные. Задача Go - взять яваскрипт, его собрать, отдать, интерпретировать на сервере, отдать и серверный результат тоже.

щас=)

Зачем там Go?

https://github.com/olebedev/go-starter-kit

клиент и сервер в разных директориях, их можно независимо в разных репах держать

Зачем там Go?

Чтобы деплоить легко. GO всяко удобнее чем node.js

Ну такое. Я бы отдельный контейнер с сервер сайд рендериногом сделал

А не пихал бы это в сервер

Чисто мое имхо

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

тип файла любой, тут не важно

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

мб вынести файл в отдельный пакет, чтобы все остальные пакеты юзали его по одному адресу

вопрос про директорию как и куда

Go+Vue я не видел. Но и видеть не хочу.

правильно, Писать что-то серьезное на нетипизированном языке — нельзя. Как следствие, все фреймворки со своими шаблонами типа vue — сразу выкидываются в помойку, без попыток в них разобраться. Отсюда и любовь всех тупорых похапэшников к vue

мб вынести файл в отдельный пакет, чтобы все остальные пакеты юзали его по одному адресу

так он относится как раз к такому пакету, который вынесени именно код пакета, который выделен из основного срвиса, и должен его юзать

так он относится как раз к такому пакету, который вынесени именно код пакета, который выделен из основного срвиса, и должен его юзать

Так-с. В init() считал в переменную MyVar, и во всех остальных пакетах юзаешь mysqlpackage.MyVar.

Так?

из общей логики вычленены "модели данных" и вынесены в отдельный пакет, который можно заменить теперь другим пакетом моделей, которые реализуют такой же интерфейс. У каждого пакета моделей свой sql файлик и подключение к БД. А делаю так : var DatabaseClient *sqlx.DB var sqlSource *dotsql.DotSql func init(){ var requestFileErr error sqlSource, requestFileErr = dotsql.LoadFromFile("/app/assets/requests.sql") if requestFileErr != nil { logrus.Printf("Loading sql file failed: %s", requestFileErr.Error()) } sqlx.NameMapper = func(s string) string { return s } var mysqlErr error DatabaseClient, mysqlErr = sqlx.Open("mysql", mysqlUser+":"+mysqlPassWord+"@tcp("+mysqlHost+")/"+mysqlDatabase+"?charset=utf8") if mysqlErr != nil { logrus.Printf("Connecting to database storage failed : %s", mysqlErr.Error()) } DatabaseClient.SetConnMaxLifetime(time.Hour * 2) DatabaseClient.SetMaxOpenConns(100) }

сейчас указан путь в app/assets/request.sql потому что я вручную уже туда переложил для проверки при сборке контейнера. Да он найдет и подгружен успешно. Но хочу разобраться как его цеплять из самого пакета с моделями, или как его класть из пакета в контейнер Docker при сборке

Оу, докер, тут я отчаливаю ?

Оу, докер, тут я отчаливаю ?

ну а в принципе

как подгрузить файл который вызывается не в основной программе а в пакете

сейчас указан путь в app/assets/request.sql потому что я вручную уже туда переложил для проверки при сборке контейнера. Да он найдет и подгружен успешно. Но хочу разобраться как его цеплять из самого пакета с моделями, или как его класть из пакета в контейнер Docker при сборке

COPY откуда куда

там как надо путь указывать или класть файл. Там же LoadFromFile берет абсолютный путь

при сборке

как подгрузить файл который вызывается не в основной программе а в пакете

Тык вызывай в пакете в глобальную переменную. (Или я не понял суть вопроса)

а в чем проблема передавать пакету путь до файла при инициализации приложения, например, из env и хранить файл где хочешь?

не совсем понимаю в чем смысл держать не go'шный файл внутри пакета

а в чем проблема передавать пакету путь до файла при инициализации приложения, например, из env и хранить файл где хочешь?

Ну я хочу к примеру с гит сервера снять один из трех пакетов, и при сборке его подключить и использовать. Как именно при сборке сервиса из пакетов переложить этот файл. Он не в моем коде будет а в Vendor folder в зависимостях

коллега, опишите задачу человеческим языком. зачем вам этот файл?

+1

коллега, опишите задачу человеческим языком. зачем вам этот файл?

хорошо, сейчас опишу яснее

Был сервис у которого было N количество моделей (структур данных) данные которых грузятся из БД. Появилось несколько сервисов, которым нужны были эти же модели. Модели вынесены в отдельный пакет и должны использоваться несколькими сервисами. На этом этапе, код sql запросов уже вынесен из кода Go в отдельный файлик и подгружается в рантайме. В продолжение прошлого примера кода рядом выше приведу пример использования в коде , где уже читается часть sql файла : var modelData []AcsiRow request, _ := sqlSource.Raw("get-AcsiModel-data") dbErr := DatabaseClient.Select(&modelData, request, date, date, date) лежит с пакетом моделей. Так как допускается что потребуется в целом все модели подменить другими структурами, и остальные сервисы потребители смогут корректно работать. Есть алгоритм по которому при запуске сервисов подгружался файл sql запросов, подключались клиенты бд и кешей, и все работало. Сейчас пытаюс решить как лучше или правильнее хранить эти sql файлы, по 1 на пакет, и правильно их запускать/подгружать при запуске кода.

подменять планируется в рантайме или загрузка проиходит единовременно при старте приложения?

подменять планируется в рантайме или загрузка проиходит единовременно при старте приложения?

Один раз при сборке определенной версии или обновлении, собрали с определенной версией пакета моделей, запускаем..

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

нужно поменять запросы - рядом делаем еще один файл со структурой с тем же интерфейсом, но с другим sql и в main подключаем уже его

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

ну у меня get-AcsiModel-data указывает на конкртный участок sql

тобишь sql запросы вынесены для отдельного таска, тесты делать)

Был сервис у которого было N количество моделей (структур данных) данные которых грузятся из БД. Появилось несколько сервисов, которым нужны были эти же модели. Модели вынесены в отдельный пакет и должны использоваться несколькими сервисами. На этом этапе, код sql запросов уже вынесен из кода Go в отдельный файлик и подгружается в рантайме. В продолжение прошлого примера кода рядом выше приведу пример использования в коде , где уже читается часть sql файла : var modelData []AcsiRow request, _ := sqlSource.Raw("get-AcsiModel-data") dbErr := DatabaseClient.Select(&modelData, request, date, date, date) лежит с пакетом моделей. Так как допускается что потребуется в целом все модели подменить другими структурами, и остальные сервисы потребители смогут корректно работать. Есть алгоритм по которому при запуске сервисов подгружался файл sql запросов, подключались клиенты бд и кешей, и все работало. Сейчас пытаюс решить как лучше или правильнее хранить эти sql файлы, по 1 на пакет, и правильно их запускать/подгружать при запуске кода.

растащить sql запросы по отдельным файлам, собрать их в go код с помощью go-bindata, использовать средства go-bindata для доступа к соответствующим переменным

растащить sql запросы по отдельным файлам, собрать их в go код с помощью go-bindata, использовать средства go-bindata для доступа к соответствующим переменным

раньше реквесты жили в go коде. Это оказалос не удобно ибо они переодически корректируются. И тестить их вместо с кодом сервиса не удобно.

так я не предлагаю их в go-код обратно сложить

я предлагаю go-код собирать из sql файлов с помощью go generate

ну - я так делаю

раньше реквесты жили в go коде. Это оказалос не удобно ибо они переодически корректируются. И тестить их вместо с кодом сервиса не удобно.

ну приведенные вые примеры работают с 1 большим файлом sql запросов, которые размечены спец метками и правильно точечно выгружаются go либой в рантайме

я предлагаю go-код собирать из sql файлов с помощью go generate

я очень долго думаю в сторону генерации кода го, но мало инфы нашел пока...

очень нужно для дргогог таска с этими же сервисами

ERROR: S client not available

ну приведенные вые примеры работают с 1 большим файлом sql запросов, которые размечены спец метками и правильно точечно выгружаются go либой в рантайме

все еще можно использовать go-bindata

Вопрос, если я передам ссылку в функцию, потом внутри передам в эту ссылку - ссылку на значение в бд например. Оно же будет пустое на выходе?

func fill(modelField *string) { value := db.GetAttributeValue("blabla") if value != "" { modelField = &value } }

Здравствуйте, если кто-нибудь юзает boltdb и может дать совет по поводу правильной архитектуры, напишите, пожалуйста, в лс

а пишите прямо здесь, мне тоже интересно

Подскажите плз, почему это работает не как я ожидаю)) https://play.golang.org/p/cP0HL_V6IV

Подскажите плз, почему это работает не как я ожидаю)) https://play.golang.org/p/cP0HL_V6IV

я надеюсь что переменная m заполнится данными, но она всё равно пустая

https://s.mail.ru/LJXP/jHEkCeXWD

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

func (t *Model) ...

func (t *Model) ...

спасибо, а так сразу и не понятно

а пишите прямо здесь, мне тоже интересно

Хорошо. Просто интересно, как правильно нужно написать логику, чтобы была возможность писать тесты. То-есть есть какие-то функции, которые сохраняют модели в бд, но во время тестов должна использоваться тестовая бд. Я сделал так: 1. Есть глобальная переменная dbMode и две константы - normalMode и testMode. В init() dbMode = normalMode 2. Есть функция connectDB, которая смотрит на текущий dbMode и в зависимости от него возвращает бд (для тестов или для продакшена). 3. Функции для работы с моделями получают бд с помощью connectDB() 4. Во время тестов делаю dbMode = testMode и все, используется тестовая бд. Вот мне и интересно, насколько это ужасно

а в чем смысл разделения базы на тестовую и прод, если она встроенная?

про прод - я преувеличил, небольшое приложение для себя, хотя какая разница а как иначе? зачем мне в моей основной бд левые данные из тестов?

или вы про разные бакеты?

ну как правило для тестов используется отдельная бд, которая сетапится при инициализации и дропается по завершению тестов

файл с тестовой бд удаляется после тестов.

я немного не про это, коду незачем знать тестовая у нас база или прод можно вынести путь до файла с базой в конфигурацию и во время тестов подменять путь

исключив всю эту ненужную логику с маршрутизацией между базами

https://play.golang.org/p/Lekvya0NRs

цените

блин какое то извращение

я немного не про это, коду незачем знать тестовая у нас база или прод можно вынести путь до файла с базой в конфигурацию и во время тестов подменять путь

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

Пока решил кейс подгрузкой нужной версии пакета через govendor в Makefile, при сборке, и копированием файла в тело контейнера.

Но с кодогенерацией предстоит разобраться в любом случае

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

не вижу ничего криминального в таком подходе

не вижу ничего криминального в таком подходе

спасибо

ну - я так делаю

Какой либой пользуетесь?

Как узнать название страны ПО РУССКИ по её коду ISO-3166-1 ? Я нашёл несколько подобных либ, но все они в международной и английской локали. вот например https://github.com/pariz/gountries

есть пдф-ка https://www.ifap.ru/library/gost/7672003.pdf, но не парсить же её в конце концов ради такой фигни