Как перейти на gRPC, сохранив REST

Комментарии 8

  • 5dd35de0a74df7b3546e8eb7d5a070c5_small.j

    12.09.17 в 13:58

    0

    Спасибо за интересную статью! Подскажите, а есть ли неплохие русскоязычные статьи про grpc или в целом доки хватает?

    • 12.09.17 в 14:45

      0

      Чтобы начать и заинтересоваться, достаточно (взято из ссылок автора поста)
  • 12.09.17 в 15:52

    +1

    В grpc-gateway есть фатальный недостаток — он очень медленный. Цепочка выглядит: Umarshal JSON -> Marshal protobuf -> Call gRPC -> Marshal protobuf on server -> Unmarshal protobuf on gateway -> Marshal JSON.
    В Go на стороне сервиса довольно легко написать HTTP handler, который будет делать Unmarshal JSON’а напрямую в gRPC Request структуры (уже есть теги json) и вызывать реализацию gRPC метода.
    • 12.09.17 в 15:59

      +1

      Я бы не назвал это очень медленным: просто не самая оптимальная реализация, которая сойдет на время переходного периода.

    • ec08b2a31e7fa10530f2eb47032ff7e9_small.j

      12.09.17 в 16:27

      0

      Это правда, grpc-gateway это ещё одно звено в цепи, со своей сериализацией/десереализацией. Но «очень медленный» это относительная фраза — речь всё таки о десятках миллисекунд, что для многих случаев более чем позволительно.

      Подход с десереализацией напрямую может работать только в случае, если это один сервис. Если же вы, к примеру, разбиваете монолит на gRPC-сервисы, и при этом хотите сохранить legacy REST API (хотя бы на время), то уже так не получится. А так да, вариант.

  • 12.09.17 в 16:19

    0

    Чем GraphQL не устраивает?
    • ec08b2a31e7fa10530f2eb47032ff7e9_small.j

      12.09.17 в 16:33

      +1

      GraphQL это язык запросов, gRPC — это кросс-языковой RPC-фреймворк.
    • 12.09.17 в 17:38

      0

      GraphQL Patent Infringement Issues

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

© Habrahabr.ru