Как подружить сервисы друг с другом?
Инженеры по всему миру навыдумывали всяких технологий, что башка кругом идёт, когда пытаешься во всём этом многообразии разобраться. Надо тебе намутить общение между сервисами - так одни говорят REST API юзай, другие крутят пальцем у виска и втюхивают свой gRPC, а кто-то сидит в уголке и натирает до блеска малоизвестный GraphQL. Ну и кого слушать?
Чаще всего технологии появляются, чтобы решить какую-то проблему, которую другие технологии или не решают, или решают фигово. Осталось понять, когда какую технологию применять, и будет нам счастье. Сейчас глянем на примерах, когда лучше юзать REST, когда gRPC, а когда и GraphQL можно расчехлить.
1. REST
Это как швейцарский нож в мире API. Он идеально подходит, когда вам нужно общаться с фронтендом. REST работает через HTTP/1.1, и браузеры отлично поддерживают этот протокол. JSON, который чаще всего используется в REST, легко обрабатывается на фронте, да и все к нему привыкли.
Есть у тебя магаз, где ты свои огурцы с кабачками продаешь. Заходишь ты на сайт магаза, и фронтенд запрашивает информацию о товарах с бэкенда. REST здесь нормас так ляжет. Ещё ж кайфово, если ребятки rest full поддержат, чисто по http методам будет ясно что делает та или иная ручка. Видишь patch метод и сразу всё ясно про это ваше обновление.
Несмотря на то, что JSON не самый лёгкий по весу формат и HTTP/1.1 не самый быстрый протокол, REST остаётся удобным и универсальным решением для большинства веб-приложений.
2. gRPC
А вот если ты вписался в мир микросервисов, то я тебе конечно соболезную, но надо как-то с этим жить. Запрос идёт с фронтенда, и чтобы собрать ответ, нам надо слазать в пяток микросервисов. Скорость тут уже начинает ролять сильнее. Надо мутить быстрый и эффективный способ обмениваться данными.
Тут-то и выходит на авансцену gRPC. Во-первых, он работает через HTTP/2, что уже делает его быстрее, так как умные ребята серьезно потюнили этот протокол с версии 1.1. Во-вторых, gRPC использует бинарный формат данных Protobuf, что уменьшает размер передаваемой информации. А коль сообщенька весит меньше, значит и летит по сети быстрее.
gRPC отлично подходит для взаимодействия между микросервисами, когда скорость и эффективность имеют решающее значение. Правда, чтоб настроить инфраструктуру для работы gRPC нужно побольше попотеть, но если сервисов много и вы завтра не планируете закрывать контору, то кажется игра стоит свеч.
3. GraphQL
Решил ты сделать магаз с кучей фильтров, где можно по-всякому вертеть, какие данные отображать при поиске, а какие нет. Не будешь же ты каждый раз получать с бекенда все данные, а фильтровать их уже на фронте. Это шляпа какая-то, которая забьет тебе сеть. Надо быть хитрее и запрашивать только то, что действительно нужно.
GraphQL — это как SQL для API: вместо того, чтобы получать фиксированный набор данных, как принято в контрактах REST или gRPC, ты можешь запросить ровно то, что нужно. Это снижает нагрузку на сеть и ускоряет загрузку данных, особенно когда речь идёт о сложных и динамичных запросах.
Итого
REST — проверенный годами варик, особенно для взаимодействия между фронтендом и бэкендом. gRPC идеально подходит для быстрого и эффективного взаимодействия между микросервисами, когда важна производительность. GraphQL даёт максимальную гибкость в запросах данных, позволяя получать только то, что нужно, и оптимизируя взаимодействие между клиентом и сервером. Короче, как обычно всё зависит от контекста. Так что вникай в контекст и включай голову. Опять думать придётся(((
🔥 - мне REST больше всего по душе
🌭 - gRPC one love
🍌 - юзаю graphQL и не стесняюсь этого!
Инженеры по всему миру навыдумывали всяких технологий, что башка кругом идёт, когда пытаешься во всём этом многообразии разобраться. Надо тебе намутить общение между сервисами - так одни говорят REST API юзай, другие крутят пальцем у виска и втюхивают свой gRPC, а кто-то сидит в уголке и натирает до блеска малоизвестный GraphQL. Ну и кого слушать?
Чаще всего технологии появляются, чтобы решить какую-то проблему, которую другие технологии или не решают, или решают фигово. Осталось понять, когда какую технологию применять, и будет нам счастье. Сейчас глянем на примерах, когда лучше юзать REST, когда gRPC, а когда и GraphQL можно расчехлить.
1. REST
Это как швейцарский нож в мире API. Он идеально подходит, когда вам нужно общаться с фронтендом. REST работает через HTTP/1.1, и браузеры отлично поддерживают этот протокол. JSON, который чаще всего используется в REST, легко обрабатывается на фронте, да и все к нему привыкли.
Есть у тебя магаз, где ты свои огурцы с кабачками продаешь. Заходишь ты на сайт магаза, и фронтенд запрашивает информацию о товарах с бэкенда. REST здесь нормас так ляжет. Ещё ж кайфово, если ребятки rest full поддержат, чисто по http методам будет ясно что делает та или иная ручка. Видишь patch метод и сразу всё ясно про это ваше обновление.
Несмотря на то, что JSON не самый лёгкий по весу формат и HTTP/1.1 не самый быстрый протокол, REST остаётся удобным и универсальным решением для большинства веб-приложений.
2. gRPC
А вот если ты вписался в мир микросервисов, то я тебе конечно соболезную, но надо как-то с этим жить. Запрос идёт с фронтенда, и чтобы собрать ответ, нам надо слазать в пяток микросервисов. Скорость тут уже начинает ролять сильнее. Надо мутить быстрый и эффективный способ обмениваться данными.
Тут-то и выходит на авансцену gRPC. Во-первых, он работает через HTTP/2, что уже делает его быстрее, так как умные ребята серьезно потюнили этот протокол с версии 1.1. Во-вторых, gRPC использует бинарный формат данных Protobuf, что уменьшает размер передаваемой информации. А коль сообщенька весит меньше, значит и летит по сети быстрее.
gRPC отлично подходит для взаимодействия между микросервисами, когда скорость и эффективность имеют решающее значение. Правда, чтоб настроить инфраструктуру для работы gRPC нужно побольше попотеть, но если сервисов много и вы завтра не планируете закрывать контору, то кажется игра стоит свеч.
3. GraphQL
Решил ты сделать магаз с кучей фильтров, где можно по-всякому вертеть, какие данные отображать при поиске, а какие нет. Не будешь же ты каждый раз получать с бекенда все данные, а фильтровать их уже на фронте. Это шляпа какая-то, которая забьет тебе сеть. Надо быть хитрее и запрашивать только то, что действительно нужно.
GraphQL — это как SQL для API: вместо того, чтобы получать фиксированный набор данных, как принято в контрактах REST или gRPC, ты можешь запросить ровно то, что нужно. Это снижает нагрузку на сеть и ускоряет загрузку данных, особенно когда речь идёт о сложных и динамичных запросах.
Итого
REST — проверенный годами варик, особенно для взаимодействия между фронтендом и бэкендом. gRPC идеально подходит для быстрого и эффективного взаимодействия между микросервисами, когда важна производительность. GraphQL даёт максимальную гибкость в запросах данных, позволяя получать только то, что нужно, и оптимизируя взаимодействие между клиентом и сервером. Короче, как обычно всё зависит от контекста. Так что вникай в контекст и включай голову. Опять думать придётся(((
🔥 - мне REST больше всего по душе
🌭 - gRPC one love
🍌 - юзаю graphQL и не стесняюсь этого!