быстрей, то почему бы сразу с них и не начать, например?)
потому что там есть оптимизации под бенчмарки)) да, он мб и быстрее стандратного, но явно не х10
Есть довольно интересный доклад, объясняющий особенности его работы: https://youtu.be/p1ILhiq5Clw, многие вопросы должны отпасть.
спасибо большое
ну даже х2 это уже аргумент, нет?
учитывая, что это время на условный роутинг и парсинг хедеров vs логика, походы в хранилище и тд то даже х2 в первом случае — вообще не аргумент
ну если разница в 1 милисекунду, то, думаю, да
упрётесь в отсутствие http/2.
хм, в таком случае gRPC как раз по http/2 протоколу работает. С учетом что мой бекенд сервер как раз и планируется под мобильное приложение, насколько разумным будет использовать gRPC вместо дефолтного REST API, есть ли тут люди с опытом, сильно выиграли от подобного?)
Основная победа тут будет за счёт использования единого контракта в виде протобафа
Можно в двух словах чем контракт в виде openapi не торт? Grpc здорово, но разработка на бэкенде и фронтеде будет денег стоить... Вопрос какая ожидаемая нагрузка? Если 10М запросов в сутки, то нафиг это надо? А когда будет столько - дописать будет не сложно.
openapi в некоторых случаях весьма торт, но я не про предложение заменить одно другим. Можно использовать grpc-gateway который поддерживает тот же openapi, и можно без проблем генериться под фронт когда это нужно, и при этом использовать протобаф там где это уместно. Но есть одно важное но - в своём коробочном решении grpc-gateway это прокся которая к тому же поражает дополнительное преобразование данных json->protobuf->json. В любом случае если у вас серьезный хайлоад - то скорее всего вы не будете генерировать клиент-серверверную часть из openapi, а если у вас всего лишь пара десятков тысяч rps на ноду, то в целом наплевать.
окей, в моем кейсе нужно максимально быстро обрабатывать запросы в которых не слишком легковесные запросы к постгресу в идеале нужно выдерживать до 300к одновременных запросов. Уместно ли сюда пихать gRPC или сойдет дефолтный го сервер и REST?
> в которых не слишком легковесные запросы к постгресу > до 300к одновременных запросов вам на рест/грпс скорее вообще не стоит обращать внимания, учитывая факты выше
Обсуждают сегодня