это не такая проблема когда ты тыкаешься из нормального языка

но некоторые проблемы если ты на баше ваяешь клиента и дергаешь curl/wget

короче не надо ошибки с кодом 200 ок возвращать

если тебе оно важно

ну я со стороны UI смотрю если курлом, то пофиг, конечно

ну я со стороны UI смотрю если курлом, то пофиг, конечно

я смотрю со стороны вообще очевидности решения

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

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

бизнес ошибка, кеширующий сервис а ля cloudflare кеширует повторяющиеся запросы которые ведут к 500, статус ресурса меняется, то что было бизнес ошибкой являлось просто временным локом на ресурс, что делать?

короче если клиент ожидает что на ошибку он получит не-200 (а так обычно и бывает), а он получит "200" то это может быть очень плохо

бизнес ошибка, кеширующий сервис а ля cloudflare кеширует повторяющиеся запросы которые ведут к 500, статус ресурса меняется, то что было бизнес ошибкой являлось просто временным локом на ресурс, что делать?

на GET запросы?

короче если клиент ожидает что на ошибку он получит не-200 (а так обычно и бывает), а он получит "200" то это может быть очень плохо

разницы никакой клиенту всё так же нужно разбирать код ошибки и так же разбирать тело

разницы никакой клиенту всё так же нужно разбирать код ошибки и так же разбирать тело

да есть разница

есть разница всегда

сперва на код смотрят

потом уже на содержимое

когда у тебя ошибка приходит с "200" это блин пипец и хочется взять биту и идти убивать

^this

потому что это нефига не очевидное поведение

@slonoed давай ты так сделаешь, скажешь мне адрес, а потом не будешь удивляться сломанным рукам? :)

@slonoed давай ты так сделаешь, скажешь мне адрес, а потом не будешь удивляться сломанным рукам? :)

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

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

ну знаешь, можно и гланды через задницу удалять

технически

это не значит что так надо делать

@slonoed есть общепринятая семантика, что ошибка это 5xx

если ты ей не следуешь, тебя наздо бить битой

если все равно не следуешь - битой с гвоздями

все

ок

потому что технически клиенту конечно пофигу

но на практике человек может ожидать например исключения от библиотеки

или реально проверять статус

увидеть 200 и пойти обрабатывать данные

а там ты вот такую свинью подложил

уважай других и делай правильно

ок

Не подскажите, можно запарсить json, не имея модели этого json? Например, мне приходит какой-то json, я его тупо хочу запихнуть в бд. var err error var v []interface{} err = json.Unmarshal(request, &v) checkErr(err) c := Session.DB("a").C("b") err = c.Insert(v...)

Вот такой код падает с ошибкой(

В какую БД?

так пихай строкой как пришла

так пихай строкой как пришла

+1

или тебе валидировать нужно?

тогда валидатор прикрути

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

но это все равно будет строка

мона

[]byte

принимает же)

А, ну действительно, лол.

Спасибо

но я бы все равно валидировал хотя бы на размер

Добрый день. Народ, кто занимался написанием и развертыванием микросервисов на го? Что можете сказать про go-micro? Для написания этих самых сервисов, не избыточен этот framework? Или лучше все с ноля делать? Со своими интерфейсами, транспортным протоколом и тд? А то встала задача распилить проект на микросервисы, присматриваюсь к реализации именно на этом языке ...

Есть низкоуровневый go-kit, ограниченный go-grpc, и вполне себе go-micro

1 и 3 расширяется как вам нужно

Любой транспорт, любой MQ

И так далее

С 1 будет много бойлерплейта

Добрый день. Народ, кто занимался написанием и развертыванием микросервисов на го? Что можете сказать про go-micro? Для написания этих самых сервисов, не избыточен этот framework? Или лучше все с ноля делать? Со своими интерфейсами, транспортным протоколом и тд? А то встала задача распилить проект на микросервисы, присматриваюсь к реализации именно на этом языке ...

А, если не секрет, можно узнать как возникла такая задача?

Писать с нуля тоже нет смысла

А, если не секрет, можно узнать как возникла такая задача?

Бизнесу захотелось больше автономности, доступности, отказоустойчивости, децентролизованности, комплексного и глубокого мониторинга всех узлов системы, в общем обычная история по мере роста проекта и монолит с толстой ESB перестал вывозить, вернее удовлетворять требованиям в полной мере ... так же одной из задач и идей было посадить отдельные команды на разработку и дальнейшую поддержку сервисов, чтобы их можно было максимально легко обновлять, управлять ими, чтобы эти процессы не тормозили основное ядро. Как-то так, сумбурненько получилось конечно! И это все как раз и продиктовало переход на микросервисы и DDD.

Классика

А в чем преимущество использования RPC фреймворков перед брокерами сообщений для взаимодействия микросервисов?

сравнение бананов с апельсинами?

А в чем преимущество использования RPC фреймворков перед брокерами сообщений для взаимодействия микросервисов?

Ни в чем. Микросервисы взаимодействуют по RPC после сообщений

А в чем преимущество использования RPC фреймворков перед брокерами сообщений для взаимодействия микросервисов?

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

Да, вроде две очереди

Да, вроде две очереди

какие 2 очереди?)

видимо, вторая с ответами после обработки

а зачем тут вообще очереди?

но очереди тут реально не нужны

Да, вроде две очереди

не, это к вопросы как организовать RPC через брокер, а не в чем профит

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

Ну мне видится, что с фрейморками мы добавляем ещё один отдельный слой, от которого зависят все составляющие. Типа если два сервиса используют одну и ту же функцию, то потом, в случае доработки, их надо будет дублировать. С очередями все более локально - создал очередь и читай с нее Опять же, как происходит взаимодействие с микросервисами, написанными на других языках? Я не шарю, вопрос не риторический

Ну мне видится, что с фрейморками мы добавляем ещё один отдельный слой, от которого зависят все составляющие. Типа если два сервиса используют одну и ту же функцию, то потом, в случае доработки, их надо будет дублировать. С очередями все более локально - создал очередь и читай с нее Опять же, как происходит взаимодействие с микросервисами, написанными на других языках? Я не шарю, вопрос не риторический

rest api & versioning

»> Опять же, как происходит взаимодействие с микросервисами, написанными на других языках? у тебя микросервис отдает json, protobuf итд определенной схемы. Каким языком это сгенерировано по сути неважно

Надо будет попробовать поюзать крч, спасибо

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

handlers

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

То как делает это rabbitmq, два топика + correlation id

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

Cqrs в помощь как говорится

А в чем преимущество использования RPC фреймворков перед брокерами сообщений для взаимодействия микросервисов?

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

Чем делать кашу с req/reply и pub/sub

Всем ??. Есть проблема с растрированием (в картинку) utf текста, который содержит эмодзи. Они либо квадратиками (если в шрифте нет эмодзи), либо панику вызывают, если есть. Никто не сталкивался? Растрирую через github.com/fogleman/gg + golang/freetype, но проблема во втором как раз (судя по их репе). Есть ли другие способы перевести текст в изображение?

О статусах и ошибках с кодом 200.

Всем привет, пытаюсь записать в redis структуру CustomStruct. LPush реализует интерфейс MarshalBinary(), который конвертирует данные в []byte. Добавил метод MarshalBinary к CustomStruct, затем, получилось записать первый элемент из массива cs[0], а как записать туда весь массив? Прошу прощения за терминологию =) LPush func(key string, values ...interface{}) *IntCmd func SaveList(redis *redis.Client, cs []*CustomStruct) error { return redis.LPush("testKey", cs[0]).Err() }

for _, csItem := range cs { err := redis.LPush("testKey", csItem).Err() if err != nil { break } }

а это не слишком большой удар по производительности?

А, так можно

что означают точки перед interface{} вроде как томжно весь массив отправить как в database/sql там аргументы отправляются пачкой