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

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

352 members

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

05:29:50 ПП
User 206966715
Видео с последней конфы

https://www.youtube.com/playlist?list=PLn2e1F9Rfr6lOTXAxwZDlukTVpBxyxeur
youtube.com/playlist?list=PLn2e1F9Rfr6lOTXAxwZDlukTVpBxyxeur
05:43:28 ПП
User 138018444
А кто-нибудь использует хэширование GraphQL-запросов, типа каждый запрос с фронта при сборке отображается в uid, который на сервере маппится в нужный реквест схемы?
06:20:40 ПП
User 386334134
а кто то собирает в пачки запросы к серверу?
типа в массив
06:40:23 ПП
User 124962553
User 138018444
А кто-нибудь использует хэширование GraphQL-запросов, типа каждый запрос с фронта при сборке отображается в uid, который на сервере маппится в нужный реквест схемы?
Фейсбук)
06:50:21 ПП
User 324326717
Если я возвращаю в своем написанном middleware JsonResponce, то у меня перестает работать доки и автоподсказки
06:50:26 ПП
User 324326717
Как пофиксить?
06:50:52 ПП
User 324326717
К сожалению я не могу в middleware сделать raise GraphQLError("error")
06:53:36 ПП
User 138018444
User 124962553
Фейсбук)
Что-то не могу найти ни одного нормального OpenSource-решения — или хотя бы гайда
07:30:06 ПП
User 68794663
User 138018444
Что-то не могу найти ни одного нормального OpenSource-решения — или хотя бы гайда
https://dev-blog.apollodata.com/automatic-persisted-queries-and-cdn-caching-with-apollo-server-2-0-bf42b3a313de
dev-blog.apollodata.com/automatic-persisted-queries-and-cdn-caching-with-apollo-server-2-0-bf42b3a313de
Enhance network performance and achieve faster time-to-interaction
08:07:44 ПП
User 138018444
User 68794663
https://dev-blog.apollodata.com/automatic-persisted-queries-and-cdn-caching-with-apollo-server-2-0-bf42b3a313de
dev-blog.apollodata.com/automatic-persisted-queries-and-cdn-caching-with-apollo-server-2-0-bf42b3a313de
Enhance network performance and achieve faster time-to-interaction
Это немножко не то, мне кажется, у GraphQL есть проблема с безопасностью в виде возможности создания открытых запросов со стороны пользователя

Назначение каждому запросу с фронта своего хэша, генерируемого с помощью секретного ключа на этапе компиляции, дало бы возможность это избежать

Кажется, FB делает именно так?
08:12:43 ПП
User 68794663
Судя по этой картинке, используется хэш.
08:12:48 ПП
08:13:45 ПП
User 68794663
(Ох как отобразилось из-за прозрачного фона 😀)
08:14:18 ПП
User 68794663
Вопрос лишь в том, что именно вам нужно. В статье речь идёт о хеше с целью ускорения.
08:14:45 ПП
User 41361143
User 138018444
А кто-нибудь использует хэширование GraphQL-запросов, типа каждый запрос с фронта при сборке отображается в uid, который на сервере маппится в нужный реквест схемы?
это apollo 2 умеет делать
08:16:18 ПП
User 68794663
User 41361143
это apollo 2 умеет делать
Я скинул выше как раз ссылку на статью про apollo-server@2. )
08:16:38 ПП
User 138018444
User 68794663
Там следующая картинка показывает, что если хэш на сервере не найден, фронт присылает запрос целиком, и потом он сохраняется в хэш
08:17:23 ПП
User 138018444
Но мне бы хотелось, чтобы фронт мог присывать только некий заданный при компиляции пулл запросов-хешей
08:19:23 ПП
User 68794663
User 138018444
Это немножко не то, мне кажется, у GraphQL есть проблема с безопасностью в виде возможности создания открытых запросов со стороны пользователя

Назначение каждому запросу с фронта своего хэша, генерируемого с помощью секретного ключа на этапе компиляции, дало бы возможность это избежать

