EA
Объясните начинающей, если graphql описывает схему, сервер клиент и тд. Но откуда он данные берёт?
Где описывать структуру бд и драйвер подключать? С какими базами работает?
Size: a a a
2019 January 31
OG
graphql это просто формат передачи данных
OG
бд можно юзать любую
OG
или сразу несколько
OG
или вообще вместо бд использовать файл
OG
graphql спецификация передачи данных между клиентом и сервером
OG
тоесть подключать бд и драйвера все как обычно, резолверы просто обращаются к коду который обращается к даным
OG
тут уже как в проекте - но все равно есть слой который отвечает за работу с даными, вот этот код и вызывают в резолверах
U
Записал скринкаст по GraphQL, видео состоит из двух частей, первая теоретическая, вторая - практическая. Описывается GraphQL в целом и процесс создания простого GraphQL сервера на GraphQL Yoga. Все материалы, используемые в скринкасте доступны по ссылке в описании.
https://youtu.be/MJxMBYanmtA
https://youtu.be/MJxMBYanmtA
@tfest здесь всё подробно описано
c
IV
но если бэк gql то redux нахрен не нужен
Как быть тогда с ui-штуками, которые необходимо хранить в сторе?
EA
Если по каким то причинам прям очень очень надо не пользоваться классическими вариантами (стейт, контекст) то appllo-client позволяет создавать свой кастомный кэш (в формате gql). Но даже Дэн Абрамов говорит что Редакс не всем нужен
l
дэна должность обязывает
EA
Это в любом случае правда)
AK
Всем привет.
Насчет авторизации в graphql: мне не нравится идея определения прав в резолверах, как и не нравится использование для этого директив.
Не нравится мне это из-за того, что у меня в проекте уже сейчас 4 роли пользователей, а планируется еще больше. Я не хочу , чтобы незарегистрированный пользователь даже видел в своей схеме запросы/мутации для администратора.
Это усложняет использование песочницы, это приводит к дополнительным затратам при разработке в dev-режиме (схема пользователя весит много, а он public), да и дает внешним силам видеть мою схему.
Моя идея такая - поднимать один сервер для всех, но внутри node.js приложения поднимать несколько apollo-server'ов на закрытых портах.
Каждый apollo-server нужен для определенного типа пользователя, имеет собственную схему.
Public сервер выполняет роль определения типа пользователя и проксирования запроса на нужный apollo-сервер.
Только вот у меня не хватает знаний оценить такое решение с точки зрения используемых ресурсов. Может кто поможет?
Насчет авторизации в graphql: мне не нравится идея определения прав в резолверах, как и не нравится использование для этого директив.
Не нравится мне это из-за того, что у меня в проекте уже сейчас 4 роли пользователей, а планируется еще больше. Я не хочу , чтобы незарегистрированный пользователь даже видел в своей схеме запросы/мутации для администратора.
Это усложняет использование песочницы, это приводит к дополнительным затратам при разработке в dev-режиме (схема пользователя весит много, а он public), да и дает внешним силам видеть мою схему.
Моя идея такая - поднимать один сервер для всех, но внутри node.js приложения поднимать несколько apollo-server'ов на закрытых портах.
Каждый apollo-server нужен для определенного типа пользователя, имеет собственную схему.
Public сервер выполняет роль определения типа пользователя и проксирования запроса на нужный apollo-сервер.
Только вот у меня не хватает знаний оценить такое решение с точки зрения используемых ресурсов. Может кто поможет?
SV
Оки, послушаем, спасибо. Завтра же.
Можно не мучиться и использовать что-то типа Prisma.
IA
Альрнативу друг другу? Ну ясен пень - редакс он для чего хочешь, а react-apollo только для graphql бэка
не совсем. react-apollo можно юзать и без graphql бэка. К примеру apollo-link-state - позволяет резолвить данные на клинете. Или apollo-lisk-rest - позволяет получаеть данные на клиете по rest
SV
Всем привет.
Насчет авторизации в graphql: мне не нравится идея определения прав в резолверах, как и не нравится использование для этого директив.
Не нравится мне это из-за того, что у меня в проекте уже сейчас 4 роли пользователей, а планируется еще больше. Я не хочу , чтобы незарегистрированный пользователь даже видел в своей схеме запросы/мутации для администратора.
Это усложняет использование песочницы, это приводит к дополнительным затратам при разработке в dev-режиме (схема пользователя весит много, а он public), да и дает внешним силам видеть мою схему.
Моя идея такая - поднимать один сервер для всех, но внутри node.js приложения поднимать несколько apollo-server'ов на закрытых портах.
Каждый apollo-server нужен для определенного типа пользователя, имеет собственную схему.
Public сервер выполняет роль определения типа пользователя и проксирования запроса на нужный apollo-сервер.
Только вот у меня не хватает знаний оценить такое решение с точки зрения используемых ресурсов. Может кто поможет?
Насчет авторизации в graphql: мне не нравится идея определения прав в резолверах, как и не нравится использование для этого директив.
Не нравится мне это из-за того, что у меня в проекте уже сейчас 4 роли пользователей, а планируется еще больше. Я не хочу , чтобы незарегистрированный пользователь даже видел в своей схеме запросы/мутации для администратора.
Это усложняет использование песочницы, это приводит к дополнительным затратам при разработке в dev-режиме (схема пользователя весит много, а он public), да и дает внешним силам видеть мою схему.
Моя идея такая - поднимать один сервер для всех, но внутри node.js приложения поднимать несколько apollo-server'ов на закрытых портах.
Каждый apollo-server нужен для определенного типа пользователя, имеет собственную схему.
Public сервер выполняет роль определения типа пользователя и проксирования запроса на нужный apollo-сервер.
Только вот у меня не хватает знаний оценить такое решение с точки зрения используемых ресурсов. Может кто поможет?
Можно несколько схем сделать. И отдавать разный апи.
EA
Ilya я уже про это написал. Мы говорим о данных с сервера. Аполло только для UI это overkill :)