실서비스 Django+Nuxt.js의 서버 구조 분석

일단 프론트의 구조입니다.

NGINX를 NUXT의 reverse proxy server로 사용
장점

1. 보안 : 서버가 털려도 proxy server가 털리기 때문에 괜찮다
2. 로드 밸런싱 : 내부 서버를 알고 있는 proxy server가 요청 분산 가능
3. 캐쉬처럼 사용해서 성능 향상 가능

두 번째로 백엔드의 구조입니다.

1. websocket : client의 요청을 받아야 server가 응답할 수 있는 http와는 다르게, client의 요청 없이도 server가 여러 client들에게 동시에 정보를 뿌릴 수 있게하는 프로토콜
2. channel-redis(asgi-redis의 업그레이드 버전) : redis를 저장소로 이용하는 채널 레이어
3. graphQL : django 안에 설치한 어플리케이션. postgreSQL에 쿼리를 날리기 위해 사용
4. redis(django-redis) : 쿼리를 캐싱하는 용도로 사용
5. RabbitMQ : Celery의 브로커 역할. django로부터 받은 task를 어떤 큐로 분배할지 결정.
6. redis vs RabbitMQ : 참조:https://www.linkedin.com/pulse/redis-vs-rabbitmq-message-broker-vishnu-kiran-k-v
7. Celery : 여러개의 큐로 구성됨. RabbitMQ로 부터 받은 task들을 처리
8. PostgreSQL : DB, 다양한 데이터 타입, 큰 용량 등등
9. Firebase : DB 용도로 사용(cloud firestore), subject app과 관련된 모델들을 여기에 저장https://firebase.google.com/docs/firestore/quickstart?hl=ko
10. Amazon S3 : 정적 파일과 미디어 파일을 보관해주는 AWS에서 제공하는 스토리지
11. boto3 : S3에 있는 파일들을 관리하게 해주는 API에 맞는 python 요청을 하게 해주는 패키지