Комментарии 9
если gRPC решает эти проблемы, почему мы не используем его на фронте?
так он почти ничего не решает, а местами наоборот проблем приносит
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 юзались. В целом ничего не потеряли, а зависимостей в проекте стало сильно меньше.


Почему на фронте нет GRPC?