Comments 8
Рассматривали ли, возможность передавать информацию о структурах и типах через метаданные в DRF? Если да, то почему предпочли описывать собственные интерфейсы для мутаций объектов?
Возникает ли проблема select n+1 при попытке использовать фильтр по id?
P.S.: Долгое время искал в себе мотивацию сделать себе адаптер для graphql, но всегда быстрее было дополнить drf.
В проекте вообще не использовал DRF, поэтому и не рассматривал возможность какой бы то ни было интеграции. А что имеется ввиду под "информацией о структурах и типах"?
Проблема select n + 1 решается при помощи пакета graphene-django-optimizer, он анализирует запрос и по возможности оптимизирует обращение к БД, а также позволяет описывать правила для оптимизации в более сложных ситуациях.
Я бы не рекомендовал GraphQL c Django в проде, слишком маленькое комьюнити, бедная документация и медленное развитие.
Если хочется GraphQL (например, если есть много разных клиентов у API, которым нужны разные данные от эндпоинтов), то я бы рекомендовал делать бек на nodejs. Сам не пробовал, но слышал от GraphQL-активистов)
Ваше решение симпатично для большей свободы от ORM и BE для разработчика FE. Иногда происходят слишком большие паузы в проекте из за добавления нового SQL вызова на BE.
И BE разработчики слишком передовые чтоб знать особенности SQL и в частности PostgreSQL.
Тут уже советы давать сложно, я бы начал не с перехода на GraphQL, а с оптимизации процессов между командами фронта/бека :)
возвращать базовый Query в ответе мутации - это крутая идея!
но как быть с мутациями, которые создают новые объекты, и в обычном RESTe возвращали бы созданный объект, или хотя бы его id? в случае с базовой Query у клиента нет возможности узнать, что он (клиент) только что создал, какой там id.
Год приключений с graphene-python