☂️Graphene-Django v3

[jkimbo]

This issue is to track v3 of Graphene-Django which will contain some breaking changes.

WIP branch: v3 (compare)

Breaking changes

• [x] Upgrade to Graphene v3 (which also upgrades graphql-core to v3) (PR work in progress: https://github.com/graphql-python/graphene-django/pull/905)
• [x] Convert MultipleChoiceField to List of type String (#611)
• [x] Start raising DeprecationWarnings for using only_fields and exclude_fields (see https://github.com/graphql-python/graphene-django/pull/691) (PR #980)
• [x] Start warning if neither fields or exclude are defined on DjangoObjectTypes https://github.com/graphql-python/graphene-django/issues/710 (PR #981)
• [x] Default CAMELCASE_ERRORS setting to True (PR #789)
• [x] Rename DJANGO_CHOICE_FIELD_ENUM_V3_NAMING to DJANGO_CHOICE_FIELD_ENUM_V2_NAMING and default it to False (reference #860) (PR #982)
• [x] Convert decimal fields correctly: https://github.com/graphql-python/graphene-django/issues/91

TODO

• [ ] Check dependant libraries: https://github.com/tfoxy/graphene-django-optimizer and https://github.com/eamigo86/graphene-django-extras

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ktosiek]

Hey stale bot, this issue is not dead yet, it's just getting started!

[ktosiek]

Has anyone started working on this? I'm currently trying to just make tests pass under graphene 3.

[swist]

Is there an up to date todolist on this? I have a couple of days this week so can pick it up and finish off your branch

[ktosiek]

I think it's complete enough to try building on top of it (porting an actual application, or checking if graphene-django-optimizer works). It would also be nice to drop the dependency on promise.

[patrick91]

@ktosiek we could try with https://github.com/graphql-python/swapi-graphene

I wanted to test graphene 3 at work, but we are still on v1 :D

[swist]

I've just tried it on my current project. Seems to work fine minus some of our custom graphene types that allow us to use django_more/django_enum

[BfutureP]

graphene-django doesn;t support graphql 3, says from graphql import get_default_backend not found

[garimagupta715]

is asgi server supported in graphene. how can we implement subscription with graphene

[ulgens]

Any progress on this?

[ganwell]

@ulgens Last month I started to run graphen-django v3 against our test-suite (https://github.com/projectcaluma/caluma), but I got distracted by other projects. I was able to reduce errors from 500 of 600 to about 150 of 600. I assume there are still bugs in the graphql*/graphene* projects, some are in caluma itself of course. I hope I can resume the work in February.

[ulgens]

@ganwell Thanks for answering to both of my comments :slightly_smiling_face: Is there any way to push your work, so we can continue on that?

[ulgens]

Or maybe, somehow, we can do some partial / incremental changes? I think it'd be more productive and beneficial for everyone.

[ganwell]

@ulgens

I did two things:

1. Match the revisions of all projects to minimize the amount of inconsistencies and give me a base to work without confusing errors because of version mismatches, this was quite a task: https://github.com/ganwell/gwork

2. One pull request with an actual bug: https://github.com/graphql-python/graphene/pull/1111

I want to continue working with the versions in gwork till I found all bugs I can with these versions and the I would iterate and update the versions.

[ulgens]

Hey everyone, i used existing PR and solved all left errors: https://github.com/graphql-python/graphene-django/pull/905

[ulgens]

Hey @jkimbo, for DJANGO_CHOICE_FIELD_ENUM_V3_NAMING settings, instead of defaulting it to True i think this setting should be removed and instead, we should intruduce a new one for V2_NAMING to revert changed behaviour.

[jkimbo]

@ulgens that sounds like a good idea!

[ganwell]

Hey everyone, i used existing PR and solved all left errors: #905

@ulgens Thanks a lot. I currently have the problem that my work is based on #774 and yours is not. I don't know how to proceed at the moment.

caluma test-suite:

355 failed, 222 passed, 96 errors
281 failed, 296 passed, 96 errors
163 failed, 414 passed, 96 errors
161 failed, 500 passed, 12 errors
Switch: 342 failed, 319 passed, 12 errors

I am more or less back where I started. I guess I will continue on #774 and check for every bug if you have already fixed it.

[ulgens]

@ganwell There is small issue with commits in my branch, i can fix it tomorrow. There is no failing test in it, so i think we can continue from there.

[ganwell]

@ulgens Thanks a lot. Could you give me the versions of graphql-core, graphql-relay-py, graphene and graphene-django you are currently using? pip freeze

If you haven't read it in my issue, I am doing an integration test by running 3+ versions of graphql-core, graphql-relay-py, graphene and graphene-django against the caluma test-suite. Of course this will find problems in caluma, but also bugs in the other projects.

So I try not change versions of these projects too often, or am set back every-time, but I guess it would be a good idea to switch to your versions.

[ulgens]

@ganwell All versions can be found in related PR. They were all the latest ones when the time of that PR.

[ganwell]

@jkimbo @ulgens I think we need a branch or a repo where we can do a regular review-process for graphene-django-3.0. I spent the whole day yesterday, incrementally merging all the commits from @ktosiek and @ulgens onto current master, and either way there are issues left. I think we need:

• Start from master
• EDIT: Switch to the 3.0+ dependencies
• Mark all ~~CI builds as allow_failures~~ failing tests
• Create small Pull-Requests gradually moving towards using graph*-3.0+ (and remove marks from fixed tests)
• Review these
• Follow changes on master, so we can cleanly merge the branch
• Merge to master
• Release

I am not the right person to review on graphene-django, but if no-one else has the time to do it, I will try.

[jkimbo]

@ganwell yeah I think you're right. How about creating a v3 branch, merging https://github.com/graphql-python/graphene-django/pull/904 then https://github.com/graphql-python/graphene-django/pull/905 and all the related changes for v3. Then we can promote that branch to master once Graphene v3 is out and release a beta of Graphene-Django.

Sound like a good plan @ganwell @ulgens ?

[ulgens]

@jkimbo @ganwell I couldn't catch why the things @ganwell recommended is needed. Everything was already done in #905 I'll check the test-tox config there when i have time but i don't see any further work needed at this point.

[ulgens]

Oh okay, i see what you recommend in that last comment @jkimbo, sorry. I think it makes sense.

[ganwell]

@ulgens @jkimbo I sometimes commented on the wrong issue/PR, so here is a status update:

• @ulgens can fix the problem I spotted easly and #905 will be made ready for merge

• I will find out why the tests are flaky for me and I'll make a pull-request to master in case it is really test order, as I suspect.

[jkimbo]

Thanks @ganwell . I don't understand why the tests on master are failing currently so any help there would be great.

Also @ganwell and @ulgens I've just created a new branch v3 and I've merged the Python 3 changes into it (#904 ). Once you've fixed up #905 @ulgens we can merge that in as well and release a beta version to flush out any other issues.

[jkimbo]

@ganwell did you get anywhere with trying to figure out why the tests are failing on master?

[jkimbo]

Managed to fix one of the failing tests and deleted the other one because I couldn't figure out what was going wrong: https://github.com/graphql-python/graphene-django/pull/931

Bit of a hack but it lets me release a bugfix for https://github.com/graphql-python/graphene-django/issues/922

[ganwell]

@jkimbo I meant that the tests fail if you run only some pytest -k tests.

I created #932

[ganwell]

I will be away from 20 til 26 of April. If still needed I will continue to work on the v3-branch from 27 of April on. @jkimbo Thanks for all the help!

[jkimbo]

@ganwell @ulgens I've just added you both to the repo with write access because of all the great work you've been doing. Would appreciate any help as well!

[ganwell]

@jkimbo Thanks a lot. I'd be glad to help. I will keep an eye on the Issues/PRs. Feel free request help. Of course I will continue to push graph* 3.0 in caluma and do PRs if issues arise.

[jkimbo]

Released the first beta version of v3: https://github.com/graphql-python/graphene-django/releases/tag/v3.0.0b1

Still needs some more changes that are listed in the description but please try it out @ganwell and report back with any issues.

[ganwell]

@jkimbo I found some time to run the caluma test-suite:

170 failed, 505 passed, 71 errors in 21.58s

This means it only slightly worse than #774. If update the snapshot tests:

80 failed, 595 passed, 71 errors

I'll start fixing ...

[jkimbo]

v3.0.0b3 released. Thanks @DoctorJohn and @radekwlsk !

[radekwlsk]

@jkimbo What's there left TODO for v3 release? Maybe I can help a bit more.

[jkimbo]

The main blocker is getting graphene v3 released actually: https://github.com/graphql-python/graphene/issues/1127

We also need some release notes for graphene-django. Is that something you could help with @radekwlsk ?

[ganwell]

My next window to work on v3 is in two weeks.

[radekwlsk]

We also need some release notes for graphene-django. Is that something you could help with @radekwlsk ?

I suppose it should be based in the list at the top of this issue and diff from master? Sounds like something I could help with, at least creating a draft for it.

[jkimbo]

That would be very helpful thanks @radekwlsk

[jkimbo]

v3 branch updated to latest master

[fabienheureux]

I fixed a few things in graphene-django-extras to bring graphene v3 compatibility, if ever some of you are using it, I would greatly appreciate your feedback on this PR https://github.com/eamigo86/graphene-django-extras/pull/148

[patrys]

I'm trying to get DjangoConnectionField to work in my project, it looks like graphene.relay.connection.IterableConnectionField.wrap_resolve replaces what DjangoConnectionField.get_resolver returns which causes DjangoConnectionField.connection_resolver to be called with just two arguments (and complain about missing arguments).

graphene = "3.0.0b5"
graphene-django = "3.0.0b4"

[jkimbo]

@patrys I just released v3.0.0b5 of graphene-django that should fix that issue. Can you try it and see?

[patrys]

@jkimbo Can confirm that it's fixed now! Now the most challenging part: to write a replacement for all promise-based dataloaders.

[patrys]

After playing with this for longer I don't see a good way to implement dataloaders.DjangoConnectionField assumes that it's completely synchronous and any code that uses functools.partial makes graphql-core assume it's synchronous as well. Now synchronous dataloaders based on Promise are no longer supported and using aiodataloader causes unresolved awaitables to be returned from resolvers (again, I think this is because graphql-core assumes that a non-coroutine wrapper cannot return an awaitable).

Edit: it seems that under Python 3.8 partials can actually function as awaitables as the code flag is set but it does not help when using DjangoConnectionField with an async connection_resolver/resolve_connection.

[jkimbo]

@patrys thanks for the investigation. We should try and use aiodataloader and use async everywhere. The lack of async DB support in Django might be a blocker though.

Could you provide some code as an example of the problems you are seeing with aiodataloader?

[patrys]

In my case dataloaders work around the ORM (at least until 3.2/4.0 lands) by offloading the database work to a worker thread:

from asgiref.sync import sync_to_async

class FooLoader(aiodataloader.DataLoader):
    @sync_to_async
    def fetch_foo(self, keys):
        return Foo.objects.in_bulk(keys)

    async def batch_load_fn(self, keys):
        foos = await self.fetch_foo(keys)
        # some other processing
        return foos

The main problem is mixing dataloaders (which require an async executor) with connection fields (that execute their own queries) within the same schema. Currently the connection field's resolve_connection/connection_resolver logic evaluates a sliced queryset which is forbidden with an event loop running (it would kill the performance of the event loop, Django will raise an exception if you try to do it) so I need a way to apply the same sync_to_async indirection to the connection field.

[cbergmiller]

graphene-django-optimizer could be an alternative to dataloader. It has to be refactored in order to work with v3 though.

For example ist uses the following imports to analyse the query:

from graphql.execution.base import (
    get_field_def,
)
from graphql.language.ast import (
    FragmentSpread,
    InlineFragment,
    Variable,
)

These imports are all renamed or don't exist in graphql-core v3 any more. Can someone give some pointers on what new methods from graphql-core to use? Here is the open issue for this: https://github.com/tfoxy/graphene-django-optimizer/issues/53

[patrys]

graphene-django-optimizer works by trying to prefetch all data ahead of any resolvers running. It's by no means a replacement for working data loaders even if we assumed that the only reason to have data loaders was to wrap the ORM. The optimizer is also fully synchronous.

(Disclaimer: we've used the optimizer extensively and my team made several contributions to that project.)

[cbergmiller]

@patrys thanks for your response! Maybe i shouldn't have compared it to dataloader as my knowledge of the data loader approach is limited. My team also uses graphene-django-optimizer. I would really like it to work with graphene-django v3. So that's why i brought it up here. Sorry if i caused any confusion.

[zbyte64]

📣 Since all the breaking changes are complete we have switched the default branch over to v3. Existing PRs are still against v2. The name of the default branch is now main and the v2 branch will continue to receive back ported fixes and releases.

[levinotik]

Any idea on when we might expect a non-beta/non-pre-release version based on v3?

[zbyte64]

I believe the only remaining dependency for a non-beta release is a non-beta release of graphene v3

[sebsasto]

Regarding graphene-django-optimizer I just opened a PR with the changes to support GrapheneV3 and graphene-django V3.

Here you can have a look: https://github.com/tfoxy/graphene-django-optimizer/pull/62

[jedie]

btw. think a project like graphene-django-optimizer should be integrated!

[AntonOfTheWoods]

I believe the only remaining dependency for a non-beta release is a non-beta release of graphene v3

Which is waiting for graphene-sqlalchemy and graphene-mongo

[allen-munsch]

just tried to upgrade to v3 and got an error message. i'm not sure how to debug this, or fix it, any suggestions, or document for the upgrade path changes?:

web_1            | Traceback (most recent call last):
web_1            |   File "/usr/local/lib/python3.6/threading.py", line 916, in _bootstrap_inner
web_1            |     self.run()
web_1            |   File "/usr/local/lib/python3.6/threading.py", line 864, in run
web_1            |     self._target(*self._args, **self._kwargs)
web_1            |   File "/venv/lib/python3.6/site-packages/django/utils/autoreload.py", line 64, in wrapper
web_1            |     fn(*args, **kwargs)
web_1            |   File "/venv/lib/python3.6/site-packages/django/core/management/commands/runserver.py", line 118, in inner_run
web_1            |     self.check(display_num_errors=True)
web_1            |   File "/venv/lib/python3.6/site-packages/django/core/management/base.py", line 423, in check
web_1            |     databases=databases,
web_1            |   File "/venv/lib/python3.6/site-packages/django/core/checks/registry.py", line 76, in run_checks
web_1            |     new_errors = check(app_configs=app_configs, databases=databases)
web_1            |   File "/venv/lib/python3.6/site-packages/django/core/checks/urls.py", line 13, in check_url_config
web_1            |     return check_resolver(resolver)
web_1            |   File "/venv/lib/python3.6/site-packages/django/core/checks/urls.py", line 23, in check_resolver
web_1            |     return check_method()
web_1            |   File "/venv/lib/python3.6/site-packages/django/urls/resolvers.py", line 412, in check
web_1            |     for pattern in self.url_patterns:
web_1            |   File "/venv/lib/python3.6/site-packages/django/utils/functional.py", line 48, in __get__
web_1            |     res = instance.__dict__[self.name] = self.func(instance)
web_1            |   File "/venv/lib/python3.6/site-packages/django/urls/resolvers.py", line 598, in url_patterns
web_1            |     patterns = getattr(self.urlconf_module, "urlpatterns", self.urlconf_module)
web_1            |   File "/venv/lib/python3.6/site-packages/django/utils/functional.py", line 48, in __get__
web_1            |     res = instance.__dict__[self.name] = self.func(instance)
web_1            |   File "/venv/lib/python3.6/site-packages/django/urls/resolvers.py", line 591, in urlconf_module
web_1            |     return import_module(self.urlconf_name)
web_1            |   File "/usr/local/lib/python3.6/importlib/__init__.py", line 126, in import_module
web_1            |     return _bootstrap._gcd_import(name[level:], package, level)
web_1            |   File "<frozen importlib._bootstrap>", line 994, in _gcd_import
web_1            |   File "<frozen importlib._bootstrap>", line 971, in _find_and_load
web_1            |   File "<frozen importlib._bootstrap>", line 955, in _find_and_load_unlocked
web_1            |   File "<frozen importlib._bootstrap>", line 665, in _load_unlocked
web_1            |   File "<frozen importlib._bootstrap_external>", line 678, in exec_module
web_1            |   File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
web_1            |   File "/app/pm/urls.py", line 3, in <module>
web_1            |     import graphql_api.gen_urls
web_1            |   File "/app/graphql_api/gen_urls.py", line 4, in <module>
web_1            |     from graphql_api.schema import schema
web_1            |   File "/app/graphql_api/schema.py", line 57, in <module>
web_1            |     schema = graphene.Schema(query=Query, mutation=Mutation, auto_camelcase=False)
web_1            |   File "/venv/lib/python3.6/site-packages/graphene/types/schema.py", line 537, in __init__
web_1            |     directives,
web_1            |   File "/venv/lib/python3.6/site-packages/graphql/type/schema.py", line 208, in __init__
web_1            |     collect_referenced_types(query)
web_1            |   File "/venv/lib/python3.6/site-packages/graphql/type/schema.py", line 422, in collect_referenced_types
web_1            |     for field in named_type.fields.values():
web_1            |   File "/venv/lib/python3.6/site-packages/graphql/pyutils/cached_property.py", line 30, in __get__
web_1            |     value = obj.__dict__[self.func.__name__] = self.func(obj)
web_1            |   File "/venv/lib/python3.6/site-packages/graphql/type/definition.py", line 760, in fields
web_1            |     raise TypeError(f"{self.name} fields cannot be resolved. {error}")
web_1            | TypeError: Query fields cannot be resolved. 
web_1            | 

@syrusakbary any docs on how to upgrade between the two version would be greatly appreciated https://github.com/graphql-python/graphene-django/compare/main...Property-Meld:pm-forked

thanks

[xaralis]

@patrys Is there any recommendation on how to deal with data loaders when migrating from v2 to v3?

[patrys]

@xaralis I'm afraid not since graphene-django assumes everything is synchronous and grapqhl-core (rightfully) dropped support for Promise objects in favor of asyncio. My plan for moving to graphql-core 3.x is to drop graphene-django and replace it with explicitly defined object types. We already heavily depend on data loaders, so losing the ORM magic is not a big concern.

[felixmeziere]

@xaralis @patrys I did a quite extensive search of a solution for using data loaders in v3, I summarised my findings in this issue: https://github.com/graphql-python/graphene-django/issues/1263. Bottom-line: they work in graphene v3, used to work in graphene-django v2 but don't work in graphene-django v3 anymore, @jkimbo and @fabienheureux seem to be working on it but I don't know what the progress is. I'd be happy to help if I can... Data loaders seem like a requirement for a graphql ecosystem to be viable, so I think this issue is quite critical for the future of graphene-django !

[ace-han]

As I checked it recently, the pending task in todo list

Check dependant libraries: https://github.com/tfoxy/graphene-django-optimizer and https://github.com/eamigo86/graphene-django-extras

graphene-django-optimizer has been done its part to support V3 both for graphene and graphene-django via this pull

https://github.com/tfoxy/graphene-django-optimizer/pull/72

Just graphene-django-extras alone now. Carry on! Go go goooo!

[fabienheureux]

@ace-han I think I already brought support to graphene v3 a long time ago 🤔 It was released in 0.5.0, here is the PR https://github.com/eamigo86/graphene-django-extras/pull/148

[fabienheureux]

@felixmeziere about dataloaders, I will restart the work on this topic later this month I think, I am really busy atm. Most of my work is based on @jkimbo help though

[felixmeziere]

@fabienheureux interesting, thank you, tell me if you make progress/need help :)

[Ouradze]

Graphene just released the v3 :tada: https://github.com/graphql-python/graphene/releases/tag/v3.0.0

[felixmeziere]

Hi @jkimbo @mvanlonden any blockers to release this?

PS: @fabienheureux did you get a chance to have a look at those DataLoaders? :P

[ulgens]

@jkimbo and all the other people 🙂 What will we do with this release? It's more than two years.

[fabienheureux]

Sorry @felixmeziere I did not have the time to look into this yet 😞

[AntonOfTheWoods]

@jkimbo and all the other people slightly_smiling_face What will we do with this release? It's more than two years.

@ulgens I'm pretty sure most of the important people here have already moved on as users. @jkimbo has been doing lots of amazing work on https://github.com/strawberry-graphql/strawberry. Strawberry is a pleasure to work with, and I'm certainly glad graphene was in such a sorry state when I needed it, and so moved to strawberry. I'm literally only here to be a participant observer in an interesting phenomenon in the FOSS community - project death throes.

[ulgens]

@AntonOfTheWoods I started writing graphql APIs in Python with graphene-django and moved to Strawberry later. I was watching almost all of the core developers moving from graphene to strawberry, and I know it's not graphene's glory days anymore. Still, I think it would be nice to create a couple of maintenance releases to give enough time to people who want to move away from it.

[bellini666]

Just to add here, I think strawberry is a better project overall and I'm too migrating all of my graphene projects to it. But I agree with @ulgens that it could do a couple of maintenance releases to not only give people more time to move away from it, but also for people who are stuck with it for some reason (i.e. a very large system that would require a major rewrite to move away from it)

Considering that graphene itself just had a new release a couple of weeks ago, and also that graphene-django v3 is basically ready (the only remaining task is actually done, just not marked as so), a new release could be done here as well.

There are just 2 things that I think that would be nice to add to that release as well:

1. Add a note on the main page of the project stating that it is basically being discontinued and that people should seek other alternatives, like strawberry. It would be nice to add this note to graphene itself too.

2. Add support for django 4.0, which was just released this week. Probably not hard to do since there aren't any major breaking changes, just adjust a couple of deprecated stuff that got removed.

I think point number 1 is really important because graphene is still considered the "main" graphql lib for python. Search for "python graphql" on google and graphene is one of the first results, even before ariadne. Strawberry isn't even in the first page. So, someone not knowing of the current "deprecated" situation could easily invest his efforts with something that he will probably have to move away sooner or later.

(unless there's someone willing to maintain graphene to keep it alive... but I don't think there is based on the discussion here)

[tim-schilling]

2 Add support for django 4.0, which was just released this week. Probably not hard to do since there aren't any major breaking changes, just adjust a couple of deprecated stuff that got removed.

This work is ready in #1281 for graphene-django v3, and #1275 for v2.

[felixmeziere]

@bellini666 I kind of agree with this although @syrusakbary did seem at some point to want to revive the ecosystem (https://github.com/graphql-python/graphene/issues/1127#issuecomment-806119584) . Our project relies very heavily on graphene which is satisfactory appart for the lack of dataloaders. I really think it would be good to at least keep it in a state where it's compatible with Django and has data loaders. We are a small business with very little resources, the migration from graphene to strawberry could be very expensive for us (bring us to a halt for months).

The whole graphql ecosystem on python is built on graphene atm, I don't think we can afford to let it die...

[bellini666]

Hey @felixmeziere ,

Yeah, don't take me wrong on my comment, I would very much prefer that graphene was kept alive, but that means that someone needs to be able to maintain it, and this issues looked like to me that was concluding that "no one would like to maintain it".

I for example am the author of https://github.com/0soft/graphene-django-plus, an extension that I created to make it easy to create CRUD mutations for graphene django as easily as possible as graphene-django's DjangoObjectType does for queries, while also providing some useful functionality like permission checking and automatic optimizer integration. I would love to continue adding functionality to it, but since I'm migrating to strawberry, I'm putting my efforts on it and on any integration that I create for it.

I totally plan to at least provide bugfixes and adjustments to make it work with the latest graphene/graphene-django versions available (e.g. I'm waiting for graphene-django 3 to be released to port it and also make a new release there), but it is as far as I can go. Other than that, I'm very opened to review and release any new features that anyone wants to contribute there.

But that's me and my way of thinking. Others will think differently and each one has its right to do so...

So, to not let it die, either of those 3 things needs to happen:

1. The people responsible for it right now can/will spare some time to at least make sure it "works" with the advent of new python/django releases, even if that's the only thing that is going to happen and no new features are going to be added. This is the situation where a "deprecated" info and a "use strawberry/whatever if starting a new project" would be nice still.

2. Someone (or a group of people) comes in and "adopts" the project, to maintain it and add new features to it. (obs. initially I was thinking in volunteering, but the fact that strawberry stole my heart made me give up).

3. As you pointed out in https://github.com/graphql-python/graphene/issues/1127#issuecomment-806119584, the project can get funded enough to be able to hire a full-time developer to maintain it, but there's a lot fo be done to get to that point it seems.

So, 1 seems doable with a small effort (it only depends on the current maintainers and their disposition). 2 also seems doable with some higher effort, as long as there's people interested. It looks like to me that 3 is not doable in the short/medium term.

[JSv4]

@bellini666, the way I found this thread was via your note in the graphene-django-plus repo (cool project btw). I do appreciate the heads-up and wish I had known about all of the above discussion sooner. That said, those kinds of deprecation warnings before a project is right and truly dead (there was a release just a few months ago) will only accelerate the process. Perhaps that's the point though?

[bellini666]

@bellini666, the way I found this thread was via your note in the graphene-django-plus repo (cool project btw). I do appreciate the heads-up and wish I had known about all of the above discussion sooner. That said, those kinds of deprecation warnings before a project is right and truly dead (there was a release just a few months ago) will only accelerate the process. Perhaps that's the point though?

Hey @JSv4, not really the point (wasn't expecting it to attract attention to this thread =P), but maybe that's actually good because it contribute to start focing an action to be taken, either to really acknowledge it as deprecated or for someone to step up.

I'm following this and the other thread at graphene repo and I sometimes see someone here and there commenting on wanting to help to keep it alive. I'm really hoping someone will :)

Also, glad to see you liked graphene-django-plus. I'm putting a lot of efforts on strawberry-django-plus now (clearly naming projects isn't my greatest skill :P) so, if you ever want to try strawberry, be sure to check it out!

[JSv4]

@bellini666, well, I'm glad it did attract attention as it seems the Graphene ecosystem is not as healthy as it would first appear from raw stats (going off of comments I'm seeing in the Slack and elsewhere). Tbh, I've never been a huge fan of Graphene's API, particularly the Django integration. It works, but I often do a lot of things manually with more boilerplate as I don't like the graphene-django magic. That said, Graphene's biggest advantage is the sheer number of libraries that are available for it (and the relatively tight Django integration, despite its flaws). Since you're moving to Strawberry, I wonder how you've found the options for 1) ORM integration, 2) auth (particularly JWT) and 3) permissioning. Do you have a recommended stack? I would love to try Strawberry, but I don't have time to rebuild a lot of the utility libraries I take for granted on Graphene (even if some have their issues).

[bellini666]

@JSv4 I did not find much alternatives since strawberry is indeed a young project. But having said that:

1. There's already an official django integration available which can be used for ORM integration. I would recommend my strawberry-django-plus lib, specially if you were already used to graphene-django-plus. It is based on the official integration, but I'm enhancing it a lot (e.g. It provides an extension that does sql optimization, much better than graphene-django-optimizer ever did). Take a look here for more information and some examples.

2. I'm planning on adding JWT to my extension there pretty soon (in the next couple of weeks)

3. Also something I solved in my extension, using schema directives. Take a look here for more information and some examples.

[Luferov]

Strawberry is too young project to “production ready” that wants to cover everything that is possible, there are fastapi, and flask, and whatever you want. I don't think this is a good solution. What about SqlAlchemy? Of course, there is enthusiasm because the project has just appeared. I really love Python and I also love graphql, they makes working with the frontend much easier. It's just that the library is already ready to switch to graphene3, a lot of people use it, I can't understand why can't switch to graphene v3. In addition, this library works well with Django-filter. There is an implementation of subscriptions: https://github.com/datadvance/DjangoChannelsGraphqlWs. We are currently developing convenient filtering on relay.

Pydantic and type annotation are a great idea for graphene_django v4.

[felixmeziere]

Guys from Graphene's Slack it seems the project might come back from the dead as it should

[cpontvieux-systra]

Well it was ONE month ago and nothing moved…

[felixmeziere]

Well it was ONE month ago and nothing moved…

We're slowly starting to get used to it...

[Luferov]

We decided to switch to nestjs, we will use subgraph there and migrate calmly from graphene. While graphql is not so developed in the Python community, to my great regret:(

[jedie]

We decided to kick graphene-django but stay with graphene for the moment.

[moritz89]

Looking at the todo list, it seems like all tasks are done for a v3 to be released. Is there anything blocking making a release?

[Luferov]

Looking at the todo list, it seems like all tasks are done for a v3 to be released. Is there anything blocking making a release?

The wish of the maintainers :smiley_cat:

[tcleonard]

I agree! Will try to get that out (I'm not sure I have the required permissions)

[ulgens]

@tcleonard I do 🌹

[dkruk]

Any chance to see this alive?