Кажется, FB делает именно так?
Вообще, API нужно защищать, чтобы абы кто всё подряд не мог писать и читать. Есть инструменты для этого. Например, GraphQL Shield (https://github.com/maticzav/graphql-shield).
github.com/maticzav/graphql-shield
🛡 A GraphQL tool to ease the creation of permission layer. - maticzav/graphql-shield
08:20:33 ПП
User 138018444
User 68794663
Вообще, API нужно защищать, чтобы абы кто всё подряд не мог писать и читать. Есть инструменты для этого. Например, GraphQL Shield (https://github.com/maticzav/graphql-shield).
github.com/maticzav/graphql-shield
🛡 A GraphQL tool to ease the creation of permission layer. - maticzav/graphql-shield
Ну это-то да, у нас пермишены на уровне JWT и микросервисов
08:21:25 ПП
User 138018444
User 138018444
Но мне бы хотелось, чтобы фронт мог присывать только некий заданный при компиляции пулл запросов-хешей
А это бы уберегло сразу и от рекурсивных запросов, и от слишком сложных по нагрузке, и от костылей на ограничение лимита, и вообще радость-счастье-пони
08:22:09 ПП
User 68794663
А так любой может через graphql introspection посмотреть что умеет твоё API и составить о нём представление.
08:22:54 ПП
User 138018444
Да, это меня и беспокоит, с хэшами и это бы ушло
08:24:11 ПП
User 68794663
Если API правильно спроектировано с точки зрения секьюрности, то зачем скрывать схему?
08:24:21 ПП
08:25:37 ПП
User 68794663
Вот, например, у GitHub сейчас GraphQL API, его каждый пытается тыкать, но они же не скрывают схему.
08:27:20 ПП
User 138018444
Потому что публичное API можно ограничивать как угодно, хоть таймауты по 1 секунде хоть бан через 30 реквестов, свой же родной фронт ограничивать нехорошо
08:27:21 ПП
User 68794663
https://dev-blog.apollodata.com/securing-your-graphql-api-from-malicious-queries-16130a324a6b
dev-blog.apollodata.com/securing-your-graphql-api-from-malicious-queries-16130a324a6b
Working with GraphQL is amazing, but also has complex security implications. Let’s dig into some essential protections for your API.
08:29:54 ПП
User 138018444
User 68794663
https://dev-blog.apollodata.com/securing-your-graphql-api-from-malicious-queries-16130a324a6b
dev-blog.apollodata.com/securing-your-graphql-api-from-malicious-queries-16130a324a6b
Working with GraphQL is amazing, but also has complex security implications. Let’s dig into some essential protections for your API.
Да, это уже лучше, спасибо большое, ещё бы этот WhiteList собирался бы на этапе компиляции с продовскими флагами…
08:30:23 ПП
User 68794663
https://github.com/4Catalyzer/graphql-validation-complexity
github.com/4Catalyzer/graphql-validation-complexity
graphql-validation-complexity - Query complexity validation for GraphQL.js
08:30:37 ПП
User 68794663
https://github.com/pa-bru/graphql-cost-analysis
github.com/pa-bru/graphql-cost-analysis
A Graphql query cost analyzer. Contribute to pa-bru/graphql-cost-analysis development by creating an account on GitHub.
08:31:07 ПП
User 138018444
Да, я понимаю, но это всё ещё костыли, нет?
08:34:16 ПП
User 68794663
Эмм… почему костыли?
08:35:08 ПП
User 68794663
Наоборот, это более правильный и цивилизованный способ ограничить API, чем просто пытаться скрыть introspection.
08:36:15 ПП
User 68794663
Это как с криптографией. Надёжен тот шифр, у которого и алгоритм, и публичный ключ не скрывается.
08:36:49 ПП
User 68794663
Все знают как он устроен, а взломать не могут, пока не подберут закрытый ключ, что почти нереально.
08:38:23 ПП
User 68794663
В таком шифре можно быть уверенным, тут нечего скрывать.

А вот шифры, алгоритм которых тщательно скрывается, сомнительны. Потому что сразу возникает мысль, раз скрывают, значит не идеален. Значит по алгоритму можно найти брешь.
08:39:04 ПП
User 138018444
Ну, у меня просто Банк, и нас беспокоит пользовательская свобода, мы бы хотели графQL- ную гибкость при разработке фронтов и абсолютно детерменированные запросы в проде
08:40:21 ПП
User 138018444
User 138018444
Да, я понимаю, но это всё ещё костыли, нет?
Ну, то есть, это всё клёво, и можно, и нужно использовать, но оно решает не все проблемы
08:41:08 ПП
User 68794663
Конкретный список проблем, пожалуйста, в студию. )
08:46:20 ПП
User 68794663
Кстати, вот ещё статья недельной давности:

https://itnext.io/graphql-data-hiding-using-apollo-stack-ad1ea92fa85c
itnext.io/graphql-data-hiding-using-apollo-stack-ad1ea92fa85c
If your website have a private GraphQL API and you don’t want people to see plain queries and responses in a browser DevTools then here is…
08:48:21 ПП
User 68794663
Но это не реальная защита, а просто своего рода обфускация.
08:49:30 ПП
User 68794663
Так как приватный ключ всё равно на клиенте. )
08:50:27 ПП
User 138018444
User 68794663
Так как приватный ключ всё равно на клиенте. )
Да, это сосвсем как-то бессмысленно, разве что от школьников, которые парсят сайты на фрилансе за еду))
08:52:55 ПП
User 68794663
В общем, для начала тебе нужно выписать вообще все поля, которые есть в базе данных и будут в твоём API. Потом понять кто и при каких условиях какие поля может читать, писать, обновлять и удалять.
08:53:45 ПП
User 138018444
User 68794663
Конкретный список проблем, пожалуйста, в студию. )
Ну, абстрактно:

