как то так

не. я понимаю как type assertion пользоваться

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

или это нормально и все так делают?

ждать го 2 и дженериков

или это нормально и все так делают?

Все так и делают, как бы )

ждать го 2 и дженериков

некогда - сегодня вечером в продакшен

некогда - сегодня вечером в продакшен

либо шашечки, либо ехать

одно из двух

В конкретном rest api строго регламентированный список параметров, это факт

каких параметров?

каких параметров?

Которые я принимаю в url, multipart-form, да хоть в headers

Меня смущает в graphql тот факт, что фронт будет дергать данные как ему заблагорассудится...

это и решает проблему over- и underfetching'а и tight coupling'а

Это будет прописано в доках и тд

это и решает проблему over- и underfetching'а и tight coupling'а

Это как бы не всегда проблема )))

Которые я принимаю в url, multipart-form, да хоть в headers

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

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

интерфейс простой только один метод String() string и этот метод есть в структуре

Это как бы не всегда проблема )))

когда начнёшь писать валидацию данных (input/output)... когда в медленных сетях наткнёшься на высокую латентность в следствии n+1 roundtrip'ов... когда будешь документировать... когда клиентов много а API один и каждому нужны разные данные и высокая производительность... в любом из этих случаев стоит перейти с REST на GraphQL, ибо иначе будешь изобретать свой GraphQL со всеми вытекающими из этого последствиями ладно, нет ни времени ни желания учить тому, что млжно прочитать в доках, лишь пожелаю удачи

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

playground ссылку в студию

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

Кто кого должен имплементировать?

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

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

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

типизация, в REST? да вы издеваетесь?

когда начнёшь писать валидацию данных (input/output)... когда в медленных сетях наткнёшься на высокую латентность в следствии n+1 roundtrip'ов... когда будешь документировать... когда клиентов много а API один и каждому нужны разные данные и высокая производительность... в любом из этих случаев стоит перейти с REST на GraphQL, ибо иначе будешь изобретать свой GraphQL со всеми вытекающими из этого последствиями ладно, нет ни времени ни желания учить тому, что млжно прочитать в доках, лишь пожелаю удачи

Не уверен что есть кто-то кроме fb или подобно крупных игроков у кого есть такая проблема

типизация, в REST? да вы издеваетесь?

Marshal/unmarshal не на уровне rest)

Не уверен что есть кто-то кроме fb или подобно крупных игроков у кого есть такая проблема

http://graphql.org/users/

http://graphql.org/users/

Это те кто пользуется, но не те кто испытал проблему перенасыщения разнотипными клиентами

Marshal/unmarshal не на уровне rest)

в этом то и проблема, что тебе всё это ручками пилить, и валидацию, и документацию, и error reporting... всё всё всё самому

Это те кто пользуется, но не те кто испытал проблему перенасыщения разнотипными клиентами

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

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

С этим конкретно столкнулся fb раз придумал себе ql))) остальные тупо на хайпе

в этом то и проблема, что тебе всё это ручками пилить, и валидацию, и документацию, и error reporting... всё всё всё самому

Не все, только доку... но красивую и понятную доку все равно ручками делать ;)

С этим конкретно столкнулся fb раз придумал себе ql))) остальные тупо на хайпе

ну да, во всём хайп виноват, а REST это наше святое, его не трогай))))

удачи тебе

ну да, во всём хайп виноват, а REST это наше святое, его не трогай))))

Rest это не инструмент... как бы

Зачем сравниваешь мягкое с горячим?)

Сам gql не всем хорош, чтобы бездумно все на нем делать...

удачи тебе

Я уже по твоим пожеланиям самый удачливый человек)))

playground ссылку в студию

https://play.golang.org/p/KvcJVFutrr-

всем привет, подскажите пожалуйста по структуре кода: package db import ( "database/sql" _ "github.com/lib/pq" "fmt" "go.uber.org/zap" ) var ( log *zap.SugaredLogger result float64 err error ) type DB struct { *sql.DB } func Initdb() (*DB, error) { logger, _ := zap.NewProduction() log = logger.Sugar() defer log.Sync() dbinfo := fmt.Sprintf("host=%s port=%s user=%s password=%s dbname=%s sslmode=disable", DB_HOST, DB_PORT, DB_USER, DB_PASSWORD, DB_NAME) db, err := sql.Open("postgres", dbinfo) if err != nil { return nil, err } return &DB{db}, nil } func (db *DB) SumQuantity(time_from string, time_to string) (float64) { err = db.QueryRow("SELECT sum(row) from table where tradetime BETWEEN $1 AND $2", time_from, time_to).Scan(&result) if err != nil { log.Fatalf("Error query: ", err) } return result } стоит ли выносить структуру DB из пакеты в отдельное место? обработку лучше делать в методе или выносить в основную программу?

Я уже по твоим пожеланиям самый удачливый человек)))

ну это-ж прекрасно)

https://play.golang.org/p/KvcJVFutrr-

а вопрос?

а вопрос?

почему не имплементируется интерфейс?

почему не имплементируется интерфейс?

будь здоров))

