Т.е. не очередной обзорный доклад - GraphQL, bla-bla-bla, язык запросов, а именно практические советы

Подводные камни какого рода? К примеру, связанные с проектированием схемы/безопасностью/применением (и неприменимостью) самой технологии?

Дайте такое на английском

Ну вот есть такой доклад "Владимир Заец. GraphQL - удобное API или хайп? JS Fest 2018", там есть и про решение некоторых проблем и про безопасность, но это не тот доклад )

Я в этом году делал три доклада, могу сформулировать все известные мне подводные камни, проверим то или не то 🙂

1. N + 1 сложнее обнаружить и обработать потому, что нам (в отличие от REST) нужно понять динамически, какие данные загружать из БД
2. Кэширование в целом и HTTP кэш в частности делать сложно и руками
3. Нет рекурсивных запросов и оператора "выбрать все" (`query { user { * } }`)
4. В некоторых случаях подход "атомарных мутаций" превращается в "четыре мутации одно и то же поле одинаково обновляют"
5. Появляются новая уязвимость "сложный/глубокий запрос"
6. Есть шанс спроектировать схему "как REST", и потом понять, что старые проблемы не решились, а новые прибавились 🙂

А видео докладов есть? )
В целом - да, большая часть из этих вопросов была в докладе

Последняя версия https://www.youtube.com/watch?v=VOvfHyyV5Bg&feature=youtu.be

а предыдущий на Dump?

так точно

“Не надо превращать GraphQL в обертку над базой данных” – ответ на вопрос про то, что стоит ли сразу генерить из моделей или инстроспекции базы свое АПИ.

Отличный ответ 👍

Хороший доклад, и самое главное какие вопросы народ задавал. Это в каком городе было?

Спасибо 🙂Иннополис, IT Nights

const MyComp = () => {
  const {data,loading,error} = useQuery()
  /* обработка loading и error...*/
  return <MyCompFunctional myData={data.query}
}

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

const MyComp = () => {
  const {data,loading,error} = useQuery()
  /* обработка loading и error...*/
  return <MyCompFunctional myData={data.query}
}

Да на самом деле, хотелось вынести логику к примеру валидации мэйла и пароля отдельно

Т.е. провалидовало и отправило запрос на сервер

т.е. речь про мутации и формы с клиентской валидацией?

Да, оно будет валидировать и на клиенте и на сервере

const MyComp = () => {
  const {data,loading,error} = useQuery()
  /* обработка loading и error...*/
  return <MyCompFunctional myData={data.query}
}

не, если тебе такой же запрос сделать нужно? делаешь хук свой, кроторый в папку hooks в текущем скоупе использования, gql файлы таким же образом, если не подходит, можно сделать общую папку с хуками, где разнести их по схемам бека, тогда можно быстро перенести из проекта в проект

Была идея сразу в вынесенной функции работать с кэшем

валидация не задача аполо, задача форм менеджера