Я бы посоветовал подумать о проблеме по-другому.
У вас есть пара проблем, с которыми вы сталкиваетесь, если я правильно понимаю:
- Выо том, чтобы впервые представить внутренние API - или что-то похожее на ваши внутренние API - внешним сторонам
- Вы обеспокоены влиянием одного на другого (например, DDoS на внешний, приводящий ваши внутренние процессы костановка)
- Вы не знаете, как лучше всего спроектировать GraphQL для совместного использования аналогичных функций в связанных, но потенциально различных API
Это хорошее резюме?
IЯ бы посоветовал вам взглянуть на API-шлюз для защиты вашего внешнего API, независимо от того, что вы выбрали в своих реализациях API.В любом случае вам нужна аутентификация и авторизация.
Шлюз API также дает вам некоторый контроль над тем, как маршрутизировать вызовы API.Если вы решили использовать идентичные API-интерфейсы для внутренних и внешних интерфейсов, у вас может быть пул этих реализаций API для избыточности, и только шлюз API сможет балансировать нагрузку между их подмножеством.Это означало бы, что даже если бы они были беспристрастными, у вас должны быть зарезервированные возможности для обработки внутренних запросов.(Если нагрузка действительно на ваши внутренние источники данных, то это совсем другая проблема!)
Если вы ищете способ создания отдельных API-интерфейсов GraphQL, которые работают полностью независимо, но повторно используют функциональность, вы можете посмотреть на что-токак Apollo , чтобы сделать это, но я не эксперт по GraphQL.
Как я уже упоминал выше, однако, ваше беспокойство об одной точке отказа, вероятно, должно учитывать вашу внутреннюю часть (с).Независимо от того, как вы разделяете свои шлюзы, прокси-серверы, конечные точки GraphQL и т. Д., Если они все используют одну и ту же базу данных, то, вероятно, катастрофа может привести к сбоям ваших внутренних и внешних API одновременно.
Надеюсь, что это даст вам пищу для размышлений.