Channels is indeed a replacement for Celery if you're OK with not having delays, retry, or the other advanced options Celery has - Channels just requires an event to respond to, and this can be triggered by the user during a view much like a Celery task.
But yes, channels deliberately has an at-most-once delivery style, which will work for operations that aren't critical, or if people build their own retry logic (but at that point, maybe use Celery). Andrew On 16 Dec 2015 07:32, "Shai Berger" <[email protected]> wrote: > On Wednesday 16 December 2015 08:08:59 Markus Holtermann wrote: > > From my point of view the major non-functional difference is the > > interaction with a client in *some way*. While a celery task runs without > > any form of client, a channels method would mostly do that. Picture the > > following example: > > > > A user uploads an image. This could happen through the common > > request-response cycle. When the upload is done the server creates a > > celery task to generate a bunch of thumbnails and returns a http > response. > > But here is Ben's point: Why would you introduce an additional moving part > here (Celery), when the Channels documentation specifically mentions this > as a > use-case? > > If I get it right -- Curtis' description is spot-on; some tasks will still > need Celery, Channels will take care of many others. > > Shai. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFwN1uoyJT8r9kL4-rYNqyzQD2LC_9Y%3DaDjbPisA3GYoKzua3A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
