Где хранить прото-файлы, которые используются в проектах?

Я бы посоветовал хранить .proto файлы в отдельном проекте. Это контракт между двумя вашими проектами, и они не обязательно «принадлежат» одному из них. Хранение их в отдельном проекте обеспечивает нейтральную основу для обоих участников проекта для согласования изменений в файлах - например, посредством процесса запроса на вытягивание / слияние, когда участники обоих проектов могут выступать в качестве рецензентов.

Что касается генерации кода из прото-файлов, я бы, вероятно, сделал это в проектах, которые в них нуждаются. Таким образом, в вашем случае проект C будет содержать только .proto файлы, а проекты A и B извлекут .proto файлы и сгенерируют код, который им нужен. Я чувствую, что так и должно быть, поскольку именно проекты A и B используют сгенерированный protobuf код. Если бы код был сгенерирован в проекте C, тогда проектам A и B все равно пришлось бы вытаскивать сгенерированный код, чтобы иметь возможность его использовать, а поскольку проект C технически отделен от A и B, было бы неочевидно, какие языки должны быть сгенерированы - все? Только 2, что нужно?

Создавая проект C, вы создаете место, которое потенциально может содержать больше .proto файлов для других проектов. Думая о будущем, у вас может быть много проектов с общими базовыми типами сообщений. Для управления архитектурой со многими взаимосвязанными проектами имеет смысл попытаться объединить определения сообщений, и это было бы сложно / невозможно, если бы каждый проект поддерживал свои собственные определения, даже хуже (как вы говорите), если есть дублирующиеся копии. Хранение их в одном месте позволяет новым проектам подбирать существующие определения и расширять их (в рамках эволюционных принципов), а также позволяет более строго управлять и поддерживать набор определений, например набор опытных рецензентов, которые следят за тем, чтобы все было сделано последовательно и разумно - будь то с точки зрения моделирования, размещения имен или управления версиями.

Я предложу небольшое отклонение от отличного ответа @JGC. См. https://www.bugsnag.com/blog/libraries-for-grpc-services для получения более подробной информации (для сути подхода, а не для обязательного сравнения).

Когда вы помещаете свои прото-файлы в отдельный репозиторий, этот самый репозиторий также может генерировать клиентский код. Например, с клиентом в Golang сгенерированный код (который также будет Golang) можно импортировать, даже если он находится в отдельном репозитории. Это означает, что проект a и / или b может легко импортировать этот сгенерированный код из проекта c.

Может случиться так, что для разных языков импорт сгенерированного клиентского кода из проекта c может потребовать большего, чем просто наличие файла в репо. Но я могу представить, что в проекте c могут быть настроены разные подходы ci / cd, позволяющие публиковать правильные пакеты.

Представьте, что один прототип проекта c используется для создания файла go, который можно импортировать в другой проект go (проект a). И проект c также публикует сгенерированный файл JavaScript (или что-то еще) в реестре npm. Я еще не знаю, как работает dart, но представьте, что он также сгенерировал клиентский код для вашего приложения flutter, и вы также взяли его из проекта c.

Приложение для iOS работает с ошибками, но найдите вопрос под названием

как поддерживать прото файлы

За хорошее объяснение