Павел -- лучшие доклады на русском по JS и GraphQL, которые я видел за крайние два года. Респект. По данному докладу есть ряд замечаний. 1. По авторизации -- лучше вернуть токен явно в ответе, чем совать его в куки. Во-первых, куки (даже httpOnly) доступны расширениям (stackoverflow.com/questions/40064016/access-to-cookies-from-chrome-extensions). Во-вторых, правильная установка куков потребует от GraphQL-сервера знать всех своих клиентов (или завязаться всегда на работу на одном origin) В-третьих, это дело клиента, где и как хранить куки и для каких целей (для интернте-банков, например, можно вообще все хранить только в памяти, да, после рефреша страницы надо переавторизовываться, но с другой стороны -- "С -- секьюрити") 2. По дата-лоадерам -- ids.map(id => results.find(item => item.id === id)) имеет сложность в O(n^2), а точнее n^2/2. Это означает, что если (ну так получилось) у нас 10 тыс. ids, то наш цикл будет на 50 млн.итераций. И даже вполне банальная сотня айдишек даст 5 тыс. итераций. Правильно делать так: const resultById = new Map(); results.forEach(r => resultById.set(r.id, r)); return ids.map(id => resultById.get(id)); Такой подход имеет оценку уже в O(n). А если точнее, то 2n (stackoverflow.com/questions/33611509/es6-map-and-set-complexity-v8-implementation). Это значит, что уже для 4-х идешек мы получим такое же быстродействие, а на 5 уже будем быстрее, ну и очевидно, что 200 много быстрее, чем 5000. Кстати, там где поиск идет не по первичному, а по вторничному ключу: (например, надо в автора добавить все его статьи), то ids.map(id => results.filter(item => item.id === id)) уже будут давать чистые n * m (вместо n + m). 3. Снова по дата-лоадерам. Дата лоадеры кешируют ответ от базы, но, т.к. мы в 99% случаев пользуемся ORM/ODM, то кешируется Модель. Это означает, что уникальность дата-лоадера должна быть на уровне request + model, а не request + resolver. Если модели из базы берутся, и по первичному, и по вторичнму ключам, то получается: request + model + keyField. 4. И еще одно про кеши: Никогда! Никогда нельзя опираться на незадокументированные фичи. В данном случае нельзя в качетсве ключей кэша использовать info.fieldNodes, т.к. никто не давал гарантий того, что это поле будет ссылаться на один и тот же объект при разных вызовах резолвера. У нас код резолвера выглядит примерно вот так: fieldResolver = (_, { id }, { dataLoaders }) => dataLoaders(loaderFactory).load(id); где, dataLoaders -- это функция, которая обеспечивает кэширование лоадеров ну уровне одного запроса. loadFactory -- это функция, которая создает конкретный датаЛоадер. Собственно эта функция и используется в качестве ключа для кэша дата-лоадеров. Т.е. пример с дата-лоадерами я бы сделал вот таким: gist.github.com/DScheglov/fd17a6de80b527d977633ace0e3b217f (с поправкой на способ описания graphQL). Я бы так много не писал, если бы, когда пришел на новый проект, не увидел там несколько десятков резолверов, каждый из которых на 99% совпадает с приведенным примером (с поправкой на имена переменных). Т.е. внутри резолвера у нас все: и объявление дата-лоадера, и его кеширование, и запрос данных. И, я думаю, что таких проектов на просторах гитхаба и битбакета неимоверное множество.

Почему не дали ему два часа? Пришлось комкать, а так интересно

Огромное спасибо за доклад. Просто великолепно!

Идея с DataLoaders напоминает один огромный кАстыль в вашем коде продиктованный безысходностью...

Загрузка файлов через graphql просто проклятая тема.

Мне не зашел доклад. Я не понял для кого этот контент. Вначале рассказывается о том что это такое, а уже потом о каких-то шутках для тех кто его использовал.

Классный доклад! Презентация nodkz.github.io/conf-talks/talks/2018.11.24-holyjs-moscow/