@graphql_ru
GraphQL — русскоговорящее сообщество

Общаемся на темы, посвященные GraphQL и опыту его использования. Проблемы. Новости. Решения. Вам могут быть полезны: @apollo_ru, @react_js, @vuejs_ru Рекомендуем сразу отключить уведомления, чтобы пребывание в чате было полезным и комфортным.

352 members

Архив канала @graphql_ru 22 января 2018 г.

06:58:36 ДП
User 481349
Всем привет. Подскажите, чем GraphQL лучше redux + some rest middleware ?
06:58:44 ДП
User 481349
@playra ^
11:58:05 ДП
User 321317845
@olebedev а чем SQL лучше JSON?
11:58:21 ДП
User 321317845
кажется, ты пытаешься сравнить несравнимое)
11:58:45 ДП
User 228403837
User 481349
Всем привет. Подскажите, чем GraphQL лучше redux + some rest middleware ?
они лучше все вместе)
11:59:03 ДП
User 481349
Я про аполло в частности
11:59:03 ДП
User 228403837
graphql - идеально для композиции данных с сервера, rest мидлваря для всего остального
11:59:18 ДП
User 481349
Не про сам язык запросов
11:59:26 ДП
User 228403837
User 481349
Я про аполло в частности
а вот это я хз, меня аполло бесит
11:59:33 ДП
User 228403837
не люблю комбайны
12:00:26 ПП
User 481349
Мне тоже показалось что не нужно так много наворотов
12:00:38 ПП
User 91770096
граф - просто замена ресту, стандарт который решил проблемы которые были в ресте
12:00:52 ПП
User 228403837
User 91770096
граф - просто замена ресту, стандарт который решил проблемы которые были в ресте
это не замена а дополнение)
12:00:55 ПП
User 481349
Я про аполло, сорри
12:01:11 ПП
User 228403837
User 91770096
граф - просто замена ресту, стандарт который решил проблемы которые были в ресте
у тебя так и так небыло реста)
12:01:21 ПП
User 91770096
что значит дополнение? Почему не было?
12:02:31 ПП
User 228403837
User 91770096
что значит дополнение? Почему не было?
нет hateoas - нет реста. А нет гипертекста - нет hateoas. А для мобильной приложеньки или SPA тебе json нужен а не гипертект.
12:02:40 ПП
User 91770096
User 481349
Я про аполло, сорри
если ты используешь графкюэль - то будет сложно эффективно управлять данными без спец либ. Чисто редакс - геморно
12:02:51 ПП
User 228403837
User 91770096
если ты используешь графкюэль - то будет сложно эффективно управлять данными без спец либ. Чисто редакс - геморно
почему?
12:02:55 ПП
User 91770096
если только не совсем примитивное приложение где нужно сделать один запрос
12:03:19 ПП
User 228403837
User 91770096
если только не совсем примитивное приложение где нужно сделать один запрос
то есть это типа кастыли для того что бы с мутаторами не так геморно было? или че?
12:04:22 ПП
User 91770096
это либа упрощающая жизнь
12:04:30 ПП
User 228403837
User 91770096
что значит дополнение? Почему не было?
дополнение потому что полностью не избавляет тебя от необходимости лепить http api (логин, загрузка файлов, много чего еще, persisted queries)
12:05:05 ПП
User 228403837
я вижу graphql как прекрасное дополнение, которое позволяет решить одну конкретную проблему - композиция данных под клиента и контроль
12:05:24 ПП
User 228403837
а так все тоже самое можно было и в json api делать просто в разы менее удобно
12:06:06 ПП
User 228403837
а булшит с заменой ресту - это как flux замена mvc. чисто ребрентинг http rpc который все и так юзают но теперь хоть не будут называть это rest-ом)
12:08:55 ПП
User 306987219
Про настоящий рест все говорят, но никто его не видел %)
12:09:16 ПП
User 228403837
User 306987219
Про настоящий рест все говорят, но никто его не видел %)
ты видишь его каждый раз когда заходишь на web-сайтик обычный
12:09:37 ПП
User 228403837
когда у тебя сервер выплевывает html и ты ходишь по ссылочкам и постишь формочки
12:09:46 ПП
User 228403837
вот это - rest. А все остальное - чисто json rpc
12:10:23 ПП
User 91770096
это все не важно
12:10:28 ПП
User 306987219
Ну о том и речь, что когда доходит до API, то про чистый рест остается только говорить
12:10:56 ПП
User 228403837
User 306987219
Ну о том и речь, что когда доходит до API, то про чистый рест остается только говорить
потому что это вопервых невозможно (ну как, в теории.. но дико сложно) да и никому не нужно)
12:10:56 ПП
User 91770096
важно то что принципы написания АПИ были одни, стали с графом - другие
12:11:06 ПП
User 228403837
User 91770096
важно то что принципы написания АПИ были одни, стали с графом - другие
нет, тоже заблуждение
12:11:10 ПП
User 306987219
И давать в пример сайтики, где всего пара простых интентов описываются гиперссылками, а чуть более сложное взаимодействие уже через hateoas не так-то просто описать
12:11:13 ПП
User 228403837
принципы остались абсолютно те ми же
12:11:46 ПП
User 306987219
Просто эти рассуждения про настоящий рест - набили оскомину немного %)
12:12:05 ПП
User 228403837
User 306987219
И давать в пример сайтики, где всего пара простых интентов описываются гиперссылками, а чуть более сложное взаимодействие уже через hateoas не так-то просто описать
у тебя есть code-on-demand что бы делат ьчто-то сложнее)
12:12:19 ПП
User 228403837
например что бы динамически подправлять экшен
12:12:26 ПП
User 91770096
User 228403837
принципы остались абсолютно те ми же
ну все тогда, граф не нужен
12:12:31 ПП
User 91770096
ничего не поменялось
12:12:35 ПП
User 228403837
User 91770096
ну все тогда, граф не нужен
у тебя очень странные выводы)
12:12:44 ПП
User 228403837
абсолютизм какой-то
12:12:50 ПП
User 306987219
Это если один сервер и один клиент (web). Грабли с code-on-demand начинаются, когда у вас много клиентов %)
12:12:52 ПП
User 228403837
либо эта штука заменяет и все делает новым, либо она не нужна
12:13:26 ПП
User 228403837
User 306987219
Это если один сервер и один клиент (web). Грабли с code-on-demand начинаются, когда у вас много клиентов %)
ну и еще - у тебя должен быть очень умный клиент. Фактически - браузер + пользователь. Это никому сейчас не нужно
12:14:08 ПП
User 306987219
Ага, для "полноценного" реста нужен в первую очередь полноценный клиент
12:14:13 ПП
User 228403837
User 91770096
ничего не поменялось
ты мог и раньше делать запросы вида:

