я решил на уровне main прокинуть в фабрику контейнер, а потом его там "растребушить" при инициализации

Looking at my current GraphQL API testing Go code I just had an idea of making GraphQL tests more declarative, because tests are what you want to be very easy to read and understand, error-prone testing is the worst! 1. define a query 2. define test conditions 3. define the expected parametric result 4. define expected conditions 5. implement the declared conditions in Go code 6. optionally, define the tests dependencies on other tests You'd generate the actual test code using gqltestgen ./, it'll collect all .gqltst files, parse them, generate a apitestsuite_test.go which can then be executed with go test -v -race This would also allow generating an API test coverage. The dependencies (test hierarchy) are useful to determine which tests should be run first to avoid having test query.user fail before mutation.createUser if actually the user creation mutation fails, not the user query node. What would you say? Do you like this idea? Do you think it's somehow limited or anything? Please don't hesitate to share your thoughts with me :leichtes_lächeln:

я решил на уровне main прокинуть в фабрику контейнер, а потом его там "растребушить" при инициализации

да, норм

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

да, норм

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

по хорошему он бы тоже мог контейнер дальше переслать...

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

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

у меня есть webserver

самому ему зависимости не нужны никакие

но хедлерам его нужны

поэтому он получает экземляр контейнера и без "требушения" кидает в хенделы

можно сделать по другому, выдрать инициализацию хендлеров "наверх" и там их иницилизировать

и скормить ему же уже накормленные

поэтому тут два варианта

Да вроде все в main инициализировать нужно

Первый: serv := http.NewWebServer(app) serv.Lisner() // Для main не существует больше никаких суб зависимостей, они спрятаны внутри

второй

routes := handlers.NewRouters(app) // Мы вытащили зависимость наверх serv := http.NewWebServer(app) serv.Lisner(routes)

в принципе мне кажется что второй вариант правильней

но он несколько более многословный, что и смущает

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

древнее зло пробудилось

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

+1

А кто какие библиотеки использует для работы с Docker API и как вы их мокаете? С Go работаю недавна, и вот встала передо мной такая задача

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

O_o

Я вот так хочу

- bin - user -- model.go // package user - cmd -- appname ---- main.go // package main - shared -- libname ---- any.go // package libname ---- test.go -- libnameTwo ---- any.go // package libnameTwo ---- test.go - vendor -- github.com ---- .... что-то такое "user" это домен, сам себе режиссер без зависимостей если их много, то можно положить в entities

Только у меня есть ещё папка db, и хочется там все запросы оставить к базе.

ну

Кажется нашёл статью, https://habr.com/post/269893/

в чем трабла то?

ну

Вот в чём, это образец: func main() { var p db.Handler db, err := p.InitDB() if err != nil { log.Fatal(err) } router := fasthttprouter.New() router.POST("/", db.getHandler) go func() { log.Fatal(fasthttp.ListenAndServe(":4000", router.Handler)) }() } func (p *Handler) getHandler(ctx *fasthttp.RequestCtx) { ... } getHandler отработает только если будет лежать в папке db. Но хэндлеры как-то не красиво там обрабатывать? Есть варианты?

Здравствуйте хотел бы задать вопрос, какую ORM лучше использовать? Пробовал gorm, но криво создаются связи, думаю перейти на go-pg, стоит ли? Слышал ещё про reform)

используйте reform. Я пока что ничего лучше не нашёл

Можно (лучше) вообще не использовать ORM.

go-pg больше фич для postgres, чем у reform

Можно (лучше) вообще не использовать ORM.

все так и делают в основном. что не отменняет того факта, что 90% SQL - раздражающий бойлерплейт

только orm не про sql)

все так и делают в основном. что не отменняет того факта, что 90% SQL - раздражающий бойлерплейт

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

И никакого "раздражающего" SQL не будет.

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

сейчас пишу кодогенерацию clojure —> golang + sql, поскольку потолок низковат

orm - это orm. квери билдер - это квери билдер. дата маппер - это дата маппер. писать в стиле "орм избавляет от sql болиерпринта" - круто, но к реальности отношения никакого не имеет

моя позиция была такова: "сгенеренный код - это тоже код, но не исходный, потому-что его не человек писал. Исходным кодом считается только то, что писал человек или сопостовимый интеллект" основываясь на https://softwareengineering.stackexchange.com/a/361460

Тут есть маленький нюанс. В идеальном мире, концептуально, и много ещё каких слов с похожим смыслом - да, кодогенерация - часть билда. В реальности же билд-инструментарий го не различает рукописный код и сгенеренный, т.е. для имеющихся инструментов оба кода достаточно исходные. Я не говорю, что это однозначно верное архитектурное решение, но го - такая штука, где чистоту архитектуры принято местами приносить в жертву практичности. Поэтому можно бесконечно обсуждать, как оно должно быть в идеале (а оно туда придет, но на основании наработанных практик, а не абстрактных рассуждений), а можно признать, что кодогенерация и компиляция для го - раздельные ортогональные процессы, и в текущий момент в данном контексте сгенеренный код ровно такой же исходный. Это решит некоторое количество проблем на выходе.

епт

вы опять за старое?

