Comments 19
если 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 и тогда да
Да и для такого в JS есть class-transformer и class-validator, чтобы не выстрелить себе в ногу
в то время другая боится резких обновлений, что строчка получения поля может превратиться в что-то в роде
resp?.body?[i]?.creds?.card?.numberТак у protobuf все поля тоже концептуально Nullable — получится такая же толпа элвисов
Очень интересно. Вероятно, мне предстоит задача отрисовки большого количесвта данных (~100 MB за раз) на канвасе. Данные, естественно, хочется в бинарном виде передавать. Думал про gRPC, но конкретно к задаче пока не приступал. Ваша статья заставляет задуматься....
Пробовали в проекте этот ваш gRPC. Куча проблем с невероятно жирными зависимостями. По итогу заменили на HTTP/3 + flatbuffers(они же с gRPC юзались. В целом ничего не потеряли, а зависимостей в проекте стало сильно меньше.
использовали для сервис-сервис? или браузер тут как-то участвует? если бек-бек, то тогда немного другая история и хороший повод для статьи)
к сожалению, с браузером flatbuffers несильно бы помог, ограничения браузера те же
У нас просто игра которая шлёт всякую статистику на бэк. Надо было просто кинуть в бэк flatbuffer и даже какой то ответ не нужен был. По итогу отказались от решения так как оно начало доставлять проблемы в очень неожиданном месте. Потребовалось обновить библиотеку которая была в зависимостях у gRPC и после обновления понеслись крэши игры. Мы конечно потратили пару недель на поиск проблемы но по итогу решили что HTTP/3 клиент реализованный поверх libcurl будет надежней ибо у нас уже была готова реализация и она оказалась проще, понятней и тоньше. Самое главное она не тащила за собой absel который в нашем случае доставлял проблемы.
Используем grpc-web и никаких проблем. Чтобы обмениваться json данными с беком, его за глаза. Даже серверные стримы работают нормально (минус websocket). То что там под капотом http1.1 (на самом деле нет, там тот же http2.0, только к специфичным штучкам доступа нет) вообще пофигу.
Да, надо ставить прокси (envoy) сайдкаром к сервису бекэнда или включать поддержку (dotnet и rust) в самом проекте. Но это мелочи на фоне секаса с поддержанием контрактов.
Почему на фронте нет GRPC?