/api?fields={foo,bar{baz}}
12:14:14 ПП
User 91770096
я сужу с практической точки зрения
12:14:25 ПП
User 228403837
просто с graphql это в разы удобнее
12:15:07 ПП
User 306987219
С практической точки зрения graphql заменил те json api, которые все именовали rest'ом. А у нас тут просто терминологический мини-холивар, правда похоже об обном и том же говорим %)
12:15:11 ПП
User 228403837
фактически идея как бы не новая, просто получила качественное исполнение и отказ от устоявшихся догм в духе "у каждого ресурса должен быть URI"
12:15:42 ПП
User 228403837
всеравно все делают все через жопу, а так хоть меньше кастылей будет
12:16:01 ПП
User 228403837
а вот то как сделаны мутаторы в graphql лично мне не очень нравится...
12:16:13 ПП
User 228403837
хотя все лучше чем ничего)
12:16:29 ПП
User 306987219
В том и проблема, что REST как концепция и был академической утопией, а все делают так, как им нежно
12:17:10 ПП
User 228403837
User 306987219
В том и проблема, что REST как концепция и был академической утопией, а все делают так, как им нежно
небыл он утопией, это диссертация которая описывала идею, "почему мы сделали web именно так"
12:17:24 ПП
User 306987219
филдинг не делал веб
12:17:38 ПП
User 228403837
User 306987219
филдинг не делал веб
он делал диссертацию)
12:17:50 ПП
User 306987219
сначала его сделали на практике другие, а он попытался описать что они сделали академическим языком
12:17:55 ПП
User 228403837
обоснование для выбора подходов использующихся в семействе стандартов про http 1.1
12:18:03 ПП
User 228403837
User 306987219
сначала его сделали на практике другие, а он попытался описать что они сделали академическим языком
и получить PhD
12:18:07 ПП
12:18:39 ПП
User 306987219
это описание того, что было постфактум %) Но почему-то решили, что это академическое описание подойдет для любых веб-API
12:18:39 ПП
User 228403837
он как бы учавствовал в формировании спецификаций) так что он в каком-то смысле делал web)
12:18:55 ПП
User 228403837
User 306987219
это описание того, что было постфактум %) Но почему-то решили, что это академическое описание подойдет для любых веб-API
проблема в том что он не про апи писал)
12:19:34 ПП
User 306987219
проблема в том, что он не стал особенно никого разубеждать, когда все попытались его REST на API натягивать %)
12:19:36 ПП
User 228403837
https://www.drupalwatchdog.com/sites/default/files/images/web/4.1-RESTfulness-tweet.png
drupalwatchdog.com/sites/default/files/images/web/4.1-RESTfulness-tweet.png
12:19:48 ПП
User 228403837
User 306987219
проблема в том, что он не стал особенно никого разубеждать, когда все попытались его REST на API натягивать %)
это да
12:20:42 ПП
User 306987219
я до сих пор подписан на чуваков, которые всё еще пытаются hateoas прикруть к веб-API (ну и конечно же сделать его единым стандартом)
12:20:54 ПП
User 306987219
good luck with that
12:21:26 ПП
User 228403837
я пол года потратил на эту чушь... загонялся, читал статьи доклады, общался с людьми и все для того что бы понять что это мертворожденная концепция
12:21:33 ПП
User 306987219
такая же фигня %)
12:21:46 ПП
User 228403837
json rpc + graphql и норм
12:21:54 ПП
User 306987219
потому тут и висим
12:21:54 ПП
User 228403837
главное что бы была возможность API одной схемой описать
12:34:50 ПП
User 144022504
User 481349
Всем привет. Подскажите, чем GraphQL лучше redux + some rest middleware ?
Изучаю как раз эту тему сейчас очень плотно. Пишу статью и буду благодарен критике.

