А в самом коде, как реализовывали? Через враппер?

враппер чего?

ну я так понимаю что у нас один ендпоинт

Который принимает запросы

И в нем мы смотрим какой method указал пользователь

это все унутре rpc спрятано

и в зависимости от него вызывает функцию

net/rpc ?

например тут https://github.com/semrush/zenrpc через switch/case

вы регистрируете хендлер, и он вызывается, на входе уже структуры, какие вы заявили

например тут https://github.com/semrush/zenrpc через switch/case

Я сейчас через switch делал

а зачем вам реализовывать сервер? есть же готовые либы

например тут https://github.com/semrush/zenrpc через switch/case

это прям официальный-официальный репо семраша?

это прям официальный-официальный репо семраша?

да

А что на счет net/rpc?

Сейчас увидел

https://golang.org/pkg/net/rpc/

так это, с ним и работаем

ok, понял

я так понимаю от по tcp бегает

то есть нет http оверхеда?

коллеги

что за херня

какой оверхед, кто его мерял?

да

это вообще не важно

вот когда вы обнаружите, что в требования ТЗ не укладываетесь - тогда и думайте

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

by the way, я для себя решил, что там, где возможно, буду делать RPC на REST (хоть это и ублюдочно)

а REST буду делать на swagger, кодогенерацией

и ниипет, что там код неоптимальный

и пока ни разу переделывать не пришлось

а REST буду делать на swagger, кодогенерацией

какой фрэймворк используешь?

https://github.com/go-swagger/go-swagger

другого, вроде, нет, с поддержкой генерации серверного кода на go

Почему просто не взять tcp и какой-либо фрейминг?

поддержка веба..

Привет. Почему в Go так плохо всё с GUI?

коллега, закругляйтесь

Привет. Почему в Go так плохо всё с GUI?

ну так сделай хорошо)

Всем привет

кто может поделиться проектом go с rest

или как backend framework лучший для go ?

go-swagger и вперед

go-swagger и вперед

backend с rest-api , чтобы в данном framworkе была архитектура , configов , prod-настроек , routers , models , permisson_guards

присутствует ?

коллега, вы бы доку почитали?

swagger, он же open api, есть стандарт индустриальный для описания rest

я еще не открывал просто читаю что люди советуют

соответственно, делать надо на нем

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

или как backend framework лучший для go ?

Ну я частенько, для пет проджектов пользуюсь chi для rest т.к. очень удобно реализовано использование jwt

Ну я частенько, для пет проджектов пользуюсь chi для rest т.к. очень удобно реализовано использование jwt

Спасибо за ответ

Спасибо за ответ

Нзчт!)

by the way, я для себя решил, что там, где возможно, буду делать RPC на REST (хоть это и ублюдочно)

Это как?

tcp это слишком низкоуровнево

Почему?

Это как?

я не понимаю вопроса :( никто не мешает нам написать RPC поверх RESTful, при этом нарушив некоторые принципы RESTful

Почему?

потому-что TCP ты не напишешь на JS для браузера, нет API, в браузере только WS(S)

я не понимаю вопроса :( никто не мешает нам написать RPC поверх RESTful, при этом нарушив некоторые принципы RESTful

Ну как бы rest несколько ортогонален rpc. И довольно быстро rpc съест rest

Как только мы начнем передавать endpoint одним из параметров

но seriously, зачем TCP? WS достаточно низкоуровневый и предоставляет дополнительные удобства как например поддержка шифрования посредством HTTPS, оверхеда там не значительно больше TCP/IP

но seriously, зачем TCP? WS достаточно низкоуровневый и предоставляет дополнительные удобства как например поддержка шифрования посредством HTTPS, оверхеда там не значительно больше TCP/IP

Wss

но seriously, зачем TCP? WS достаточно низкоуровневый и предоставляет дополнительные удобства как например поддержка шифрования посредством HTTPS, оверхеда там не значительно больше TCP/IP

Потому что сообщения по ws могут теряться.

ERROR: S client not available

Потому что сообщения по ws могут теряться.

таак, а вот тут подробнее плиз)

таак, а вот тут подробнее плиз)

А что подробнее? Как мы узнаем, что удаленная сторона получила сообщение?

А что подробнее? Как мы узнаем, что удаленная сторона получила сообщение?

WebSockets работает поверх TCP/IP соединения которое пораждает HTTP(S) запрос который потом апгрейдится в WS(S). если WS не гарантирует доставку, тогда HTTP не гарантирует и TCP/IP тоже, что естественно неправда, поскольку TCP/IP это не UDP, он reliable. WS не гарантируешь лишь одно: обработает ли сервер сообщение? поэтому в webwire есть request-reply. посылаем сообщение запрос и асинхронно ожидаем сообщение ответ.

WebSockets работает поверх TCP/IP соединения которое пораждает HTTP(S) запрос который потом апгрейдится в WS(S). если WS не гарантирует доставку, тогда HTTP не гарантирует и TCP/IP тоже, что естественно неправда, поскольку TCP/IP это не UDP, он reliable. WS не гарантируешь лишь одно: обработает ли сервер сообщение? поэтому в webwire есть request-reply. посылаем сообщение запрос и асинхронно ожидаем сообщение ответ.

tcp гарантирует доставку только до ядерного буфера на удаленном хосте. Остальное - нет.

tcp гарантирует доставку только до ядерного буфера на удаленном хосте. Остальное - нет.

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

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

А что подразумевается под ошибкой?

А что подразумевается под ошибкой?

есть несколько видов ошибок, ошибка ReqErr которая определяется user-code'ом, в ней есть CODE и MSG, аналогично HTTP status но с большей свободой и есть internal error, который только логируется но не отдаёт на клиент описание ошибки ради безопасности onRequest(ctx context.Context) (wwr.Payload, error) { msg := ctx.Value(wwr.Msg).(wwr.Message) if msg.Name != "auth" { // user-code error reply return wwr.Payload{}, wwr.NewReqErr("YOUR_CUSTOM_ERROR", "Something went wrong, check it out") } // Internal error, similar to HTTP 500 status, will be logged return fmt.Errorf("internal error, an unexpected error happened") }

А питерские чятики в тг есть по го?

А питерские чятики в тг есть по го?

Чем тебе этот не питерский?

Чем тебе этот не питерский?

Не ламповый какой-то)

Вопрос-ответ чятик

Вопрос-ответ чятик

А что должно быть? Телочки и наркотики?

В Питере народ суровый)))

А что должно быть? Телочки и наркотики?

не наркотики же! бухло...

WebSockets работает поверх TCP/IP соединения которое пораждает HTTP(S) запрос который потом апгрейдится в WS(S). если WS не гарантирует доставку, тогда HTTP не гарантирует и TCP/IP тоже, что естественно неправда, поскольку TCP/IP это не UDP, он reliable. WS не гарантируешь лишь одно: обработает ли сервер сообщение? поэтому в webwire есть request-reply. посылаем сообщение запрос и асинхронно ожидаем сообщение ответ.

Чем этот request-reply лучше HTTP/2?

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

не может, конечно

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

А питерские чятики в тг есть по го?

Чтобы с Гошницами знакомится? ?

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

Клиент должен прислать ответ на ответ. ?

Чтобы с Гошницами знакомится? ?

Рубистки красивше)

Чем этот request-reply лучше HTTP/2?

конкретно доклад писать не буду, времени нет, возможно напишу статью на медиум с полным подетальным раскладом он в любом случае легковеснее и гибче HTTP/2 но разница в плане request-reply не большая, ибо именно так и запланировано чтоб webwire мог спокойно заменять HTTP для коммуникации с API сервером. главная фишка в дуплексе. у HTTP нет обратной связи, long polling не решение да и server-push это про другое.. и нам не хотелось делать запросы по одному каналу, а получать оповещения по другому... это геморно, и там и там нужно связь мониторить, аутентифицировать и т.д. поэтому написали webwire, чтоб полностью работать на WS(S)

Коректне сравнивать с gRPC. Он тоже full duplex поверх HTTP/2, с request-reply, стримингом и таймаутами.

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

гарантии абсолютно идентичны с HTTP(S) всё что гарантирует HTTP, гарантирует и WebWire. - запрос гарантировано дойдёт. обработает ли сервер запрос? это ответственность пользователя, тут не может быть гарантий кроме timeout ошибки. получит ли клиент ответ на запрос? again.. возможно гарантировать только доставку и то что webwire-js или клиент из webwire-go вызовет соответствующий handler. если сеть пропала во время обработки запроса - будет ошибка, которую если не отработать - естественно сервер забудет про невыполненый запрос и на стороне клиента будет timeout

Коректне сравнивать с gRPC. Он тоже full duplex поверх HTTP/2, с request-reply, стримингом и таймаутами.

gRPC это RPC с protobuf поверх HTTP/2 webwire это extension для вебсокетов, более легковесный и гибкий их сложно сравнивать

HTTP/2 не заменит websockets, websockets не заменит HTTP/2 для разных проблем - разные решения. А webwire мы написали чтоб работать с API по вебсокетам ? поверх webwire тоже можно реализовать RPC с protobuf или чем угодно..

народ, а вы решаете подобные задачи. Есть 5 воркеров, они кладут в канал chan *MyStruct результаты работы. Но перед формированием неких данных в MyStruct надо убедится что в канал уже не поступала подобная структура (по ID)

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

можно в ворке прокинуть структурку на базе sync.Mutex, и там по get проверять, а добавление только через канал