Тут есть маленький нюанс. В идеальном мире, концептуально, и много ещё каких слов с похожим смыслом - да, кодогенерация - часть билда. В реальности же билд-инструментарий го не различает рукописный код и сгенеренный, т.е. для имеющихся инструментов оба кода достаточно исходные. Я не говорю, что это однозначно верное архитектурное решение, но го - такая штука, где чистоту архитектуры принято местами приносить в жертву практичности. Поэтому можно бесконечно обсуждать, как оно должно быть в идеале (а оно туда придет, но на основании наработанных практик, а не абстрактных рассуждений), а можно признать, что кодогенерация и компиляция для го - раздельные ортогональные процессы, и в текущий момент в данном контексте сгенеренный код ровно такой же исходный. Это решит некоторое количество проблем на выходе.

я не говорил про компиляцию, я говорил про сборку проекта (build script). а это вещи разные

Дык, билд-скрипт - вообще отдельный вопрос. Кому-то как раз левая автоматизация только мешает

Ему, в смысле

ВИЛКА!

бан надо

Спамер несчастный

ТОО G1 Software Kazakhstan Астана, улица Е-49, 7 Требуемый опыт работы: 1–3 года Полная занятость, полный день Что нужно делать: В целом - писать проекты на Go Участвовать в непосредственном проектировании архитектур для новых решений; Писать лаконичный код, приправлять его хорошим количеством комментариев, а так же покрывать тестами. Главное - без фанатизма. Что нужно знать и уметь: Хорошее знание сетевых протоколов; Опыт написания асинхронных веб-приложений с использованием REST, понимание принципов работы вебсокетов; Опыт работы с PostgreSQL; Знание Git. Будет плюсом: Опыт построения высоконагруженных систем; Опыт работы с веб-фреймоворком Gin; Понимание работы RPC (в частности опыт использования RPCX); JIRA/Bitbucket/Confluence для вас не простой набор слов, который "вы видели где-то на Хабре"; Английский на уровне свободного чтения технической документации. Что мы предлагаем: Пятидневную рабочую неделю с 9.00 - 18.00; Отличные возможности для профессионального роста и развития; Динамичную и дружественную рабочую атмосферу в успешной команде; Интересные и нестандартные проекты; Достойный оклад на стабильной основе.

ТОО G1 Software Kazakhstan Астана, улица Е-49, 7 Требуемый опыт работы: 1–3 года Полная занятость, полный день Что нужно делать: В целом - писать проекты на Go Участвовать в непосредственном проектировании архитектур для новых решений; Писать лаконичный код, приправлять его хорошим количеством комментариев, а так же покрывать тестами. Главное - без фанатизма. Что нужно знать и уметь: Хорошее знание сетевых протоколов; Опыт написания асинхронных веб-приложений с использованием REST, понимание принципов работы вебсокетов; Опыт работы с PostgreSQL; Знание Git. Будет плюсом: Опыт построения высоконагруженных систем; Опыт работы с веб-фреймоворком Gin; Понимание работы RPC (в частности опыт использования RPCX); JIRA/Bitbucket/Confluence для вас не простой набор слов, который "вы видели где-то на Хабре"; Английский на уровне свободного чтения технической документации. Что мы предлагаем: Пятидневную рабочую неделю с 9.00 - 18.00; Отличные возможности для профессионального роста и развития; Динамичную и дружественную рабочую атмосферу в успешной команде; Интересные и нестандартные проекты; Достойный оклад на стабильной основе.

Вилка?

Вилка?

Добрый конь, да красавица жена

250-500 тыс тг

Извините, что не указали сразу

250-500 тыс тг

50-100к российских рублей

ERROR: S client not available

расходимся

расходимся

Они же Джуна ищут

Для Джуна норм

Угу, июнь архитектуру будет проектировать

Они же Джуна ищут

> джун > 1-3 года

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

хотя... > казахстан для них может и норм

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

Вроде как нормальная ЗП для джуна который живёт не в Москве и не в Питере)

Вроде как нормальная ЗП для джуна который живёт не в Москве и не в Питере)

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

> джун > 1-3 года

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

хотя... > казахстан для них может и норм

Миддл-казахстанец, получаю ~50k RUB и это ещё считается неплохой ЗП, на предыдущем месте предлагали 20

Вроде как нормальная ЗП для джуна который живёт не в Москве и не в Питере)

Для Московского Джуна это тоже норм жп

хз как в мск, но для джуна после института в питере 50К хорошая з.п.

Для Московского Джуна это тоже норм жп

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

или просмотра гайдов хауди

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

Нормальный работодатель не будет брать Джуна без нормального опыта на 100к

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

Это уже какие-то влажные фантазии пошли

я без выхи на 50к на испытательный срок пошёл во фронтенд, и это во Владивостоке

s/фронтенд/любая ёбань связанная с вебом/

и это я на первом же собесе отобрался

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

а так то ясен хер, что сейчас ставка в объявлениях на джунов пониженная, ибо развелось всяких выпускников гикбрейнса и зрителей хауди из-за хайпа вокруг IT

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

я без выхи на 50к на испытательный срок пошёл во фронтенд, и это во Владивостоке

и без комерческого опыта во фронте?

и без комерческого опыта во фронте?

да

был некомерческий опыт полторы недели ))0

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

да не гений я, а дефолтный парень, который в IT пошёл не из-за денег, а из-за увлечения

Сорян