Comments 4
Я могу ошибатся, но во время прочтения статьи закралось чувство, что изначальная цель была неправильной - переписать всё. Ну это как "Отбойный молоток работает быстро и бъёт сильно, выкидываем обычные молотки... Ой, что-то отбойным молотком неудобно дверные косяки подбивать, но вот мы нашли решение сложное и громозкое зато работает ...". Вы же делали вероятно переход из-за преимуществ gRPC - быстродействие (и ряд других), мне кажется было бы проще перевести только самые критические API, а остальное оставить как есть. Вот возьмём банк, есть API платежей супер критично, должно работать быстро, + обратная совместимость, + двунаправленность, а есть API отчётов, API открыть/посмотреть/редактировать/закрыть счёт, API проверки можно ли дать иппотеку/кредит/ссуду/рассрочку, и т.д. что используется на несколько порядков реже и не требует молниеносного ответа. И вот в итоге, могло оказаться, что для самых критичных API и не нужны nullable (да, связка значение и флаг), enum (константы), decimal (передаём деньги в центах), DateTime (используем тики/секунды от 01/01/1900 и т.д.), generic и наследования, и было бы достаточно примитивных типов. Конечно, как я писал - я могу ошибаться, так как не видел вашей системы и её кода, это просто мои рассуждения вслух.
А в целом, статья написана и оформлена отлично, спасибо, что поделились опытом.
Благодарю за развернутый комментарий! Вы во многом правы, и здесь классический архитектурный вопрос: переходить точечно или полностью. Я не стал захламлять статью требованиями заказчика и рассказом, какое у нас страшное легаси было)
Частичный переход создал бы зоопарк из REST + WCF + gRPC, который поддерживать ещё тяжелее. Да и методов у нас было не то чтобы много, может быть, до 10 штук, не помню уже, суть в моделях, которые там применялись.
По поводу «критичных API без сложных типов» - в этом тоже есть доля правды, если у вас в проекте такие есть, то дерзайте первым делом переносить их. Но в legacy-коде, который мы переносили, модели уже были сформированы с наследованием, дженериками и decimal - переписывать бизнес-логику попутно с переходом на gRPC было бы ещё рискованнее.
А ещё есть protobuf-net.Grpc с которым просто пишем датаконтракты на C# а всё развлечение с proto оставляем библиотеке. Единственное отличие от wcf - обязательный Order в DataMember атрибуте.
Подводные камни gRPC