State of django integration for Strawberry

As a novice in graphql it seems quite confusing about the state of graphql and its python and django integration - you really feel more in a npm environment that in a pip environment :) I came across strawberry because I was told that the most starred graphql library for django is dead and stumble across strawberry which neatly integrates some cool new and useful Python features like it type hinting.

My proposal would be to state the following motivations in the README.md to better understand the state of strawberry-django which is essential if you consider using it for a project

• why strawberry vs. graphene-django

• why is there strawberry.django, strawberry_django - this repo, strawberry_django_plus (I know there is a PR https://github.com/strawberry-graphql/strawberry-graphql-django/issues/139) and some extensions for ?? What are their dependency hierarchies as they somehow depend on each other but at the same time also have no fixed dependencies, see https://github.com/strawberry-graphql/strawberry-graphql-django/issues/182#issuecomment-1260642217 - IMO it is best to have an upper boundary within a minor version (so that the API is stable) instead of having a lower boundary, e.g. the following line will break in production and dev easily if you don't freeze your complete dependency tree and requires you to always use the newest version of everything https://github.com/strawberry-graphql/strawberry-graphql-django/blob/b615ed58a75943aacb0f41faa77d3a5bfedf2ea6/pyproject.toml#L29 I think some confusion could also be resolved if the documentation would use sphinx (#207 ) as this also allows to link the documentation across multiple projects

• why does this django integration deviate from common django design principles and more follows the strawberry approach? DRF mimics the Django Form API, making it easier to adapt and understand/follow what is happening behind the abstraction. IMO an inheritance pattern is more easy to understand than a decorator based approach - this is maybe a matter of preference but Django uses decorators only to encapsulate (e.g. @login_required, but which can also be used as a Mixin), rarely to generate code, e.g. the current approach

  @strawberry.django.type(models.Fruit)
  class Fruit:
      id: auto
      name: auto
  

  would look more like this in a traditional Django based approach (e.g. Admin, Form, ClassBasedViews)

  class Fruit(strawberry.django.Type):
    id: auto
    name: auto
  
    class Meta:
      model = models.Fruit
  

  The class inheritance make it easier to understand what is happening from within the IDE as well - therefore I would be really interested what the motivation behind the currently used design principle is.

Also some crucial use cases like authentication are stated as done on the README.md but is not documented and is also asked on SO - some patterns for permissions would also be nice :)

I also look forward to contribute to this repo as I decided to use it in a project :)