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 :)

Upvote & Fund

We're using Polar.sh so you can upvote and help fund this issue.
We receive the funding once the issue is completed & confirmed by you.
Thank you in advance for helping prioritize & fund our backlog.

Hi @capital-G ,

There's still a lot of improvements to be made to this lib indeed, specially regarding documentation. I'll answer some of your questions here:

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 ??

The main strawberry repository is a monorepo containing all of the integrations with other frameworks, and the idea is to have this integration there as well once it is mature enough.

Also, since you mentioned strawberry-django-plus, it is an extension to this lib that I wrote at the end of last year to add some functionality that I needed for some projects that I was migrating from graphene. It end ended up having a lot of very useful (some might say "must have") features that the community liked (i.e. the query optimizer). I later was invited to maintain this repo and decided to merge those features here, which I unfortunately didn't have time yet to do yet =p.

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

This project and strawberry itself follows the patterns defined by the dataclasses lib, in which a decorated class gets transformed to become "a data class". I understand when you say that it deviates from the django design principles, but following it would also deviate from the strawberry design principles.

Also note that when you are writing a graphql api you are not only exposing types that gets "automatically generated" by the ORM extension, but you are also writing other pure strawberry types and also adding non ORM fields to your type. If this lib followed DRF conventions you would end up with a lot of mixed styles in your module that don't talk to each other. Not to mention that the DRF style doesn't support data class transforms.

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

All contributions are very welcomed! :) As I mentioned earlier, there's still a lot of work to be done here. There are a lot of features to be ported from strawberry-django-plus, there's some missing features and improvements to be made, and a lot of documentation to be written.

Hit us on our discord channel in case you want to discuss anything, are having any issues. Feel free to @ me there as well :)

Yeah, there's a lot of fragmentation and still a lot missing. Having got one django app in production and working nicely with graphene, I've begun working with strawberry after reading the exact same post as @capital-G and found that reality is that there's a hell of a long way to go before we hit parity with the django graphene offerings.

To be clear, this isn't a dig at you @bellini666 since you seem to be overwhelmingly delivering for an ever-bigger set of user demands. Is the constraint for you and the rest of the core strawberry team about time, or about money?

If the latter, I can't afford to become a recurring sponsor but potentially can sponsor some specific issues if you'd like to talk more.
If the former, perhaps I or my team at Octue do a few things but we're also pretty resource constrained, and honestly we're still learning about strawberry so it might not be so effective.

I disagree with the Graphene vs Strawberry parity remark @thclark. Recently doing a large project with strawberry, I've mainly found it to be a steep learning curve with some rough edges that need smoothing. But feature wise, Strawberry out-classes graphene for our projects any day of the week.

Was it more difficult to get started then graphene? Yes.
Did I end up doing some changes myself to fit my use-case? Yes. Would it have been faster with graphene? Maybe - but that library is pre-async era and has plenty of challenges and missing features itself.

Let's compare Strawberry to graphene with a few quick real-world examples:

	Strawberry	Graphene
Async / Sync	Async first	Sync First
Subscriptions	out of the box	community
CUD mutations	out of the box	create yourself
File upload.	out of the box	community.

You can see that when it comes to foundations, Strawberry is the winner. The rest, is us as a community improving and chipping in one commit at a time.

I'm on the strawberry side, hands down. One of the main challenges I see in the learning-curve of Strawberry-django vs graphene. Why? The code-style challenges how we've come to expect a Django application to work. That for me created some head scratching, and some frustration along the way. A improved set of documentation that's writing from a new user perspective would have cut down my onboarding time in half.

Strawberry is a diamond in the rough.

@bellini666 in between the lines I understand that Strawberry is on top of your daily responsibilities. Which I would imagine makes it very difficult giving the project constant attention.

During my time working on the library, I would have happily paid someone with the experience to get things moving along. The sponsorship opportunities didn't allow for this philosophy, so we ended up investing the time ourselves.

Personally I would happily setup a commercial support for Strawberry, which will ultimately benefit the library itself, everyone using it and add to guaranteeing long-term succes.

I believe this would be the right way forward to increase traction. Drop me a msg if you're open to discussing this.

Hey @thclark and @sdobbelaere ,

First of all, as a former Graphene user myself, I want to agree with @sdobbelaere regarding strawberry being superior! Of course my opinion should be taken with a grain of salt as I'm biased towards it :)

One thing for sure that Strawberry Django needs is more docs and tutorials! I really want to start creating some video tutorials to post on youtube for it, but I'm lackin time lately. An introduction could be this presentation I made at last year's Djangocon US: https://www.youtube.com/watch?v=TP8MC2W3eIw

Regarding my dedication to this repo: At my previous job I was using strawberry extensively to build a lot of projects, but I recently moved to another job where I'm unfortunately working with REST now T_T

I'm still committed to maintain this library and will never abandon it no matter what, but while before it was part of my daily work to identify issues and improvement opportunities as one of the users of this lib, now this has become a side-project and I can only dedicate my spare time to it.

During that spare time I'll usually focus on reviewing PRs from the community, replying to issues and also trying to tackle some issues that I think are important, but for sure it is not moving as faster as it was before... Having said that, I'm open to have some issues/features sponsored to give them a high priority in that spare time :). Feel free to send me an email (look at my profile) or send me a pm on discord (my username is bellini)

Also, regarding setting up a commercial support for Strawberry and ensure its longevity, it is possible to support it at our open collective page: https://opencollective.com/strawberry-graphql

Thanks @bellini666 and @sdobbelaere these are helpful comments.

On my parity comment, our difference is an issue of perspective - but the main thing is it's worth reiterating that I work in OSS myself, so I do really understand the struggle; I'm tremendously grateful of your efforts, as they're what brought us here!

Let's put some polish on the diamond, to follow @sdobbelaere's simile.

It sounds like @bellini666 you're struggling a bit for time but in the first instance I'll drop you an email and let's discuss properly how I can support you, perhaps we draw on SD too. I'm a good documentation person so perhaps we can work out something where I sponsor to prioritise some features, then contribute some days of work on the documentation myself once I see how it all works.

In the meantime I'll make an issue around subscriptions, which is one of the areas I'm interested in bringing strawberry-django along.

strawberry-graphql / strawberry-django

State of django integration for Strawberry #208

Upvote & Fund