Open nin-jin opened 4 years ago
Про загрузку файлов можно выкинуть. По крайней мере если исходить из парадигмы использования GraphQL over HTTP(S) https://blog.apollographql.com/file-uploads-with-apollo-server-2-0-5db2f3f60675
HTTP кеширование не работает
GraphQL не про интерфейс и протокол, это про структуру данных. Как реализуют клиенты кэширование вообще отдельная тема. При необходимости можно даже HTTP кэш накинуть. Но в целом это решается через механизмы кэширования на клиенте или в WW.
Потенциальный DOS
Есть уже способы работы со сложными системами на GraphQL чтобы учитывать query complexity, например https://github.com/slicknode/graphql-query-complexity
Накину про серверсайд gql на ts:
class GraphQLEnumType /* <T> */ {
, сложно использовать в аргументах, тем более что values может маппить как угодно входные значения__typename: string
: https://github.com/relay-tools/relay-compiler-language-typescript/issues/190type Offer = { id: string; related: Offer[] }
, надо отдельно вынести все поля без related в GraphQLObjectTypeConfig, создать OfferBase с этими типами без related и Offer с related.new GraphQLObjectType<Snippet | Card, GraphqlContext, Args>
new GraphQLList(new GraphQLNonNull(SomeType))
Денормализованная выдача
Выдаётся всегда дерево в денормализованной форме. Если в графе есть циклы, то выдача может легко увеличиться на порядок за счёт дублирования поддеревьев.
Представление данных в виде слепков
Это несовместимо с с бесконфликтными алгоритмами слияния, так как теряет мета-информацию об изменениях.
Нестандартизированные параметры
GQL - это просто RPC. offset, limit, filter, sort и прочее реализуется всеми по разному. Из-за чего нельзя написать универсальный инструмент работы с разными АПИ.
DevTools браузера мало полезны
Все запросы POST-ом (или экранированным GET), все ответы с кодом 200. Соответственно браузер никак не помогает всё это дебажить.
HTTP кеширование не работает
RPC в принципе не кешируется. В лучшем случае кеширование реализуется клиентской библиотекой. Кеширование на прокси идёт лесом.
Много сложностей
Все эти типы, фрагменты, мутации и пр на собственном ограниченном языке, требующем писать много кода для простых вещей. Дженерики? Плиморфизм для мутаций? Переиспользование кода между запросами и мутациями? "Вам это не нужно". Без библиотек и спец-инструментов использовать очень сложно.
Нет загрузки файлов
Разве что через упаковку их в BASE64 и посылки текстом.
Потенциальный DOS
Легко простым запросом выгрузить на клиент всю базу, что положит сервер. Дизайн запросов такой, что сложно сделать ограниченное число запросов к базе на запрос к северу. А неограниченное число запросов к базе быстро убьёт производительность. Расстановка индексов становится нетривиальной задачей.
Кривой nullable
Все поля nullable по умолчанию. При этом невозможно отличить null от отсутствия поля, что важно при мутациях, чтобы не стирать данные, если поле не передано.