개발 고민해보기

오늘은 쉬는날이다 ㅎㅎ 근데 이번주에 유난히 쉬는 날이 많아져서 쉬는 날이여도 조금씩 해야할 듯 싶다. 

 

일단 상황은 다음과 같다.

프론트에서 lexorank 를 도입했을 때의 문제점

프론트에서 모든 투두 및 하위투두, 그리고 category 를 가지고 있어야 한다.

근데 거기서 문제가 발생한다.

async strorage 가 어떻게 동작하는 지 모르나 가끔 투두가 이미 있음에도 아무런 투두를 만들었지 않다고 하며 중간 값을 반환하는 경우가 있음.

이렇게 되어서 가끔 투두가 안만들어지는 치명적인 에러가 발생한다.

 

그러므로 결론적으로 프론트의 부하도 줄일겸.. 그리고 앱이 작동하는데 큰 문제가 없도록 다음의 오픈소스를 사용해보려고한다.

https://github.com/rozumdev/django-lexorank

GitHub - rozumdev/django-lexorank: This package implements an algorithm similar to JIRA's lexorank, but without using buckets fo

여기에는 무려 rebalancing 이 있다! 최고최고

 

사실 저번에 사용하긴 했었는데 모델을 상속받는게 무서워서 기피했었다. 그런데 지금 생각해보니... 그렇게 무서워할 건 없었는데.. 

지금은 모델에 대해서 더 많이 알아서 그런 거라고 사고를 바꿔본다....!

 

그래서 일단 바꾸는 편이 나을 듯 싶다. 바꾼다면 빠르게 바꿔야해서, 이 일부터 우선적으로 시행해야한다.

 

그리고 어제 궁금했던 사항에 멘토님 답변은 의외였는데 일단 질문은 다음과 같다.

storage 에 저장된 토큰을 데려오다 보니, dev 의 엑세스 토큰이 prod 에서도 같은 토큰으로 사용하게 됩니다… 여기에서 다른 계정으로 로그인하는 문제가 발생합니다…!

저희가 생각한 해결방법은 다음과 같습니다.

1. 환경을 구분해서 엑세스 토큰을 사용할 수 있도록 수정한다.
2. db 를 하나만 사용한다(dev, prod 같이 사용 (최대한 사용하고 싶지 않은 방법))
3. 아예 해결하지 않는다. (일반 사용자는 Dev에 접속하는 경우가 없으므로)

 

여기에 대한 멘토님의 답변은 3번도 괜찮고 2번도 괜찮다고 하셨다. 의외로 1번은 선택받지 못했다.

 

현업에서는 2번도 괜찮은게 배포를 할 때 다르게 설정해서 겹치지 않는다고 하시는데... 흡 내일 팀원분들과 이야기 해봐야 할 것 같다.

 

그래서 오늘은 lexorank 를 테스트 해볼 생각이다. 바꿀게 많을까... 싶은데 하긴 뷰를 전부 바꿔야하는구나....

 

오늘은 여기까지...