Yes, a much simpler design is possible. It’s all a question of what features you’re willing to give up.
I have written websocket servers using the python websockets library as a custom Django management command. It allows me to add and retrieve data from a database using Django models, from a browser websocket connection. It was the simplest method I could come up with for that specific task. It actually works quite well.
Why should I write all that code when it’s already provided for me within the Channels environment?
So you’re not going to perform any authentication on the request? Anyone is going to be able to connect to your websocket server? (That is a valid approach in a number of different environments.)
I would say the “trouble” (I’d probably prefer the term “limitations”) with this type of approach is that for it to be truly usable, there’s a lot of code left to write.
I think an appropriate analogy might be along the same lines as a discussion around using DRF. If you have just one or two views that need to return JSON in your Django site, then DRF is probably a lot more than you need. However, if you’re building out a full API that needs to handle things like nested objects, token authentication, custom and selectable serialization formats, etc, then you’re better off using DRF.
I believe the same applies here. You can start out simple - like with a websocket server as I described above. But then as you keep adding functionality, you realize at some point what you’ve done is recreated “Channels-lite”.
For example, what specifically are the types of messages that you’re looking to transfer? Are you looking for messages to act as an RPC? That’s really a core feature of Channels - and probably its most significant function from my perspective.
Are you only returning JSON? Or are you looking to return HTML such as using Channels with HTMX? (Being able to call Django views is a plus there.)
What about handling transient connects/disconnects? (Always an issue if you’re working with mobile devices.)
So, only sending / receiving data from a browser? Sure, go the simpler route. But if you want real Django-integration with the rest of your Django project, I don’t see why you would want to build that yourself.