Пусть у нас найти пользователя по комментарию — нетривиальный и сложный запрос (мы плохие программисты, которые не смогли)

Тогда даже ограничив глубину можно сделать

user->commentar[]->user[]->commentary[]->user[]

Предположим, злобные хакеры посидели с профайлером и нашли наш сложный запрос

Двадцадь аккаунтов — пусть 60 запросов в секунду (то есть, даже по IP не залочить) — и всё, прод валяется у всех
08:54:37 ПП
User 138018444
Входящей нагрузки нет, злоумышленник затерялся в общей массе, всё плохо
08:55:36 ПП
User 138018444
User 68794663
В общем, для начала тебе нужно выписать вообще все поля, которые есть в базе данных и будут в твоём API. Потом понять кто и при каких условиях какие поля может читать, писать, обновлять и удалять.
Да это-то да, в REST-то мы можем)
08:56:25 ПП
User 68794663
Так подсчитывайте Cost и Complexity каждого запроса.
08:56:52 ПП
User 68794663
Если больше порогового значения, не выполняйте.
08:57:37 ПП
User 68794663
Подключите Apollo Engine, собирайте метрики. Смотрите, что происходит.
08:59:20 ПП
User 68794663
Статья, которую я скинул, она об этом.
08:59:46 ПП
User 68794663
Ребята из Spectrum Chat это юзают на продакшене.
09:01:54 ПП
User 68794663
Кстати, в Apollo Engine есть ещё кэширование.
09:02:11 ПП
User 68794663
Чтобы не вычислять одно и то же каждый раз.
09:04:25 ПП
User 68794663
А если юзать Prisma (https://prisma.io), то это вообще считай ORM, превращающая базу данных в OpenCRUD GraphQL API. То есть под капотом она должна индексы строить.
prisma.io
Prisma is a performant open-source GraphQL ORM-like layer doing the heavy lifting in your GraphQL server.
09:11:56 ПП
User 138018444
User 68794663
Так подсчитывайте Cost и Complexity каждого запроса.
Не пойми неправильно, я за GraphQL всей душой, но посоны (безопасники) — не поймут) spectrum.chat, кстати, похоже, лежит))
09:12:17 ПП
User 138018444
Во, ожил
09:13:57 ПП
User 68794663
Вот ещё очень полезный пакет:

https://github.com/confuser/graphql-constraint-directive

