А почему с ноды переписывать хотите?

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

Ооо, здорово.

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

Лично я такие не встречал. Пишу сам просто и все.

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

А чем вы думаете должно принципиально отличаться? Все таки ООП и там и там. Да и нода с го во многом похожи.

скинул бы пример на 5к строк, да реп приватный

в общем, можно, но не всегда нужно

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

А чем вы думаете должно принципиально отличаться? Все таки ООП и там и там. Да и нода с го во многом похожи.

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

например, так: project ├── routes.go ├── routes_stories_create.go ├── routes_stories_delete.go ├── routes_stories_update.go └── routes_stories_[...].go

скорее всего быстрее, но на уровне погрешности, видно наверное будет только на супер точных тестах

если к каждому файлу добавить ещё файл _test.go, то совсем каша

божечки

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

в го же тоже есть модули? Вы про какие модули?)

и зачем все складировать в корне?

есть несколько подходов к структурированию

каждый со своего предыдущего языка тянет свой

я бы сказал, что их не несколько, а дох;я)

в го же тоже есть модули? Вы про какие модули?)

да, я понимаю, что можно разбить на разные пэкэджи, но скажем если я сделаю отдельный package routes, а он много от чего зависит, что определяется в package main, скажем, он базы данных, то надо в него передавать все эти переменные

да, я понимаю, что можно разбить на разные пэкэджи, но скажем если я сделаю отдельный package routes, а он много от чего зависит, что определяется в package main, скажем, он базы данных, то надо в него передавать все эти переменные

Посмотрите на фото. Что-то страшное там случилось после написания _test?

https://github.com/boltdb/bolt

пример, когда все в корне (кроме бинаря)

Или так даже еще понятней теперь что там тестится? Помоему каши нет.

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

я правильно понимаю, что, например, models, routers — это отдельные package?

разумеется

вот. например вы открываете базу в package db, как вы её потом передаёте в routers? у вас же рауты должны использовать базу

берем инстанс из db?

например так: package routers var ( db *gorm.DB ) func receiveDb(dbRef *gorm.DB) { db = dbRef }

https://stackoverflow.com/questions/31218008/sharing-a-globally-defined-db-conn-with-multiple-packages-in-golang

?

А берется указатель на память.

да, я понял. makes sense.

Если вам удобно, вы можете возвращать инстанс соединения с бд в любую точку приложения, через метод к примеру. Но я сам так не делаю. Сейчас покажу.

да, понятно, спасибо.

Кстати, что есть best practice в "компилируемых" REST бекендах? Открывать\закрывать базу при каждом запросе, либо открыть только 1 раз при запуске приложения?

открывать и держать

Эх, а я постоянно заново открываю )))

да, понятно, спасибо.

А почему вы фреймворк взять не хотите, раз у вас в основном CRUD?

Так ему и с фреймворком нужно будет конектиться к бд же )

открывать и держать

Получается инстанс соединения с бд нужно будет "мьютить" при работе с ним? Или как?

Получается инстанс соединения с бд нужно будет "мьютить" при работе с ним? Или как?

Он тред сейф

Там по дефолту пул коннектов

Можно использовать параллельно прозрачно для себя

то есть это совсем не как со случаем с добавлением в массив да?

О, одной болью меньше )

то есть это совсем не как со случаем с добавлением в массив да?

Анна

Ага

Про пул надо проверить, правда, сколько он держит, вот это всё

Я не помню)

открывать и держать

Ахха. Теперь я понимаю что нет особо смысла соединять по unix сокету, если он 1 раз содинился и держит коннект )

именно

и ещё у меня был вопрос — про валидацию пользовательских данных на раутах. изобрёл как-то так, используя gojsonschema, но мне почему-то кажется, что тут слишком много происходит: package main import ( "encoding/json" "net/http" "github.com/xeipuuv/gojsonschema" ) func createStoryHandler(w http.ResponseWriter, r *http.Request) { story := Story{} documentLoader, reader := gojsonschema.NewReaderLoader(r.Body) decodeErr := json.NewDecoder(reader).Decode(&story) validationResult, err := createStorySchema.Validate(documentLoader) if err != nil { panic(err) } if !validationResult.Valid() { handleValidationError(validationResult) return } if decodeErr != nil { panic(decodeErr) } if err := db.Create(&story).Error; err != nil { panic(err) } w.WriteHeader(http.StatusCreated) }

именно

А самые частые ошибки какие? Вот резко падает база. Там как окннекшн клозет будет?

