внезапно вдруг и ниоткуда редко такие проблемы возникают

да ладно, неужели не бывало что заказчик "немного пересмотрел" концепцию и теперь вот нужно хитровывернутое взаимодействие между фитчами устроить?

На мой взгляд все эти observable в стиле rxjs имеют фундаментальный недостаток - там происходит замыкание переменных к которым нет доступа к извне (кстати с redux-saga то же самое так как там состояние замыкается в генераторах которых нельзя клонировать и сохранить в локалсторадж например).
На первый взгяд кажется удобным когда с этим rxjs демонстрируют пример drag-and-drop когда взяли стрим кликов замапили на mousemove и т.д но потом когда приложение развивается и становится более связанным по фичам оказывается нужно в другой части приложения узнать происходит ли в текущий момент драг.
Без rxjs проблема решается просто - ставим обработчик на mousedown и обновляем переменную isDrag и теперь доступ к этой переменной можно получить в любой другой части приложения.
А с rxjs получается уже нужно как-то связывать эти два стрима вместе потому что состояние было замкнуто в этих стримах. И чем больше будем добавлять фич тем больше нужно будет соединять стримы по всему приложению вместо того чтобы работать с состоянием через переменные

спасибо за ответ! а как по-твоему лучше обрабатывать поступающую информацию?
Допустим, нужно получить данные (о пользователе). С одной стороны можно кинуть запрос средствами effect (хотя тогда, по-идее, вообще не нужен аполло и можно обойтись хоть нативным фетчем), с другой стороны - хуки от apollo. В первом случае нужно больше обработчиков (refetch, optimistic response при необходимости и т.д.). Во втором случае это из коробки, но втягивается бизнес-логика в компоненты.

а в идеале адаптер написать, который от запроса будет создаваться, выдавая наружу апи как у аполло-хуков для реакта

Ну только без аполло внутри

почему нет?

Не нужен

Не слышу аргументов

Какие за?

Кеш батчинг