20201119(목)_회고록

멘토링

• redis는 동기화하는 과정에서 주로 사용
• 서버를 여러 개 사용할 때 데이터 동기화를 위해 redis를 사용
• graphQl은 러닝 커브가 클 것이다.
• rx도 마찬가지
• 우선, 최소한의 요구사항을 모두 만족하는 것이 우선
• api를 호출하는 비용과 서버에서의 작업 비용 두가지로 생각할 수 있다.
• 민식님은 서버에서 하는게 더 낫지 않을까?
• 종원님은 반대 → 현재 프로젝트 정도에서는 어차피 sender가 Api를 한번 호출해서 서버에게 모든 번역을 전달하는 것이 좋을 거 같다고 말씀 하심.
• 타이핑 했을 때 번역 결과를 미리보여주는것을 하기에는 클라이언트쪽에서 하는 것이 더 맞지 않을까?
• 프로덕션으로 가면 서버에서 하는게 더 낫지않을까 라고 민식님이 이야기 해주심
• cra 탈락 → 웹팩은 어차피 해야한다 ^^
• 로컬 스토리지 사용 지양
• 디비를 통해 하는 것이 성능적으로 별로인 것 같으면 앞단에 레디스를 두는것도 하나의 방법이다.
• 일시적으로 메모리에 어느정도 쌓다가 디비에 넣어주는 식?
• 종원님은 언어설정 정도의 데이터는 로컬 스토리지에 저장해도 괜찮다
• 기본적으로 유저 디비가 없기 때문에 로컬 스토리지를 사용하는 것 말고는 방법이 없을 듯 하다.
• 방은 그냥 생성 삭제해라
• rx나 combine 그놈이 그놈이다. 둘 중에 하나만 마스터해도 둘다 가능하다.
• 리덕스는 과하다 라는 이야기가 있다. 현재는 좀 더 간단한 상태 관리를 위해 신기술이 등장하는 추세라고 함.
• 복잡한 기능이 필요없으면 thunk, 필요하면 saga 또는 observable

CI 계획

• jenkins에서 어떤 브랜치를 추적할지에 대한 토론
• ios, web이 같은 repository를 사용해서 생기는 고민
• dev 브랜치에 결국 핫픽스를 해주어야 하는데 그러면 web의 변경이 생겨도 ios에서 jenkins가 작동을 한다.
• 결론 : 다른 방법을 사용하면 git flow 방식이 아니거나 기타 등등의 이유가 있으므로 코드를 잘짜서 핫픽스를 최대한 줄여보자.