트러블 슈팅 & 고민 기록

puppeteer 사용 중 웹페이지의 중간 querySelector 어딘가에서 자꾸 null을 뱉었다. waitForSelector로 셀렉터 로드 될때까지 충분히 기다려도 timeout이 나는 상황. 처음엔 봇을 막나 하고 봇 디텍션을 우회하는 방법을 사용해봤다 (링크) 그래도 안 되어서 계속 찾아보니, DOM TREE 중간 어딘가에 아이프레임이 걸려있었다. 찾고자 하는 셀렉터는 iframe 내부에 있어 찾지 못했던것. 아래처럼 프레임 내부에서 처리해주면 된다.

puppeteer는 heroku에서 기본적으로 돌지 않는다. heroku가 도는 ubuntu os에서 puppeteer를 돌리기 위한 라이브러리가 부족해서인데, heroku buildpack을 사용해 수동으로 모두 빌드해야 하는줄 알았으나… @jontewks라는 분이 만들어놓은 빌드팩이 존재했다. 링크는 여기 단 빌드팩 하나만 올리면 안되고, node buildpack과 puppeteer buildpack을 동시에 셋업 해야 한다. 잘 알려진 문제인데, heroku node server의 포트는 헤로쿠가 동적할당하는 포트를 받아야 하므로, 다음과 같이 작성해야 한다.

Context yarn workspace의 루트에서 yarn으로 한번에 모듈을 설치했는데, subtree에서 참조하는 element-ui의 css파일을 실행시에 못 잡음 해결책 nohoist 옵션으로 element-ui만 서브트리에 두면 해결되었다…또르르 굳이 npm으로 다시 받아줄 필요가 없었던 것이다…

요구사항 페이지는 계층구조를 가지고 있고, 상위 페이지가 삭제되면 하위 페이지까지 개념적으로 삭제된다. 즉 페이지 하위에 페이지가 무한대로 있을 수 있는데, 상위 페이지가 삭제되면 하위 페이지까지 UI에서 보이지 않아야 한다는 이야기. 고민 포인트1 Hierarchy를 가진 비슷한 예로 대댓글이 무한대로 펼쳐지는 것을 생각해볼 수 있는데, 보통 댓글의 정책은 대댓글이 있으면 삭제를 막던가, 혹은 삭제된 단일 댓글에 대해서만 삭제된 댓글입니다 와 같이 보여준다. 그러나 페이지는 그렇게 처리할 수 없다. 단일 페이지는 단일 화면에서 보이기 때문이다. 보통 삭제 처리는 DB에서 관념적으로 flag 처리를 한다. 때문에 삭제와 복원이 매우 빈번한 페이지의 특성상 하위 페이지의 모든 flag를 바꾸는 것은 무리이다. 물론 주기적으로 batch job을 돌려 업데이트를 해줄 수 있지만.. 일단 보류해본다. 왜냐하면 삭제된 페이지를 복원했을 때, 자식이 실제로 삭제되지 않았으면 똑같이 복원되어야 하기 때문이다 😂 이 경우 플래그를 하나 더 두는 수밖에 없다. isParentDeleted 라던가.. 해결 => recursive query를 하위부터 상위의 방향으로 사용해서 삭제된 부모가 있는지 체크 고민 포인트2 페이지가 삭제되면 휴지통으로 이동하며, 이 페이지가 삭제되었는지 여부를 클라이언트에서 알 수 있어야 한다. 단순히 단일 페이지가(혹은 그 페이지의 먼 조상이)삭제되었는지를 체크할 때는, recursive하게 쿼리를 처리하면 된다. 하지만 페이지 정보를 불러오는 API에서 매 요청마다 recursive 쿼리를 요청하는 것은 오버헤드가 크다. 페이지 정보는 자주 불리기 때문이다. 또 삭제와 복원이 매우 빈번하기 때문에, 삭제 여부를 캐싱하기도 애매하다. 해결 => 삭제 여부를 체크하는 API를 별도로 분리해서 휴지통에서만 사용하도록 처리