Помимо того, что с помощью graphql-shield можно ограничить кто что может читать и писать, этот пакет добавляет валидацию самих полей (например, по регулярке).
github.com/confuser/graphql-constraint-directive
graphql-constraint-directive - Validate GraphQL fields
09:20:00 ПП
User 68794663
User 138018444
Не пойми неправильно, я за GraphQL всей душой, но посоны (безопасники) — не поймут) spectrum.chat, кстати, похоже, лежит))
Ну раз собрались использовать GraphQL, нужно изучать как это работает и перестраивать своё мышление.

Если раньше ваши безопасники следили чтобы не было слишком частых запросов к endpkint'ам, то теперь у вас один endpoint и нужно смотреть не на количество запросов, а на «качество» – насколько сложный это запрос.

Те же яйца только вид в профиль.
09:22:11 ПП
User 68794663
У вас есть человек кто занимается базами данных, оптимизирует SQL-запросы?
09:22:45 ПП
User 138018444
User 68794663
Ну раз собрались использовать GraphQL, нужно изучать как это работает и перестраивать своё мышление.

Если раньше ваши безопасники следили чтобы не было слишком частых запросов к endpkint'ам, то теперь у вас один endpoint и нужно смотреть не на количество запросов, а на «качество» – насколько сложный это запрос.

Те же яйца только вид в профиль.
Нет, это так не работает, абстрактно: всем понятно, как лочить по IP за превышение RPM, есть умение, есть практика, есть автоматические инструменты
09:22:48 ПП
User 68794663
Подключите его к процессу разработки API.
09:23:22 ПП
User 138018444
User 68794663
У вас есть человек кто занимается базами данных, оптимизирует SQL-запросы?
У нас почти фулл devops))
09:24:53 ПП
User 68794663
User 138018444
Нет, это так не работает, абстрактно: всем понятно, как лочить по IP за превышение RPM, есть умение, есть практика, есть автоматические инструменты
Теперь у вас вместо RPM Complexity и Cost. )
09:25:29 ПП
User 68794663
Как вариант, можете сделать просто обёрту над REST.
09:25:42 ПП
User 138018444
Ещё всех беспокоит, что ни одного Success story, ни каких-то Best Practice от крупных чуваков, кто держит его на фронте, нет, статей про Angular или про реакт или про Go — миллион, как только они появились, все сразу же стали впихивать их куда ни поподя, GrapQL же уже 6 лет, и что-то всё пусто
09:26:12 ПП
User 138018444
User 68794663
Теперь у вас вместо RPM Complexity и Cost. )
Но это уже не обработать Nginx) (Хотя вообще говоря не знаю, что отвечает за блок по RPM)
09:27:25 ПП
User 68794663
Вообще-то полно всяких Success Stories и Best Practices. (:
09:27:52 ПП
User 68794663
Открой для себя Medium. ;)
09:28:21 ПП
User 68794663
Саммиты по GraphQL по несколько раз в год.
09:28:43 ПП
User 68794663
Есть записи на YouTube, офигенские доклады.
09:29:23 ПП
User 68794663
https://www.graphql-europe.org
graphql-europe.org
GraphQL Europe - Berlin, June 15th, 2018 - Join Europe’s biggest GraphQL-dedicated conference
09:29:38 ПП
User 68794663
Почитай список докладов.
09:31:59 ПП
User 68794663
Сейчас GraphQL – такой же buzzword в мире front-end как и, например, PWA (Progressive Web Apps) или Web Components.
09:32:35 ПП
User 68794663
И Facebook его пиарит так же как и React.
09:33:42 ПП
User 138018444
Ну, типа, если серьёзно, у большей части статей, которые ты скинул (хотя спасибо большое) ~120 хлопочков, при том, что на медиуме один человек может до 50 ставить
09:33:58 ПП
User 138018444
Эх, ладно, пойду завтра его снова на работе пиарить ;)
09:34:49 ПП
User 68794663
Причём даже в связке React+GraphQL. См. Relay (https://facebook.github.io/relay/).
09:37:05 ПП
User 68794663
User 138018444
Ну, типа, если серьёзно, у большей части статей, которые ты скинул (хотя спасибо большое) ~120 хлопочков, при том, что на медиуме один человек может до 50 ставить
Недавно уже в Twitter было меренье проектов звёздами на GitHub и разжёвыванием неадекватности этой метрики.

С хлопками на медиума та же фигня. )