feat: ✨ personal general 에 dailyActivities 추가

[jpham005]

• 기존과는 다른 구조로 제작하였습니다. 앞으로 db 정리하고 이런 방식으로 고치면 어떨까 하는 생각입니다.

• daily_logtimes collection 을 추가했습니다.

• scale_teams, events_users 로 인해 성능 저하가 심각한 수준이면 별도 collection 으로 분리할 예정입니다. 현재 자체 테스트에선 dev 기준 100 ~ 300ms 정도 나옵니다.

• close daily logtime 을 위한 location 최적화 #388

• close scale team, events users daily record 추가 #389

---

위에 언급된 '기존과 다른 구조' 에 대한 자세한 설명입니다. 확정되면 관련 이슈에 옮길 계획입니다.

기존 방식

• page/xxx 에 resolver, model, service 가 있음
• xxx/service 는 api/yyy 에 있는 db 로직이 대부분인 yyy/service 를 사용함

장점

• collection 에 상관없이 원하는 collection 을 page 에서 사용할 수 있음

단점

• page, api 라는 이름이 직관적이지 않음
• page resolver, service 에는 로직이 거의 없고, api service 에 db query 문을 포함한 대부분의 로직이 존재함
• 사용하는 타입들에 대한 정의가 없어 계층 간 의존성이 강함
• 캐싱이나 page service 에서 사용할 인자에 대한 처리등 계층별로 필요한 로직의 위치가 불분명함

새로운 방식

• page/xxx 에 resolver, model 만 존재함
  • model 에는 실제로 resolver 에서 필요한 type 들만 정의
    • 후술할 yyy/dto 에 있는 타입은 재활용 가능
  • caching 은 resolver 로 이동
  • 인자 검증, 설정도 resolver 에서 진행
• yyy 에 (api 폴더 아님) service, dto, dao 정의
  • dto 에 dao -> service, service -> resolver 에 필요한 타입들 모두 정의
  • dao 에 query 로직 작성
    • 반환 타입은 무조건 dto 에 있는 타입을 사용
    • dao, daoImpl 을 분리하여 이후 impl 만 변경하면 되도록 설계

장점

• 계층 간 분리가 이뤄짐
• 기존 api service 에 있던 로직을 분리

단점

• cache 의 경우 기존에 사용하던 decorator 가 제대로 작동하지 않을 것으로 보임
• 기존 preload 캐시를 생각해보면 dao 에 캐시가 여전히 필요할 것으로 보이긴 함
• 루트 레벨에 폴더가 매우 많아질 것, 대신 하나 하나의 깊이는 얕아짐

database schema 위치가 고민입니다.

1. database 폴더에 schema 전부 정의하기 (aggregation, filter 등 util 함수 포함)

• 이게 제일 깔끔할 것 같긴 합니다

2. 적당히 yyy 들에 나눠서 만들기

• 폴더 수를 많이 줄여줄 것으로 보입니다

[jpham005]

이런 부분은 service 에서 처리했어도 좋았을 것 같네요.

[jpham005]

이게 graphql 상으론 표현이 되지 않는게 문제입니다.

[jpham005]

reviewer 부재로 자체 merge 합니다.