Там, где данные нужно передать дальше чем на один компонент, лучше всего использовать не родной 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 знает?
12:40:13 ПП
User 306987219
Живем без apollo, relay и redux. Немного утомляет, что придумали чудесный концепт для упрощения всего стэка (graphql), который должен быть уменьшить количество слоев, а потом поверх этого все равно нагородили еще кучу слоев, при этом потеряв всю простоту и элегантность решения
12:43:03 ПП
User 144022504
User 306987219
Живем без apollo, relay и redux. Немного утомляет, что придумали чудесный концепт для упрощения всего стэка (graphql), который должен быть уменьшить количество слоев, а потом поверх этого все равно нагородили еще кучу слоев, при этом потеряв всю простоту и элегантность решения
На бэке видимо живете?
12:43:28 ПП
User 306987219
Ну почему, и на клиенте. Суть же в том, чтобы весь стэк упростить - и бэк и фронт
12:44:40 ПП
User 144022504
User 306987219
Ну почему, и на клиенте. Суть же в том, чтобы весь стэк упростить - и бэк и фронт
React, Angular?
12:45:26 ПП
User 306987219
Вообще не хватает конечно для фронтенда простого клиента, который был бы чуть сложнее чем adrenaline и ему подобные, но не требовал бы build-step'а как relay или apollo. И с которого (при большой нужде) можно было бы переехать
12:45:29 ПП
12:46:17 ПП
User 228403837
User 306987219
Живем без apollo, relay и redux. Немного утомляет, что придумали чудесный концепт для упрощения всего стэка (graphql), который должен быть уменьшить количество слоев, а потом поверх этого все равно нагородили еще кучу слоев, при этом потеряв всю простоту и элегантность решения
ну redux всеравно удобно, а вот релеи всякие - сомнительны, хотя кому-нибудь может и удобно
12:48:47 ПП
User 306987219
Напрягает, что и relay и apollo в итоге занимаются нормацлизацией данных на клиенте, а потом заново собирают в нужную форму. По-хорошему это должно быть на уровне сервера. А раз в graphql такого нет, значит эти клиенты не используют его сильные стороны, а используют слабые
12:48:54 ПП
User 144022504
User 306987219
Вообще не хватает конечно для фронтенда простого клиента, который был бы чуть сложнее чем adrenaline и ему подобные, но не требовал бы build-step'а как relay или apollo. И с которого (при большой нужде) можно было бы переехать
Вот и я сейчас лоялен Apollo не с пустого места. Инструмент, с которым писать код стало в разы меньше. Да и перспектива работать не только по React, а также с iOS, Android. Интрумент кроссплатформеный.
12:50:32 ПП
User 144022504
User 228403837
ну redux всеравно удобно, а вот релеи всякие - сомнительны, хотя кому-нибудь может и удобно
12:51:08 ПП
User 306987219
Да, это понятно, логичный выбор. Просто сам подход к graphql на frontend'е сейчас строится вокруг той части, где graphql слаб - нормализации данных
12:51:46 ПП
User 306987219
Вероятнее всего на самом сервере в итоге что-то с этим будут делать
12:52:06 ПП
User 144022504
User 306987219
Да, это понятно, логичный выбор. Просто сам подход к graphql на frontend'е сейчас строится вокруг той части, где graphql слаб - нормализации данных
где почитать годную статью по нормализации?
12:52:17 ПП
User 306987219
Но до тех пор опять приличное количество сложности на клиенте остается
12:52:46 ПП
User 228403837
User 144022504
Вот и я сейчас лоялен Apollo не с пустого места. Инструмент, с которым писать код стало в разы меньше. Да и перспектива работать не только по React, а также с iOS, Android. Интрумент кроссплатформеный.
я так и вижу как андройдщики посылают меня далеко и надолго потому что я предлагаю заменить их любимый ретрофит на какую-то стремную штуку
12:55:12 ПП
User 144022504
User 228403837
я так и вижу как андройдщики посылают меня далеко и надолго потому что я предлагаю заменить их любимый ретрофит на какую-то стремную штуку
как обычно вырасит только то, что совершеней и для людей.
12:58:34 ПП
User 228403837
User 144022504
как обычно вырасит только то, что совершеней и для людей.
привычнее* я бы сказал)
12:58:56 ПП
User 228403837
ну там есть нюансы короч, я пока не настолько глубоко погружался в аполло что бы накидывать о недостатках/ненужности каких-то его частей
12:59:22 ПП
User 228403837
2-ую версию смотрел на уровне чейнджлога
01:00:28 ПП
User 281898493
Ребят, подскажите, существуют какие-нибдуь статьи по apollo на русском языке?
01:01:51 ПП
User 281898493
шел 3 день как я разбираюсь со стеком react/apollo, мозг кипит, понимания нет)
01:03:53 ПП
User 306987219
По-моему пока не переводили по аполло2.0 доки
01:06:17 ПП
User 306987219
А что не понятно? Может подскажем %)
01:12:52 ПП
User 144022504
User 281898493
Ребят, подскажите, существуют какие-нибдуь статьи по apollo на русском языке?
На русском вряд ли, совсем не довно появилась вторая версия. На англиском хороший туториал для Apollo 1.x здесь
https://github.com/react-native-village/react-native-video-tutorial
github.com/react-native-village/react-native-video-tutorial
react-native-video-tutorial - Video tutorials on the library react-native
01:19:46 ПП
User 281898493
Вопросы думаю достаточно нубские, и, я подозреваю, связанны, отчасти, в целом с построением архитектуры приложения)

С получением данных посредством HOC я разобрался, но что, если другой компонент (лежащий на другом уровне) должен провоцировать обновление этих данных?
01:24:39 ПП
User 281898493
с redux это, вроде, тривиальная задача, но во 2 версии его выпилили
01:25:45 ПП
User 281898493
или я что-то не догоняю)
01:26:16 ПП
User 306987219
Так у них же глобальный кэш вроде. Если другой компонент обновит данные - они везде обновятся
01:26:30 ПП
User 306987219
Хотя я давно аполло не смотрел, но концептуально все должно было остаться также
01:28:09 ПП
User 281898493
т.е явно не нужно указывать что хранить?
01:29:21 ПП
User 306987219
как я понимаю нет, но лучше пусть ответит тот, кто работал с последним аполло %)
01:30:06 ПП
User 281898493
и сейчас пробовал через compose выполнить на одном компоненте 2 запроса — вижу что данные с обоих запросов приходят, но доступен только последний