More documentation on the view_as_consumer

[ElHombre87]

Please explain the uses for view_as_consumer.

There's no documentation to explain why one would use this, and the advantages gained from doing so.

Currently, I create a url pattern that uses the view_as_consumer. I import a DRF Model Viewset from .views

from djangochannelsrestframework.consumers import view_as_consumer
from .multiplexing import OpsDemultiplexer
from .views import ProfileViewSet

websocket_urlpatterns = [
    path('ws/multi/', OpsDemultiplexer),
    url(r"testing123/", view_as_consumer(ProfileViewSet)),
]

Then I import the url_pattern to the router.

application = ProtocolTypeRouter({
    'websocket': AuthMiddlewareStack(
        URLRouter(
            common.routing.websocket_urlpatterns + testing.routing.websocket_urlpatterns
        )
    ),
})

I'm not sure of what to expect at this point. How do I access the view? What are the perks of connecting to the view via websockets? Is it more efficient? Am I even doing this right?

I make use of the multiplexing, connecting multiple consumers via 1 path. I would like to incorporate the view_as_consumer if it will somehow make this process more efficient.

As of now, I use my DRF views for my HTTP requests. Does this wrapper replace that at all? Can one at least do GET requests? The only apparent feature I can think of is being able to have temporary views that are only accessible for the duration of the socket connection.

[hishnash]

view_as_consumer is used to expose a Django over a web-socket. So that you can send {action: 'retrieve', "request_id": 1}.

the action mapping is:

            "create": "PUT",
            "update": "PATCH",
            "list": "GET",
            "retrieve": "GET",

What are the perks of connecting to the view via websockets? Is it more efficient?

The main intention of this is to used it with a multiplexer so that you can have a single web-socket connection to your server and use it for many api calls. The overhead (in latency and data) is much lower than HTTP1.1 request. However if your users are connecting with HTTP2 then the use case of this is less compelling since the HTTP overhead is massively reduced with HTTP2.

Does this wrapper replace that at all?

It does not change your current HTTP api endpoints it just exposes them to a web-socket connection as well. In fact personal I keep my DRF views on regular HTTP endpoints so that normal rest clients can call them but I also expose them on a Multiplexed web-socket so that web-socket clients can access all of theses features.