문득 유튜브를 보다가, 조회수와 좋아요 수가 실시간으로 바뀌는 애니메이션을 봤습니다.

 

절묘하게 찍은 좋아요, 조회수 증가 애니메이션

 

 

최근에 롱폴링과 SSE, 소켓 등에 대해 알아보고 서비스에 맞는 기술을 적용해보면서 왠지 롱폴링으로 정보를 업데이트할 것 같아서 유튜브의 네트워크 요청을 염탐해보았다.

 

유튜브의 정보 업데이트 요청

 

https://www.youtube.com/youtubei/v1/updated_metadata?prettyPrint=false

 

위의 POST 요청으로 데이터를 받아오고 있었다.

확인해보니 약 20초 간격으로 폴링하고 있었다.

 

그냥 단순한 궁금중이었지만 이 기능을 개발하면서 개발자는 무슨 생각들을 했을까?

 

1. 몇초 간격으로 폴링을 해야할까?

이 고민은 DevOps 부서와의 협업이 필요하지 않았을까?

가상 유저를 두고 요청 시나리오 테스트를 해보면서, 가용 가능한 횟수를 지정한 후 재요청 간격을 정하지 않았을까 싶다.

 

 

2. GET 요청 / POST 요청 어떤 방식으로 해야 할까?

처음에는 당연히 데이터를 받아오는 요청이므로 GET을 사용할 것이라고 생각했다.

 

하지만, 실제로는 POST 요청을 사용했었다.

왜 그럴까 실제 네트워크를 둘러보았는데, 요청의 payload를 보고 고개가 끄떡여졌다.

 

서버로 보내는 데이터가 너무 많았다.

이 데이터들을 GET 요청의 쿼리로 보내면 너무 길어질 것이다.

실제로 HTTP 표준상, 쿼리의 길이에는 제한이 있긴 하지만 엄청 긴 것으로 알고 있다.

하지만, 이렇게 많은 데이터를 쿼리로 보내면 디버깅 하기도 힘들어 보인다.

 

RESTFul한 API를 설계하는 것이 중요하긴 하지만, 상황에 맞는 기술을 선택하는 것이 개발자의 덕목이 아닐까 싶다.

엄청 많은 payload

 

오늘은 심심해서 유튜브의 네트워크를 염탐해보았다.

개발할때는 다른 개발자가 내 요청을 볼 수 있다는 것을 항상 염두해두어야 겠다.

'끄적끄적' 카테고리의 다른 글

열심히 쌓은 잔디 기부하기  (2) 2024.12.26

+ Recent posts