-- тред про graphql --
До того как я начала работать в Фейсбуке о graphql я слышала, но не использовала.
В моем проекте мы используем много graphql с Relay.
Тут будет:
graphql и Rest, что graphql даёт, что graphql не дает, как влияет на процесс + Relay
Идея graphql
Представим что у нас есть user profile. Это гигантская сущность - тут все - friends, subscription, relationship status. Эта сущность логическая - части хранятся в разных хранилищах, где-то кеш, что-то обновляется часто, что-то transient. Итого, допустим ~500 fields
У нас есть UI. UI компоненты используют малую часть полей user profile. Например - name и photo url, location и privacy settings, etc.
Вопрос -
Как компонентам получить нужные данные из user profile?
Также - как избежать передачи полей, которые не нужны ни одному из компонентов?
Можно забить на overfetch - брать все и распределять поля на уровне компонентов. Это ужасно, не делайте так.
Можно писать rest endpoint для каждого компонента отдельно, но тогда вы получите 400 endpoints со всевозможными комбинациями полей user profile, maintainability 0
Но мы хитрые!
Мы напишем REST endpoint с параметрами, что-то вроде fields-list. Это будет один endpoint, за ним мы спрячем resolve, acess control, etc всеx нужных полей. Компонент будет запрашивать свой fields-list, maintainbility растет.
Поздравляю, мы почти изобрели graphql.
Теперь мы не копируем resolve код для одной сущности на сервере много раз. Это хорошо.
Но наши компоненты всё ещё не знают когда им надо обновляться если поле X поменялось (один из field-list запросов вернул обновленные данные).
Нашим UI компонентам не хватает важнейшего свойства
UI компоненты должны декларативно определить свои data requirements, что из user profile они рендерят или используют.
В graphql это называется Query.
Сервер определяет что вообще он может дать - (f.i. user profile) - это GraphQL Object.
Итого на сервере единожды описываем как доставать ВСЕ.
Немного упростив получаем - schema и resolvers на Graph QL server-е.
Schema состоит из Query(все r запросы), Mutation(все cud запросы), и Subscription деклараций.
Все graphql objects(req/resp) описываются также в схеме.
На UI компоненты обернуты в Queries. В разных фреймворках это выглядит по-разному.
В Relay это либо хук либо компонент- контейнер.
Дальше больше.
Все типизировано сразу и полностью.
Нельзя использовать на UI поле котрого нет, компиляция упадет. Что это даёт?
Возможность работать в полностью независимых командах в моно репозитории, без страха кого-то поломать. Это важный момент - это еnabling growth.
Декларативный подход даёт одно сверхпреимущество
-- optimization из коробки --
дедупликация data requirements ui компонентов, UI кеш, оптимальный re-fetch, re-render on data update, data requirement locality, computable fields.
Это все Relay.
Что такое GraphQL?
Это только query language спецификация.
GraphQL server имплементация может быть на любом языке.
GraphQL server resolvers и server context содержат всю магию auth. Тут ничего не меняется кардинально - токены, сессии, roles, итд
Что GraphQL вам не даст?
- спокойную и лёгкую миграцию из/в REST
- easy hiring, все таки learning curve есть
- opensource предпочитает REST, потому меньше опций по имплементациям
- Dynamic shemas это хак и будет работать так себе, потому если типы какие-то динамичные - 0 benefit
Часто люди пробующие GraphQL ошибаются так:
- плохой изначальный schema design
- продолжают думать об endpoints, а не о objects
- не хорошая организация релизов - graphql server и client должны всегда быть on a same page (это сложно)
Вот тут bit.ly/2WVieWv подробнее
Зачем?
Чтобы забыть о каких-то там body/path параметрах, data updates handling - фреймворк все сделает сам
Надо что-то зарендерить? Не надо трогать сервер - просто добавляешь нужное поле в Query компонента.
Надо как-то хитро что-то вычитать из базы или кеша - код пишешь один раз
На этом по graphql у меня все.
Завтра отвечу на оставшиеся вопросы!
Спасибо большое за внимание и прекрасные вопросы.
Традиционно - лучший туториал хоть и не книга
bit.ly/2NrLbX7
Всем спасибо ! И если хотите -
