Server Sent Event
•
WebSocket의 경우 Event를 통해서 양방향 통신이 가능했었는데, SSE의 경우 일방적으로 Server로 부터 데이터를 계속 받아오는 것을 말한다. WebSocket을 이용해도 무방하긴 하다.
npm install sse
•
일반적으로 SSE의 경우, Client의 데이터들을 모두 믿지 않고 오로지 Server에 집중하여 Client들을 관리하고 싶을 때 사용하게 된다. (socket.io와 이용 방법이 유사하다.)
•
예를 들면, 수강 신청의 경우 해당 Server의 시간을 이용하게 된다. 따라서 해당 Server로 부터 시간을 읽어와서 보여주는 Service 들도 SSE와 같다.
•
SSE를 사용하기 위해선, Frontend에 Event Source Policy를 명시해야 한다. (Code 참고하자.)
Scheduling 구현하기
•
Scheduling과 같이 예약 이벤트에 대한 처리를 위해 node-schedule이라는 Package를 이용한다.
npm install node-schedule
•
setTimeout() Method로도 가능은 하지만, 정확한 시간으로 이용할 수 없기 떄문에 위 Package를 이용한다.
•
node-schedule Package는 로직을 처리하는 곳에서 사용한다. (Code 참고하자.)
•
sequelize에서 SQL을 직접 사용할 때, sequelize.literal() Method를 사용한다. (직접 SQL을 사용해야 하는 경우는 연산에 대한 Update일 때 주로 사용한다.)
•
node-schedule을 통한 Scheduling은 setTimeout() Method에 비해서 정확한 시간에 대한 예약 작업이 가능하지만, Server의 메모리에 Scheduling이 저장된다. 이러면, Server가 죽어버리거나 재시작을 하면 Scheduling이 작동하지 않게 된다. 따라서 이에 대한 처리를 따로 해줘야 한다. (Server가 시작할 때, 놓친 Scheduling이 있는지 찾아서 이를 처리해주는 로직을 사용하는 것도 좋지만, MongoDB와 같이 agenda라는 Package를 사용하는 것도 좋다.)
** node-schedule외에도 agenda, cron, crontab 등등 Package들이 많다.
스스로 해보기2 (경매 시간 자유 조정)
•
데이터베이스를 변경하기 위해선 Migrate를 이용해야 한다. 이용 방법은 다음과 같다.
1.
sequelize migration:create —name $migrationName
2.
생성된 migration File에서 up, down Method 작성 (up → Migrate, down → Revert)
3.
sequelize db:migrate (여기서 만일 down Method가 작성되어 있고 Migrate를 취소하고 싶다면, sequelize db:migrate:undo를 사용한다.)
4.
Migration을 통해서 데이터베이스를 수정했다면, 매 시작마다 호출되는 sequelize.sync()에도 동일한 Model이 적용될 수 있도록, Model에도 수정사항에 대해서 작업한다.
** allowNull: false와 default를 같이 쓰지 않도록 한다.
스스로 해보기3 (Scheduler 재시작)
•
Scheduling을 데이터베이스에서 관리하여 Server가 재시작 되었을 때, 데이터베이스에 남아 있는 작업들이 있다면 이어서 Scheduling을 하게 할 수도 있다.
•
혹은 지금의 방법 처럼 Server가 재시작할 때마다, 데이터베이스 내의 시간을 확인하면서 Scheduling을 하도록 할 수도 있다.
•
사실 이 방법은 문제가 좀 있다. 지금 하고 있는 프로젝트를 예로 들면, 경매 시간이 아직 끝나지 않은 작업에 대해서 Server가 재시작 될 때 문제가 될 수 있다. 해당 경우, Server의 재시작으로 Scheduling은 멈추게 되지만 멈춘 Scheduling에 대해서 다시 시작하기 위해선 한 번 더 Server의 재시작이 필요하다. 즉, Server가 다시 한 번 더 재시작 하지 않으면 경매는 지속되는 것이다. 따라서 Scheduling들은 데이터베이스에서 관리를 하고, Server의 재시작 때마다 남아 있는 Scheduling들을 처리하는 방법이 예외 없이 깔끔하게 처리 될 수 있는 것이다.
•
위와 같은 문제를 해결하기 위해서 만일 현재 프로젝트와 같이 Scheduling에 대한 별도의 데이터베이스를 두지 않고 시간으로만 검증을 하게 된다면, 끝난 작업에 대한 완료 처리 및 Scheduling의 재시작이 필요한 것이다. (여기까지 해준다면, 데이터베이스를 두고 사용하는 것과 동일하게 처리할 수 있는 것이다.)