проблема в том что он не про апи писал)

проблема в том, что он не стал особенно никого разубеждать, когда все попытались его REST на API натягивать %)

это да

я до сих пор подписан на чуваков, которые всё еще пытаются hateoas прикруть к веб-API (ну и конечно же сделать его единым стандартом)

good luck with that

я пол года потратил на эту чушь... загонялся, читал статьи доклады, общался с людьми и все для того что бы понять что это мертворожденная концепция

такая же фигня %)

json rpc + graphql и норм

потому тут и висим

главное что бы была возможность API одной схемой описать

Изучаю как раз эту тему сейчас очень плотно. Пишу статью и буду благодарен критике.

Там, где данные нужно передать дальше чем на один компонент, лучше всего использовать не родной React-Native state-management, да и сам Facebook в своей документации ссылается на Redux. Он получил мировое признание не просто так, но так как Redux не для того чтобы работать с сервером, также как Flux, MobX, то этот интрумент разработчика хорош только для управления состоянием и обмена данными по горизонтали, так как работать с сетью он не умеет, а для создании социальной сети это ключевой фактор. Для работы с сервером, обмена данными по вертикали, предполагаю, что может быть fetch() или более профессиональный инструмент как например axios.  В каждой группе разработчиков iOS, Android, React, React Native пишутся запросы к серверу на своем языке. Можете представьте себе, что если бы например iOS разработчик, мог бы написать компонент запроса к серверу, а Android, React, React Native разработчики могли бы его переиспользовать и наоборот, то сколько бы времени, до готовых приложений, высвободила бы эта технология для создания новых приложений и еще, если бы эта технология управляла состоянием мобильного приложения? И таких, основных, технологий на данный момент времени две: Relay и Apollo, если провести бенчмаркинг, то Apollo в приоритете, так как более простой и понятный, отлично задокументированный под все платформы, а также с активным френдли сообществом и более того, разработчик изучая эту технологию, становится специалистом и в бэкэнд разработке, так как работа с базой данных, что на сервере, что на сайте и мобильных платформах, осуществляется через Resolvers, из-за чего грань между front-end и back-end разработкой все заметней стирается, так как по своей сути сервер - это такой же умное железо, как мобильные платформы и десктопы. Подробней об этом можно почитать здесь: https://dev-blog.apollodata.com/the-future-of-state-management-dd410864cae2
О том как можно сократить использование Redux кода с помощью React Apollo можно почитать здесь: https://habrahabr.ru/post/331088/
Apollo 1.x очень круто работат в связке с Redux
Не могу мигрировать на Apollo 2.x так как с Redux знаю как, а без нет, в частности react-navigation интегриованый в redux очень крут, не знаю как заменить.
Может @kureev знает?

Живем без apollo, relay и redux. Немного утомляет, что придумали чудесный концепт для упрощения всего стэка (graphql), который должен быть уменьшить количество слоев, а потом поверх этого все равно нагородили еще кучу слоев, при этом потеряв всю простоту и элегантность решения

На бэке видимо живете?

Ну почему, и на клиенте. Суть же в том, чтобы весь стэк упростить - и бэк и фронт

React, Angular?

Вообще не хватает конечно для фронтенда простого клиента, который был бы чуть сложнее чем adrenaline и ему подобные, но не требовал бы build-step'а как relay или apollo. И с которого (при большой нужде) можно было бы переехать

React

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

Напрягает, что и relay и apollo в итоге занимаются нормацлизацией данных на клиенте, а потом заново собирают в нужную форму. По-хорошему это должно быть на уровне сервера. А раз в graphql такого нет, значит эти клиенты не используют его сильные стороны, а используют слабые