Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

async support + async test-project #130

Open
benjaoming opened this issue Dec 12, 2023 · 3 comments
Open

async support + async test-project #130

benjaoming opened this issue Dec 12, 2023 · 3 comments

Comments

@benjaoming
Copy link
Member

This is a pretty hefty issue to report.

Firstly, async support should of course be part of a notifications application 💯

There's probably a lot of work to do to get there. I would suggest starting with a copy of test-project, let's call it test-project-async and start from there.

@oscarmcm
Copy link
Member

How are we going to handle if the user doesn't want to use async stuff? are we going to follow the same Django approach (prefix all the async methods with an a and then from the now async method call the async one but using async_to_sync?

@oscarmcm
Copy link
Member

How this affects Django-Wiki in the end?

@benjaoming
Copy link
Member Author

@oscarmcm yes, good question, I can't remember the conclusion but I think I saw a discussion about this in django-ratelimit, specifically which prefix to use for the new functions.

How this affects Django-Wiki in the end?

It should not affect django-wiki or any other deployments. I think that's a requirement that we need to follow. I can see django-nyt being very useful for other projects down the road... but it doesn't look good if current users are disturbed or async becomes a requirement. I like the simplest use-cases to get people started (i.e. no async and only a cron job to send emails).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants