В случае с новыми обьектами можно точечно расширять тип, который возвращает конкретная мутация и добавлять туда обьект нужного типа. Хорошей идеей было бы добавить это на уровне либы и написать в статье, спасибо за комментарий :)
Я бы не рекомендовал GraphQL c Django в проде, слишком маленькое комьюнити, бедная документация и медленное развитие.
Если хочется GraphQL (например, если есть много разных клиентов у API, которым нужны разные данные от эндпоинтов), то я бы рекомендовал делать бек на nodejs. Сам не пробовал, но слышал от GraphQL-активистов)
Ваше решение симпатично для большей свободы от ORM и BE для разработчика FE. Иногда происходят слишком большие паузы в проекте из за добавления нового SQL вызова на BE.
И BE разработчики слишком передовые чтоб знать особенности SQL и в частности PostgreSQL.
Тут уже советы давать сложно, я бы начал не с перехода на GraphQL, а с оптимизации процессов между командами фронта/бека :)
К сожалению, магических историй не происходит ни с кем, в нее нужно ввязаться самому :D
Лучший совет, как понять стоит ли решаться — попробовать. Но надо понимать, что сразу ничего не получится и за пару дней новый поезд водить не научишься. Терпение и опыт решают
В проекте вообще не использовал DRF, поэтому и не рассматривал возможность какой бы то ни было интеграции. А что имеется ввиду под "информацией о структурах и типах"?
Проблема select n + 1 решается при помощи пакета graphene-django-optimizer, он анализирует запрос и по возможности оптимизирует обращение к БД, а также позволяет описывать правила для оптимизации в более сложных ситуациях.
В случае с новыми обьектами можно точечно расширять тип, который возвращает конкретная мутация и добавлять туда обьект нужного типа. Хорошей идеей было бы добавить это на уровне либы и написать в статье, спасибо за комментарий :)
Я бы не рекомендовал GraphQL c Django в проде, слишком маленькое комьюнити, бедная документация и медленное развитие.
Если хочется GraphQL (например, если есть много разных клиентов у API, которым нужны разные данные от эндпоинтов), то я бы рекомендовал делать бек на nodejs. Сам не пробовал, но слышал от GraphQL-активистов)
Тут уже советы давать сложно, я бы начал не с перехода на GraphQL, а с оптимизации процессов между командами фронта/бека :)
К сожалению, магических историй не происходит ни с кем, в нее нужно ввязаться самому :D
Лучший совет, как понять стоит ли решаться — попробовать. Но надо понимать, что сразу ничего не получится и за пару дней новый поезд водить не научишься. Терпение и опыт решают
Да, занятная шутка. Но она для DRF, а он никак не клеится с graphql. Но спасибо за ссылку!
В проекте вообще не использовал DRF, поэтому и не рассматривал возможность какой бы то ни было интеграции. А что имеется ввиду под "информацией о структурах и типах"?
Проблема select n + 1 решается при помощи пакета graphene-django-optimizer, он анализирует запрос и по возможности оптимизирует обращение к БД, а также позволяет описывать правила для оптимизации в более сложных ситуациях.