Это скорее всего про returnPartialData

@matochu чет я не сразу понял что такое watchQuery. Это запрос с разу с подпиской ? где в коллбеке уже указываешь действие ?

я подсмотрел в доках хасуры - ангулара :)

Спасибо  👍

Да, он сразу подписывается на изменения в кеше. В Angular все через observable, поэтому там просто используется вот этот метод из core

Закончил слайды к своему докладу на HolyJS 24 июня: Оборачиваем существующее REST API в GraphQL (методология за 1000000 рублей)

http://bit.ly/rest2graphql

По традиции делюсь слайдами заранее. Чтоб помогли мне с орфографией и опечатками. 🙏

Если есть правки или дополнения – Welcome. 😉

playground в самой презентации? прикольно :)
главное чтобы бэк не рухнул на самом докладе >_<

локально тоже есть

👍

Спасибо за презентацию, очень интересно.
Теперь по ошибкам. Сначала общее замечание. Понимаю, что автор немного "хулиганит" со сленгом, но надо определиться в терминах и единой политике, а то по тексту встрачается "API", "апи" и "АПИ", "GraphQL" и "графкуэль", "ДатаЛоадеры", "дата-лоадеры" и "DataLoader'ы". Павел, представьте, что кто-то в graphql-схеме в одном query напишет "recordId", а в другом "recordNum" 😂
Теперь частности.
1. Я бы 1 000 000 написал (долго считать нули)
3.6. "придётся" (раз начали писать с "ё", надо и продолжать)
3.14. после "сперва" запятая не нужна
3.15. запятая после Domain
3.19. запятая после "теперь" не нужна, "ещё" с ё
3.20. запятая после "ну".
5.3. "Берём" с ё
5.4. "Воссоздаём" с ё
5.6. "даём" с ё
5.9. "сгенерировать этого самый" - несогласованная фраза
6.5. "с возможность редактирования". исправить на "с возможностью"
7.9. "без учёта" с ё
7.10. "дёшево" с ё
8.6. "в нём" с ё
8.7. "а ещё" с ё. Перед "это" тире. "лёгкий" с ё
8.9. "По завершении"
9.2. перед "где" запятая
9.4. "берёт"с ё. После "При этом" запятая
9.8. "черева-то" исправить на "чревато"
10.7. две открывающие и две закрывающие скобочки в 3-м подпункте
10.8. "жёсткие" с ё
10.11 "ещё" с ё
11.2. "Английский - русский - английский" термины некрасиво
11.4. "cоздаёт" c ё
11.5. "В нашем случаем" - исправить на "В нашем случае". Убрать запятую после
11.7. "ещё" с ё
11.11. "те, которые" - вставить запятую
11.16. "ой-как" не нужен дефис. "порой" - вводное слово, запятые с двух сторон
12.3. "Ну, или чтобы" - поставить запятую. Здесь же "максимально возможное"
12.4. Перед "исходя" запятая
12.7. "Берём" с ё... "Создаём" с ё
12.8. "по желанию, " - вставляем запятую
12.9. "черТ его знает," - пропущена буква и запятая
12.12. "добавили", т.к. раньше и позже множественное число "написали", "накостылили"
13.4. нет такого слова "ложим". Есть "кладём"
14.5. Перед "чтобы" запятая
15.5. "её много," с ё и запятая
15.6. "например," с запятой; "для браузеров в основном" я бы заменил на ", в основном, для браузеров" с запятыми.
Вот, как-то так ☺

Шик 👌
Спасибо огромное 🙏

Завтра уже буду вносить правки, сейчас хочу трейсинг прикрутить и спать.

1111 участников. )

А как вы именуете подписки subscription (Суфиксы, префиксы) - если можно пример :)

Приветствую!

Скажите пожалуйста, как написать запрос для такого возвращаемого типа? И валиден ли этот возвращаемый тип?

Возвращаемый тип : [[[lesson]]]

а зачем такая глубокая вложенность?

Кто-нибудь у себя реализовывал https://github.com/APIs-guru/graphql-constraints-spec ?

Почему тут numberValue покрывает и Int и Float? Мы же не можем аргумент сделать union'ом.

Во-первых, это спецификация, а не реализация.

Во-вторых, одна и та же директива может применяться одновременно и к Int, и к Float.

Директива вообще может применяться к String, делать JSON.parse и если на выходе JS number, то дело сделано.

Тут даже приписка есть:

> @numberValue directive is used to describe possible numeric values. Instance is valid if it is a numeric value according to the Serialization Format (e.g. JSON)

В примере вообще custom scalar Integer вместо Int:

type Foo {
  bitMask: Integer @numberValue(
    oneOf: [ 1, 2, 4, 8, 16, 32, 64, 128 ]
  )
}

Понятно что это спека. Вопрос как реализовать такую проверку максимально стандартно.

Если я объявлю директиву directive @numberValue(max: Int) on INPUT_FIELD_DEFINITION то в max не смогу указать 0.1 когда буду применять для Float. Сразу делать @numberValue(max: Float) и надеяться, что проглотит int для полей с int?