Context

• What is Strawberry?
  Strawberry is a modern, type‑first Python GraphQL library that uses Python type hints and dataclasses to define GraphQL schemas, with good async support and a strong focus on developer ergonomics.

• Why is this an important feature to implement?
  Multiple users explicitly prefer Strawberry over Graphene and see it as the more “modern” choice in the Python GraphQL ecosystem (“Graphene is a relic now, long live strawberry 🍓”). They’re already exploring Django MongoDB Backend and asking whether Strawberry works or is supported, alongside interest in DRF and admin integration.
  Providing a clear, supported story for Strawberry + Django MongoDB Backend aligns us with current community expectations and makes it easier to build GraphQL APIs on top of MongoDB-backed Django apps.
  •  

    User 1: Thanks for bringing this update to Django! It's really appreciates that NoSQL alternatives are being considered for such a loved framework. I'm currently reading through the project current limitations, and it seems like the basics are well covered, Geospatial Queries will be a great addition in the future. Additionally, having DRF support as a priority is a big plus. I'm curious if Graphene or Django Ninja is on your compatibility roadmap?
    User 2: I'd rather see Strawberry, personally 😅
    User 3: +1 to "strawberry, not graphene" comment. Graphene is a relic now, long live strawberry 🍓 Personally, I'm more interested in admin integration. I checked the docs, couldn't see any mention of it. Not sure if it works just fine or doesn't work at all.
    

     

Acceptance Criteria

• What does implementation look like with respect to Django-MongoDB-Backend

• • A documented pattern (or example project) showing how to define Strawberry types and resolvers backed by models using Django MongoDB Backend.
  • Working examples of basic CRUD via Strawberry (queries and mutations) against MongoDB collections, including nested/embedded document access where appropriate.
  • Clear guidance on any differences vs. relational Django setups (e.g., querying, pagination approaches, or limitations) so users know what “supported” means in practice.

Pitfalls

• Identify any pitfalls

• • Strawberry’s integration patterns and many community examples assume a traditional Django/relational backend; some features (joins, complex relational filters) don’t map 1:1 to MongoDB’s document model and may require custom resolvers or query logic.
  • Handling embedded documents, dynamic schemas, and MongoDB‑specific features (e.g., aggregation pipelines, geospatial queries) in a type‑safe GraphQL schema may add complexity.
  • Keeping compatibility across evolving versions of Strawberry, Django, and Django MongoDB Backend, plus user interest in adjacent integrations like Django admin, expands the surface area for testing and maintenance.