или nil pointer?

Ахха. Теперь я понимаю что нет особо смысла соединять по unix сокету, если он 1 раз содинился и держит коннект )

Все равно по сокету шустрее)

Все равно по сокету шустрее)

Так по unix сокеты коннектят, потому что он время на самом коннекте экономит вроде А что еще можно там сэкономить? )

А почему вы фреймворк взять не хотите, раз у вас в основном CRUD?

пока для прокачивания в гоу хочу всё руками написать, наверное, поэтому

ERROR: S client not available

а ну тогда правильно

и ещё у меня был вопрос — про валидацию пользовательских данных на раутах. изобрёл как-то так, используя gojsonschema, но мне почему-то кажется, что тут слишком много происходит: package main import ( "encoding/json" "net/http" "github.com/xeipuuv/gojsonschema" ) func createStoryHandler(w http.ResponseWriter, r *http.Request) { story := Story{} documentLoader, reader := gojsonschema.NewReaderLoader(r.Body) decodeErr := json.NewDecoder(reader).Decode(&story) validationResult, err := createStorySchema.Validate(documentLoader) if err != nil { panic(err) } if !validationResult.Valid() { handleValidationError(validationResult) return } if decodeErr != nil { panic(decodeErr) } if err := db.Create(&story).Error; err != nil { panic(err) } w.WriteHeader(http.StatusCreated) }

так вот про валидацию: кто как делает вообще?

Так по unix сокеты коннектят, потому что он время на самом коннекте экономит вроде А что еще можно там сэкономить? )

TCP все равно оверхед и на просто пакеты даёт

А есть книги по архитектуре в го?

TCP все равно оверхед и на просто пакеты даёт

Я блин вобще до сих пор не понимаю что это. Из-за парня который выше гооврил про валидацию )))

если по стандартной либе

а не всяким ОРМ

то вот

https://golang.org/pkg/database/sql/#Open

TCP все равно оверхед и на просто пакеты даёт

НУ ладно, на продакшене буду все равно unix сокет юзать. Да и на сам гошный веб будет по Unix форвардиться.

НУ ладно, на продакшене буду все равно unix сокет юзать. Да и на сам гошный веб будет по Unix форвардиться.

У 95% проектов, кстати, вообще плевать, тсп там или что, не такие большие нагрузки

Но думаю опыт не помешает.

Там ска в sql драйвере стандартном в примере мелкую ошибку они сделали, не увидел ее, задолбался искать )

он не стандартный

впрочем, юзается много где

вот список https://github.com/golang/go/wiki/SQLDrivers

и ещё у меня был вопрос — про валидацию пользовательских данных на раутах. изобрёл как-то так, используя gojsonschema, но мне почему-то кажется, что тут слишком много происходит: package main import ( "encoding/json" "net/http" "github.com/xeipuuv/gojsonschema" ) func createStoryHandler(w http.ResponseWriter, r *http.Request) { story := Story{} documentLoader, reader := gojsonschema.NewReaderLoader(r.Body) decodeErr := json.NewDecoder(reader).Decode(&story) validationResult, err := createStorySchema.Validate(documentLoader) if err != nil { panic(err) } if !validationResult.Valid() { handleValidationError(validationResult) return } if decodeErr != nil { panic(decodeErr) } if err := db.Create(&story).Error; err != nil { panic(err) } w.WriteHeader(http.StatusCreated) }

Я вообще касаемо таки вопросов иду на awesome-{ЯП} и там ищу нужную либу https://github.com/avelino/awesome-go#validation Но раз вы хотите качать скилл, то наверное нужно самому пробовать как то

там повеселее issue были https://github.com/go-sql-driver/mysql/issues/657

Я вообще касаемо таки вопросов иду на awesome-{ЯП} и там ищу нужную либу https://github.com/avelino/awesome-go#validation Но раз вы хотите качать скилл, то наверное нужно самому пробовать как то

для старта идеальное место вообще

для старта идеальное место вообще

а профи велосипеды пишут?)

иногда приходится

я, правда, еще себя профи не считаю :)

а профи велосипеды пишут?)

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

минутка философии: так то все в этом мире конструктор из готовых блоков

на минутку, атом - тоже готовый блок

собранный из кварков

Всё, мне объяснили что такое валидатор )

We have just released Go version 1.9.3, a minor point release. This release includes fixes to the compiler, runtime, and the database/sql, math/big, net/http, and net/url packages. View the release notes for more information: https://golang.org/doc/devel/release.html#go1.9.minor