Comments 8
Я не вижу никаких преимуществ перед Orleans. Ошибаюсь?
ну WCF мертв да здравствует wcf
Ну и строгая типизация — это не совсем про REST. Не исключаю, что я не умею его готовить, но плясать от контракта описанного в protobuf приятнее.
Как работать с большими контрактами, с идеологией proto-first не очень понятно, точнее — не очень удобно, потому что автогенерация proto-файлов пока еще не возможна.
Так на то и proto-first, как вы его назвали, что proto файлы не генерятся, а пишутся руками. Это вызывает небольшое отторжение, но:
- Это только первое время, потом привыкаешь
- Следуя заветам дядюшки Боба — помогает охранять границы (контракты).
Вообще говоря, protobuf довольно неплох для описания сообщений, и помогает от простреленной ноги. Не хватает двух вещей (на мой вкус: generic классов и нормального наследования. И если с последним я готов мириться для защиты ног, то без generic бывает очень грустно.
Из плюсов grpc — просмотрите на streaming, это просто космическая штука для передачи IAsyncEnumerable или IObservable.
Ну и сериализация быстрее. Она даже быстрее чем бинарная при помощи BinaryFormatter, где-то в 1,5 раза. В некоторых случаях наверно даже до 10 раз! Я даже думаю затащить кэширование в редисе на использование протобуфов.
На работе будет проблематично слезть с хорошо работающего инструмента, который удобен и разработчикам и тестировщикам. Больший эффект даст переход на HTTP2.
Для Redis всегда использовал msgpack.org.
В конечном счете, с оптимизациями, дойдете до того, что и Redis будет медленным, т.к у него не бинарный протокол
Ну, тогда встанет вопрос — а надо ли пилить свой редис с бинарями и хай-перфомансом) бизнес логика и сетевые задержки могут сожрать эти оптимизации и не подаваться.
А насчёт http/2 — без него grpc вообще никак, так что по-любому перелезать на него. Мне повезло, у меня есть возможность использовать grpc и на работе, и таки я этому рад)
Interprocess communication с использованием GRPC