В общем, я бы рекомендовал свести количество языков в решении к минимуму, когда вы работаете в команде. Главным образом потому, что вы сводите к минимуму вероятность того, что тот, кто представил язык, будет единственным, кто обновляет сервис. Не поймите меня неправильно, Go — отличный язык, и я полностью поддерживаю его изучение.
Я изо всех сил пытаюсь увидеть отдельную цель второго сервиса во вступительном посте. В какой-то момент вам все еще нужно иметь средства службы Go для связи со службой C#, поэтому ограничение Go только частью веб-сервера усложняет работу, не получая при этом особых преимуществ.
Теперь, если бы у вас был слой GraphQL, реализованный в Go, который взаимодействовал бы с вашей службой C#, тогда я вижу кое-что, на чем вы могли бы основываться... особенно в инфраструктуре на основе микросервисов. GraphQL предназначен для обработки ваших данных как графика, поэтому вы можете запрашивать только те записи, которые вам нужны, и получать только те данные, которые хотите отобразить. Это немного больше, чем добавление пары обработчиков к встроенному веб-сервису, который вы получаете с минимальными усилиями на C#.
Если это личный проект и у вас есть личные причины что-то делать, то дерзайте. Но если вы работаете в команде, рассмотрите стоимость добавления новой технологии, включая долгосрочное обслуживание. Насколько вашей команде нужно научиться исправлять ошибки или добавлять новые функции? Если в нужной вам языковой платформе нет чего-то неотъемлемого, согласованность между сервисами будет легче поддерживать. В этом случае у вас есть зависимость от языка из-за вашего проприетарного продукта, который вы хотите интегрировать, но часто командам может потребоваться интегрировать службы Python из-за возможностей машинного обучения или обработки естественного языка, которые разработаны на этой платформе.
Рекомендую посмотреть эти видео для лучшего погружения в вопрос: