Обновить

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

если gRPC решает эти проблемы, почему мы не используем его на фронте?

так он почти ничего не решает, а местами наоборот проблем приносит

проблемы с gRPC естественно есть. Я больше рассмотрел это через призму backend разработки, где он ну супер хорош

буквально хотелось взять этот прото-файлик общий и просто везде использовать, в концепции будто бы кайф, не?

ну и далее я в статье в принципе описал, какие трбаблы и альтернативы

resp?.body?[i]?.creds?.card?.number

Так в protobuf тоже все поля опциональные by design.

не совсем
в proto3 точно (за остальные не скажу) используются zero-value
ист: https://protobuf.dev/programming-guides/proto3/#default

if the encoded message bytes do not contain a particular field, accessing that field in the parsed object returns the default value for that field

сами байты данных опциональны, но они от этого не становятся null/undefined

как раз для такого есть optional и тогда да

в то время другая боится резких обновлений, что строчка получения поля может превратиться в что-то в роде

resp?.body?[i]?.creds?.card?.number

Так у protobuf все поля тоже концептуально Nullable — получится такая же толпа элвисов

Очень интересно. Вероятно, мне предстоит задача отрисовки большого количесвта данных (~100 MB за раз) на канвасе. Данные, естественно, хочется в бинарном виде передавать. Думал про gRPC, но конкретно к задаче пока не приступал. Ваша статья заставляет задуматься....

спасибо за ос! крайне приятно знать, что кому-то мог помочь или натолкнуть на мысли)

Пробовали в проекте этот ваш gRPC. Куча проблем с невероятно жирными зависимостями. По итогу заменили на HTTP/3 + flatbuffers(они же с gRPC юзались. В целом ничего не потеряли, а зависимостей в проекте стало сильно меньше.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации