Size: a a a

2020 October 06

AK

Arseny Khoroshilov in Go-go!
Artem Zheltak
Вопрос про varidic, можете обьяснить почему в го не разрешают делать
result := tx.Exec(query, uuid,ids...)
а только  
result := tx.Exec(query, values...)

для сигнатуры
func (s *DB) Exec(sql string, values ...interface{}) *DB {
Видимо, потому что лексить сложнее. Он ждёт либо кучу (в т.ч.) Т последним аргументом, либо список из Т с многоточием. А тут ни то, ни то.
источник

M

MrSmith in Go-go!
Adv0cat
Вы же понимаете, что микросервисы ничем не отличабтся от обычных монолитных приложений по сути?)) Ну т.е. все что делать нужно с монолитами, то же и с микросервисами, такой же CI/CD, такая же оркестровка, в общем всё похожее. Добавляется только взаимодействие между этими микросервисами и то, через апи, как если бы эти сервисы были далеко от вас, типа фейсбук апи, гугл апи и т.д. Т.е. в итоге можно применять все практики, которые были для монолитов на микросервисы 😊
Батарея отличается от кошки, но в принципе одно и тоже
источник

M

MrSmith in Go-go!
Монолит и микросервисы это про размер а не про структурную организацию
источник

M

MrSmith in Go-go!
Линукс не микросервисы не потому что так нельзя
источник

AZ

Artem Zheltak in Go-go!
pragus
variadic может быть только последний аргумент
вот я думал что последний, но не единственный
источник

A

Adv0cat in Go-go!
MrSmith
Батарея отличается от кошки, но в принципе одно и тоже
Иксперт ворвался в тред 😄
источник

M

MrSmith in Go-go!
Да корова священная вот я и не понял ниче
источник

M

MrSmith in Go-go!
Раньше как будто никто не использовал сокеты и различные костыли для апа систем
источник

M

MrSmith in Go-go!
https://m.habr.com/ru/post/249183/
Я вот эту вот статью читал. Ещё слушал чуваков которые готовили где то доклад о том как они решали проблемы согласованности API. Вообшем у меня сложилось впечатление что в реальности микросервисы не решают проблемы, а скребают их под ковер и вместо уровень кода, ты их будешь мучат на уровне инфраструктуры.
Возникает вопрос, а зачем? Простому то программисту не за чем
источник

DP

Daniel Podolsky in Go-go!
на самом деле - решают, но не ту, о которой все сразу думают
источник

DP

Daniel Podolsky in Go-go!
сделать из монолита комок грязи (это термин) очень просто
источник

HF

Harry Fox in Go-go!
MrSmith
https://m.habr.com/ru/post/249183/
Я вот эту вот статью читал. Ещё слушал чуваков которые готовили где то доклад о том как они решали проблемы согласованности API. Вообшем у меня сложилось впечатление что в реальности микросервисы не решают проблемы, а скребают их под ковер и вместо уровень кода, ты их будешь мучат на уровне инфраструктуры.
Возникает вопрос, а зачем? Простому то программисту не за чем
где-то убавляют проблем, где-то прибавляют
источник

DP

Daniel Podolsky in Go-go!
сделать из микросервисов комок грязи сложнее, но и результат более разрушительный
источник

T

Taras in Go-go!
MrSmith
https://m.habr.com/ru/post/249183/
Я вот эту вот статью читал. Ещё слушал чуваков которые готовили где то доклад о том как они решали проблемы согласованности API. Вообшем у меня сложилось впечатление что в реальности микросервисы не решают проблемы, а скребают их под ковер и вместо уровень кода, ты их будешь мучат на уровне инфраструктуры.
Возникает вопрос, а зачем? Простому то программисту не за чем
Затем, что когда у тебя штаб из 40 или 100 или 300 девов монолит будет адом
источник

M

MrSmith in Go-go!
Taras
Затем, что когда у тебя штаб из 40 или 100 или 300 девов монолит будет адом
Да ну, 300 обезьян вы хотели сказать?
источник

HF

Harry Fox in Go-go!
на докладах и в статьях часто вижу/слышу
- независимая разработка несколькими командами
- повышенная отказоустойчивость
- легче вносить изменения, т.к. маленький сервис легче охватить
- легче доставка на прод
источник

T

Taras in Go-go!
как раз независимая
источник

DP

Daniel Podolsky in Go-go!
микросервисы решают проблемы на стыке разработки и эксплуатации (масштабирование и BG deploy)
источник

T

Taras in Go-go!
На практике не совсем независимая. Но вот пример. Разделяешь всех по командах и каждая команда несет ответсвенность только за свой сервис
источник

DP

Daniel Podolsky in Go-go!
и на стыке разработки и бизнеса (новые бизнес-требования можно внедрять плавно)
источник