Django Channels - Introduction

Scope란 connection의 정보를 뜻한다. remote IP, username, lifetime of connection등의 정보를 가지고 있다. Application은 한번의 scope당 한번씩 instantiate된다. HTTP에서는 각 request마다, socket에서는 각 WebSocket connection마다이다.

Consumer

각각의 프로토콜은 각자 다른 event들이 발생하며 이 event들은 메소드로 표현된다. 개발자는 각각의 event들을 어떻게 처리할지 코드만 작성하면 Django의 Channel이 스케쥴링과 병렬적으로 실행시켜준다.


class LogConsumer(WebsocketConsumer):

    def connect(self, message):
        Log.objects.create(
            type="connected",
            client=self.scope["client"],
        )
Channel은 asynchronous event loop을 기반으로 돌아간다.  하지만 위처럼 코드를 작성하면 synchronous thread에서 실행이 된다. 따라서 위의 코드처럼 blocking operation도 문제없이 잘 작동한다.
class PingConsumer(AsyncConsumer):
    async def websocket_connect(self, message):
        await self.send({
            "type": "websocket.accept",
        })

    async def websocket_receive(self, message):
        await asyncio.sleep(1)
        await self.send({
            "type": "websocket.send",
            "text": "pong",
        })
위처럼 작성하면 asynchronous하게 작동한다.


Cross-Process Communication

Application내에서 통신하는 것은 각 application바다 존재하는 application instance를 통해서 하면 되지만, application끼리 통신하는 것은 이야기가 달라진다. 데이터베이스 polling을 통해서 할 수도 있지만 Channels는 channel layer라는 개념을 도입했다. 각각의 application instance는 unique channel name을 가지고 있으며, group에 join할 수 있다.

# In a consumer
self.channel_layer.send(
    "myproject.thumbnail_notifications",
    {
        "type": "thumbnail.generate",
        "id": 90902949,
    },
)
위의 코드처럼 다른 process에게 broadcasting해줄 수 있다.



댓글

댓글 쓰기

이 블로그의 인기 게시물

[Django REST Framework] create() vs perform_create()

Django REST Framework의 ModelViewSet과 create() 관련 찾아보고 공부한 내용을 정리해보려고 한다. 기본적으로 ModelViewSet은 GenericAPIView라는 클래스를 상속받기 때문에 .list(), .create()  .list(), .create() 등을 기본으로 내장하고 있다. 따라서 이 중에서 기본 내장되어 있는 메소드 중 동작을 변경하고 싶은 것들만 overriding해서 수정하면 된다. 그리고 ModelViewSet은 GenericAPIView를 상속받고 있기 때문에 최소한 queryset와 serializer_class는 세팅해주어야 한다. from rest_framework import status from rest_framework.response import Response def create(self, request, *args, **kwargs): serializer = self.get_serializer(data=request.data) serializer.is_valid(raise_exception=True) self.perform_create(serializer) headers = self.get_success_headers(serializer.data) return Response(serializer.data, status=status.HTTP_201_CREATED, headers=headers) def perform_create(self, serializer): serializer.save() 위의 코드를 보면 이해가 조금 더 쉬울 것 같다. perform_create()은 create()의 동작 중 일부분을 overriding한다고 생각하면 되는데, serializer.save()가 호출될 때 perform_create()가 호출된다고 생각하면 된다. 위의 경우 명시적으로 perform_create()를 호출했지...
자세한 내용 보기

[Django 공식문서 번역] REST Framework - Viewset and Router

Viewset을 사용하면 관련된 view들을 하나의 클래스로 묶을 수 있다. class UserViewSet ( viewsets . ViewSet ): """ A simple ViewSet for listing or retrieving users. """ def list ( self , request ): queryset = User . objects . all () serializer = UserSerializer ( queryset , many = True ) return Response ( serializer . data ) def retrieve ( self , request , pk = None ): queryset = User . objects . all () user = get_object_or_404 ( queryset , pk = pk ) serializer = UserSerializer ( user ) return Response ( serializer . data ) from rest_framework import routers router = routers . SimpleRouter () router . register ( r 'users' , UserViewSet ) router . register ( r 'accounts' , AccountViewSet ) urlpatterns = router . urls 위의 예시는 아래의 URL 패턴을 만든다 URL pattern:  ^users/$  Name:  'user-list' URL pattern:  ^users/{pk}/$  Name:  'user-detail' URL...
자세한 내용 보기

[PostgreSQL 공부하기] PostgreSQL Index는 B-Tree를 어떻게 사용할까?

이미지
원문:  https://www.qwertee.io/blog/postgresql-b-tree-index-explained-part-1/ 원문:  https://en.wikipedia.org/wiki/B-tree Index의 목적은 적은 양의 데이터를 찾을때 disk I/O를 줄이는 것이다. disk를 검색하는 작업은 O(n)이지만 index가 유용하기 위해서는 그보다 더 빨라야한다. PostgreSQL의 default index는 B-Tree로 구성되며 좀 더 정확하게는 B+ Tree로 구성된다. B-Tree와 B+ Tree의 차이점은 key가 저장되는 방식에 있다. B-Tree에서는 각각의 Key들은  leaf node이든 non-leaf node이든 딱 1번만  저장되지만 B+ Tree는 모든 Key들은  leaf node에 존재하고 non-leaf node에도  존재할 수 있다.  Leaf Nodes Leaf Node는 table row을 가리키는 포인터를 가지고 있는  ROWID 와  key 를 가지고 있다. 각각의 leaf node사이에는 index key에 기반한 순서가 있다. 이 순서는 실제로 저장되는 physical order와는 독립적이다. physical order와 독립적이기 때문에 INSERT같은 작업을 하더라도 실제로 data를 옮기지 않고 몇개의 Pointer만을 업데이트하면 되기 때문에 작업을 빠르게 수행할 수 있다. 이렇게 logical order를 따라 저장되어 있기 때문에 오름차순과 내림차순 검색이 가능하다. Internal Nodes(Non-leaf Nodes) 위의 사진을 보면 좀 더 쉽게 이해가 될 것 같은데 internal node에는 pre-define된 범위가 있다. 그리고 포인터들은 각각의 범위안의 노드들을 가리킨다. 즉 위의 예시에서 7보다 작은 key들이 모여져 있는 노드들을 가리키...
자세한 내용 보기