GRPC gateway неудобен для полноценного использования HTTP, плюс на проксирование дополнительные ресурсы уходят. У нас на работе тоже его использовали и в какой-то момент возникла необходимость больше возможностей HTTP использовать. В частности, отдавать 304 Not Modified, когда данные не обновились. На гейтвее это если и можно было сделать, то очень неудобно. Поэтому решили нативную реализацию сделать. И чтобы плавно перейти, я начал делать генератор http сервера из proto файла. В целом всё получилось и с гейтвея мы слезли. Теперь можно из прото файла отдельно сделать GRPC и HTTP сервер. Производительность улучшилась и можно явно заголовками оперировать. Стримы и файлы не поддерживаются, т.к. потребности не было, но в целом хочется проект доделать, чтобы полноценным был. Генерацию спецификации на гугловый генератор перенесли. Есть нюансы, но в целом аналогично работает https://github.com/google/gnostic/tree/main/cmd/protoc-gen-openapi Сам проект генератора http: https://github.com/MUlt1mate/protoc-gen-httpgo
Похожий функционал есть на сайте http://wordsfromtext.com/. Только там ты сам отмечаешь слова, которые знаешь, и система переводит только незнакомые. В целом очень удобно, но субтитры с переводом можно делать только в платной версии.
Полтора года назад сделал онлайн-расписание на дипломный проект. До этого все через эксель создавалось, и у студентов доступ был только к печатному варианту. Расписание ЧИ БГУЭП
у вас указано, что есть еще protobuf для grpc. Как вы в таком случае синхронизируете контракт между openapi и protobuf и гарантируете совместимость?
я такую же проблему решал, но с другой стороны. нужно было с grpc переходить на http, решил сохранить proto файлы и поверх них написать генератор.
Кажется такой подход чуть лучше работает:
общий контракт для gprc и http
правила валидации можно в том же proto прописать
openapi можно из proto генерировать
Моя команда генерации так выгядит:
--go_out=paths=source_relative:. - структуры го
--go-grpc_out=paths=source_relative:. - grpc обертка
--validate_out=lang=go,paths=source_relative:. - валидатор (envoyproxy/protoc-gen-validate)
--openapi_out=output_mode=source_relative:. openapi(google/gnostic)
--httpgo_out=paths=source_relative:. http server+client (моё решение https://github.com/MUlt1mate/protoc-gen-httpgo)
GRPC gateway неудобен для полноценного использования HTTP, плюс на проксирование дополнительные ресурсы уходят.
У нас на работе тоже его использовали и в какой-то момент возникла необходимость больше возможностей HTTP использовать.
В частности, отдавать 304 Not Modified, когда данные не обновились. На гейтвее это если и можно было сделать, то очень неудобно.
Поэтому решили нативную реализацию сделать. И чтобы плавно перейти, я начал делать генератор http сервера из proto файла.
В целом всё получилось и с гейтвея мы слезли. Теперь можно из прото файла отдельно сделать GRPC и HTTP сервер.
Производительность улучшилась и можно явно заголовками оперировать.
Стримы и файлы не поддерживаются, т.к. потребности не было, но в целом хочется проект доделать, чтобы полноценным был.
Генерацию спецификации на гугловый генератор перенесли. Есть нюансы, но в целом аналогично работает https://github.com/google/gnostic/tree/main/cmd/protoc-gen-openapi
Сам проект генератора http: https://github.com/MUlt1mate/protoc-gen-httpgo
Возведение в степень вычисляется справа налево.
2 ** 3 ** 2 == 512;2 ** (3 ** 2) = 2 ** 9 = 512Я, кстати, дост)
$data = json_decode($resp, true);То есть заочно обучаться тоже можно?
1. Чтение со скоростью свыше 1000 слов в минуту невозможно?
Да, чтение со скоростью свыше 1000 слов в минуту невозможно.
Нет, чтение со скоростью свыше 1000 слов в минуту невозможно.
Извините, не удержался)))