думать как сделать все адекватно.
Вопрос - идея сделать сервис гейтвей оркестратор с graphql для фронта и всем межсервисным взаимодействием по grpc нормальная? У нас сейчас все взаимодействие по rest и слишком много связей между ними. Думаю сделать все сервисы максимально простыми, а все логику по сборке данных в один ответ в гейтвей засунуть
Можно хапнуть n+1 на пустом месте, поэтому супер аккуратно придётся писать реализацию гейтвея, но а целом идея рабочая, правда если фронт будет делать запросы уровня - отдай мне все я сам потом разберусь, особого выигрыша от GraphQL не будет, плюс ещё надо по хорошему внедрять cost analysis для graphql запросов
Нормальная, если понимаете подводные камни gRPC. Нетфликс такой подход использует. Только у них это масштабней. Каждый блок в системе закрыт своим graphql-сервисом, за которым скрыты микросервисы этого блока. Общение между ними разными способами: gRPC, rest, graphql, Kafka. А все graphql-гейтвеи расположены за сервисом со схемой-федерацией.
Кажется нет, особенно для MVP, либо MVP давно не MVP. Кажется если нет внешних клиентов цена потенциальных проблем и сложностей того не стоит
Архитектура под задачи рисуется. Важно понимать где будет разворачиваться и под как ую нагрузку рассчитывается
Где можно посмотреть на это?
https://netflixtechblog.com/how-netflix-scales-its-api-with-graphql-federation-part-1-ae3557c187e2
Обсуждают сегодня