Благодарю за развернутый комментарий! Вы во многом правы, и здесь классический архитектурный вопрос: переходить точечно или полностью. Я не стал захламлять статью требованиями заказчика и рассказом, какое у нас страшное легаси было)
Частичный переход создал бы зоопарк из REST + WCF + gRPC, который поддерживать ещё тяжелее. Да и методов у нас было не то чтобы много, может быть, до 10 штук, не помню уже, суть в моделях, которые там применялись.
По поводу «критичных API без сложных типов» - в этом тоже есть доля правды, если у вас в проекте такие есть, то дерзайте первым делом переносить их. Но в legacy-коде, который мы переносили, модели уже были сформированы с наследованием, дженериками и decimal - переписывать бизнес-логику попутно с переходом на gRPC было бы ещё рискованнее.
Да, в статье есть информация про эту библиотеку и почему её не использовали
Благодарю за развернутый комментарий! Вы во многом правы, и здесь классический архитектурный вопрос: переходить точечно или полностью. Я не стал захламлять статью требованиями заказчика и рассказом, какое у нас страшное легаси было)
Частичный переход создал бы зоопарк из REST + WCF + gRPC, который поддерживать ещё тяжелее. Да и методов у нас было не то чтобы много, может быть, до 10 штук, не помню уже, суть в моделях, которые там применялись.
По поводу «критичных API без сложных типов» - в этом тоже есть доля правды, если у вас в проекте такие есть, то дерзайте первым делом переносить их. Но в legacy-коде, который мы переносили, модели уже были сформированы с наследованием, дженериками и decimal - переписывать бизнес-логику попутно с переходом на gRPC было бы ещё рискованнее.