всем привет, подскажите пожалуйста по структуре кода: package db import ( "database/sql" _ "github.com/lib/pq" "fmt" "go.uber.org/zap" ) var ( log *zap.SugaredLogger result float64 err error ) type DB struct { *sql.DB } func Initdb() (*DB, error) { logger, _ := zap.NewProduction() log = logger.Sugar() defer log.Sync() dbinfo := fmt.Sprintf("host=%s port=%s user=%s password=%s dbname=%s sslmode=disable", DB_HOST, DB_PORT, DB_USER, DB_PASSWORD, DB_NAME) db, err := sql.Open("postgres", dbinfo) if err != nil { return nil, err } return &DB{db}, nil } func (db *DB) SumQuantity(time_from string, time_to string) (float64) { err = db.QueryRow("SELECT sum(row) from table where tradetime BETWEEN $1 AND $2", time_from, time_to).Scan(&result) if err != nil { log.Fatalf("Error query: ", err) } return result } стоит ли выносить структуру DB из пакеты в отдельное место? обработку лучше делать в методе или выносить в основную программу?

Как то неприятно на вид

Как то неприятно на вид

вот как можно было бы сделать лучше

есть какой best practices?

или примеры

Мне ORM больше импонирует

есть какой best practices?

До этого писал на пхп или питоне?

До этого писал на пхп или питоне?

на питоне чуть чуть

будь здоров))

https://play.golang.org/p/6OEDO_FjlRx

поправил там должен быть интерфейс IB но все равно не работает

https://play.golang.org/p/6OEDO_FjlRx

перефразируй свой вопрос, он был довольно непонятен

поправил там должен быть интерфейс IB но все равно не работает

Такое не прокатит

Такое не прокатит

Интерфейс в интерфейсе не катит?

Интерфейс в интерфейсе не катит?

Да, типы в го не ковариантны

?

?

Ты пытаешься обобщить Test() *B как Test() IB, предполагая что *B = IB, но даже если *B = IB, для го Test() *B != Test() IB

Ты пытаешься обобщить Test() *B как Test() IB, предполагая что *B = IB, но даже если *B = IB, для го Test() *B != Test() IB

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

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

Концептуально какую проблему ты хочешь решить?

получить из пакета X какую-то структуру

Концептуально какую проблему ты хочешь решить?

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

как - то так и живем)

получить из пакета X какую-то структуру

https://play.golang.org/p/fcpw9BlYk-T

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

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

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

даже джавист поймет!

ERROR: S client not available

Мне ORM больше импонирует

ну orm я так понимаю вообще самое последнее дело использовать

ну orm я так понимаю вообще самое последнее дело использовать

Если упретесь в какой-то средней сложности запрос - будет бо-бо

мы так ушли от GORMa

ну вот, поэтому пытаюсь без orm, но не знаю как правильно все это оформить

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

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

goqu

goqu

о, спасибо за информацию

гоку какие-то не те кавычки рисует, мускуль ругается

Всем привет. Глупейший вопрос, но вот хочется узнать, как Go, как язык для бэка? Я сейчас в распутье между Node.js, Scala и Go, как язык для бэка. Опыт в бэке есть, но на джаве, большой соблазн написать что-нибудь именно на Go. Как с работой сейчас?

Прям сейчас очень хорошо

Всем привет. Глупейший вопрос, но вот хочется узнать, как Go, как язык для бэка? Я сейчас в распутье между Node.js, Scala и Go, как язык для бэка. Опыт в бэке есть, но на джаве, большой соблазн написать что-нибудь именно на Go. Как с работой сейчас?

В штатах/Европке хайп на Go (и React Native), с работой сильно лучше, чем год назад Бери Го, Скала - ад

Всем привет. Глупейший вопрос, но вот хочется узнать, как Go, как язык для бэка? Я сейчас в распутье между Node.js, Scala и Go, как язык для бэка. Опыт в бэке есть, но на джаве, большой соблазн написать что-нибудь именно на Go. Как с работой сейчас?

Год уйдет, только чтобы ту скалу выучить

В штатах/Европке хайп на Go (и React Native), с работой сильно лучше, чем год назад Бери Го, Скала - ад

Спасибо за ответ. Да не, скала тоже няшная. А фуллстеки актуальны, например React+Redux/Go?

Год уйдет, только чтобы ту скалу выучить

Ну это уж субъективно слишком :) Смотря как учить

Год уйдет, только чтобы ту скалу выучить

зависит от бэкграунда

ну orm я так понимаю вообще самое последнее дело использовать

Почему?)

Почему?)

говорят меньше гибкости предоставляет и время на то чтобы обучиться определенной orm уйдет больше чем писать чистый sql

говорят меньше гибкости предоставляет и время на то чтобы обучиться определенной orm уйдет больше чем писать чистый sql

На го все равно нет орм, так что придется учить sql

На го все равно нет орм, так что придется учить sql

они то есть по факту, просто вникать не хочется)

они то есть по факту, просто вникать не хочется)

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

На го все равно нет орм, так что придется учить sql

Не в том понимании как в php да, в основном кросс. Query builder

Не в том понимании как в php да, в основном кросс. Query builder

Ну я так и делаю, сначала в датагрипе пишу запрос, а потом просто переделываю его на горм

Если потом бд поменяется в последствии, то хреново все переписывать... миграции и тд

Я про голый sql

Если потом бд поменяется в последствии, то хреново все переписывать... миграции и тд

Только идиот будет менять бд

Только идиот будет менять бд

Нет, к примеру надо впарить одну систему двум заказчикам, но у обоих разные бд

Только идиот будет менять бд

бизнес потребует, поменяешь

А так с qb уже проще

гайз, нужно, чтобы один файлик xxx_test.go не ранился что там в go test указать?

бизнес потребует, поменяешь

Я с монги проект переделывал на постгрес, но тут никакая орм не спасла бы ситуацию

Я с монги проект переделывал на постгрес, но тут никакая орм не спасла бы ситуацию

Ну так это же не sql