-
Notifications
You must be signed in to change notification settings - Fork 11
[회의록] 2019 12 02
- 개발은 어느정도 마무리 되어 간다.
- 기술적으로 어필할 것이 부족하다.
- Oauth는 이제 시작해야 한다.
정호 Apollo를 사용해서 얻는 것과 잃는 것을 명확히 해야할 필요가 있다.
공부 시간 대비 얻는 것이 충분히 많다면 하는 것이 옳되, 공부 시간이 지나치게 많이 소요가 된다면 Apollo를 제하고 다른 최적화 이슈에 투자하는 것이 맞다고 본다.
재현
소영 어떤 것을 캐싱하는 것이 좋은지 확실히 하여야 Apollo에 재한 전력을 세울 수 있을 것 같다.
캐싱 우리에게 캐싱이 어디에 얼마나 어떻게 필요한지를 분석하는 것이 필요하다.
에러 처리 graphql -> Apollo를 이용한 에러 처리
- asterisk 를 사용하지 않는다.
- n 백명을 follow할 때 최신 게시글 m개만 가져오는 빠른 방법.
이건 소영이가 할거임
검색 기능외에는 Elastic Search가 사용되지 않는다. 검색 기능 내에서도 필터링이 있지도 않고 검색 요소가 많지도 않기 때문에 learning curve 을 고려했을 때 제하는 것이 나을 것 같다.
현 프로젝트의 많은 부분이 무한 스크롤링 + 컴포넌트 리스트를 처리해야 하는데, 이에 대한 최적화가 필요하다고 생각하여 react-virtualized 모듈을 사용해보는 것이 좋을 듯하다.
반대 현재 DM을 한다는 것은 웹소켓을 도입한다는 의미이고, 웹소켓에 대한 공부와 깊이있는 이해가 과연 남은 시간 내에 가능한 것인가 의문이 있다. 동시에 DM기능을 할 경우, 알림 기능에도 실시간 기능을 추가해야 하는 상황이기에 시간상 불가능할 것 같다.
반대 첫 째. DM을 하려면, 깊게 하는게 아니면 하는 의미가 없다. 두 번째. 그냥 단순 구현만 하더라도 절대적인 시간 소요가 상당할 것 같다. 따라서 프로젝트 전반의 깊이가 얕아 질 것 같아 반대한다. (never)
반대 위 두사람과 비슷한 의견임. 인스타그램에 좋은 기능들이 많지만 우리의 시간은 2달이 채 안되는 시간으로 한정되어있고 우리가 할 수 있는 활동의 양도 정해져있다. 활동의 양을 DM에 할애한다면 기능은 많아지겠지만 다른 기능들의 깊이는 상대적으로 얕아질 수 밖에 없다고 생각한다. 현재 상황에서는 그런 것 보다 다른 기존 기능에 활동의 양을 할애해서 깊이를 늘리는 것이 중요하다고 생각한다.(none에 가까운 should였으면 함.)
반대 첫 번째 이유는 정호와 비슷하게 우리의 결과가 단순히 많은 기능들의 나열이 아닌 깊이 있는 기술들이 적용된 기능들로 나와야 된다는 점에서 DM를 적용하는 것은 현재 상황상 어려움이 있어보인다.
두 번째 이유는 최적화 이슈가 사실상 앞으로의 최대 이슈일 듯 보이는데, Apollo의 적용여부가 아직 결정되지는 않았지만, 최적화를 위한 여러 기술들의 공부가 만만치 않아 보이기 때문에 DM를 구현하는 데 시간이 부족해 보인다.
세 번째 이유는 앞으로 역할 분담이 OAuth 2명, SNS 2명으로 나뉠 예정이기 때문에 DM를 완벽히 깊게 구현할 정도의 인원이 되지 않는다.
should로 하되, 만약 최적화 이슈가 일찍 정리가 된다면 남은 should 중에서 우선순위가 높은 should로 한다.
- 보안 이슈도 고민을 해보자
권한에 대한 기능을 하기 위해서는 비공개 계정에 대한 설정이 반드시 필요하다.
decorator 를 쓰거나 해서 묶어준다.
graphql에서의 에러처리를 정리한 블로그
에러를 어떻게 넘겨주고 어떻게 표출할 것인가
- 404 Error
- 500 Error
- 에러 페이지!!!