Why there is a hardcoded channel name prefix events- in case of pushpin proxy

[montaro]

I was trying to send an event to a named channel test as in the docs, and this worked fine with the Channels setup. However, After configuration against fanout/pushpin proxy, messages are not delivered. After debugging, I found out that here the channel name is published to a different channel name with a hardcoded prefix events-!
What is the rationale behind this, please?

django-eventstream/django_eventstream/utils.py

Lines 89 to 90 in 35a9173

	publish(
	'events-%s' % quote(channel),

[jkarneges]

Django-eventstream uses prefixes to differentiate between different types of channels. The events- channels are for regular events (i.e. for events sent with send_event), but there are also user- channels for targeting specific users (see the code for publish_kick).

This prefixing is handled internally, so you shouldn't need to worry about it in your app. When a client is subscribed to a channel, the prefix will automatically be added.

[montaro]

@jkarneges I'm using the django-eventstream with fastly/fanout/Pushpin proxy without Django Channels and I have to handle this manually, i.e. I need to handle the hardcoded events- in the fastly Compute@Edge code because the whatever the channel name I use in the send_event() will get a prefix events-.
Is it really a desired behaviour in the setup without Django Channels?

[jkarneges]

It sounds like you might be writing your own handler code for Compute@Edge rather than deferring to the handler code from django-eventstream. Is that on purpose? The proper way to use django-eventstream with Fastly would be to have requests forwarded to your backend django app so they can be handled the usual way. You can use Compute@Edge code like this: https://github.com/fastly/compute-starter-kit-rust-fanout-forward

If you do mean to write code on Compute@Edge to substitute the handler code in django-eventstream, then yes you'll need to format channel names in the way django-eventstream expects, which should not be surprising.