ЕО
У нас SAAS и этого API от него
Size: a a a
2020 August 24
IK
А, то есть паблик API?
ЕО
Ага
ЕО
На прошлой работе был grpc-gateway с похожими целями. Но плюс мы фронт на публичный апи переносили
Y
А никто не сталкивался с проблемой, когда указываешь полные пути к импортам внутри проекта, то при попытке собрать go build в приватном репо github ругается с ошибкой
При этом гиту я явно указал ходить по ssh на github
fatal: could not read Username for 'https://github.com': terminal prompts disabledПри этом гиту я явно указал ходить по ssh на github
DP
значит, не указал
Y
значит, не указал
вроде бы указал. Модуль он на гитхабе при этом находит
Конфиг в гите прописан:
Конфиг в гите прописан:
[url "git@github.com:"]
insteadOf = https://github.com
DP
вроде бы указал. Модуль он на гитхабе при этом находит
Конфиг в гите прописан:
Конфиг в гите прописан:
[url "git@github.com:"]
insteadOf = https://github.com
[url "git@github.com:"]
insteadOf = https://github.com/
Y
[url "git@github.com:"]
insteadOf = https://github.com/
а в чем разница? =)
М
Коллеги, какие у вас кейсы использования grpc-gateway?
Когда и почему решаете использовать не одно или другое, а оба?
Когда и почему решаете использовать не одно или другое, а оба?
Это неплохой способ описывать REST сервисы
Автоматическая документация + Swagger + строго типизированное API с автоматическими маппингами
Автоматическая документация + Swagger + строго типизированное API с автоматическими маппингами
AB
Коллеги, какие у вас кейсы использования grpc-gateway?
Когда и почему решаете использовать не одно или другое, а оба?
Когда и почему решаете использовать не одно или другое, а оба?
микросервисы запускаются с HTTP и gRPC открытыми портами
сервисы друг с другом общаются по gRPC
но если этого кому-то не хватает (неудобно) - то можно слать запросы по HTTP, можно посмотреть API в swagger. обычно это тестировщики аналитики, бекенд-разработчики соседних команд, когда занимаются интеграцией, фронт-енд разработчики, когда прикручивают UX
сервисы друг с другом общаются по gRPC
но если этого кому-то не хватает (неудобно) - то можно слать запросы по HTTP, можно посмотреть API в swagger. обычно это тестировщики аналитики, бекенд-разработчики соседних команд, когда занимаются интеграцией, фронт-енд разработчики, когда прикручивают UX
IK
Я сегодня интересный аргумент услышал - что grpc зависит от вендорной библиотеки (protoc), который может ломаться при обновлении, и версии станут обратно несовместимыми. А с REST такого быть не может
IK
Никогда не смотрел под таким углом
ЕО
Я сегодня интересный аргумент услышал - что grpc зависит от вендорной библиотеки (protoc), который может ломаться при обновлении, и версии станут обратно несовместимыми. А с REST такого быть не может
С рест такое скорее будет всегда, потому что ты зависишь от парсеров JSON и их разработчики даже не пытаются сделать что-то консистентное
C
Я сегодня интересный аргумент услышал - что grpc зависит от вендорной библиотеки (protoc), который может ломаться при обновлении, и версии станут обратно несовместимыми. А с REST такого быть не может
Разве protoc когда либо ломал обратную совместимость?🤔
IK
С рест такое скорее будет всегда, потому что ты зависишь от парсеров JSON и их разработчики даже не пытаются сделать что-то консистентное
Ну и да и нет, json все-таки в разумных пределах одинаково работают
ЕО
Ну и да и нет, json все-таки в разумных пределах одинаково работают
Ну нет, как раз наоборот
IK
Разве protoc когда либо ломал обратную совместимость?🤔
Говорят, что ломал. Я сам не видел, поэтому склонен верить