-
프로젝트명 : 킨더그루
-
주제 : 유치원이 아이의 교육에 보다 집중할 수 있도록 아이 관리를 지원하는 통합 관리 서비스
-
기간 : 2023년 3월 10일 ~ 2023년 4월 21일
-
프론트엔드 깃허브 : 킨더그루 FrontEnd
-
팀 노션 : 팀 노션 바로가기
-
팀원
이름 FE/BE Github 백주원 FE https://github.com/baekjoowon 황재연 FE https://github.com/yeonso08 우주호 FE https://github.com/Cupcakes33 홍예석 BE https://github.com/yshong1998 이상훈 BE https://github.com/strangehoon 김근호 BE https://github.com/GEUNHOKIM 김현호 BE https://github.com/cho-coding
접기/펼치기
-
1. 간편한 소셜 로그인
-
2. 등하원 관리 서비스
-
실시간 등 하원 처리
-
실시간 알림 기능(학부모 등,하원 카톡 전송)
-
-
3. 출결 관리 서비스
-
월별 출석부(+ 엑셀 내보내기 기능)
-
일별 출석부(+ 엑셀 내보내기 기능)
-
결석 신청 및 취소
-
- 4. 유치원 운영관리 서비스
-
반 별 갤러리
-
아이 정보 열람
-
- 전체회의시간: 저녁 8시
- BE 회의시간: 저녁 5시 30분
- 코드리뷰
- 이슈 공유하기
- 진행 상황 공유하기
- 적어도 회의 시간에는 비디오와 음성 키기
- 기능 단위로 커밋하기
- pr 템플릿 양식 준수하기
- Issue 템플릿 양식 준수하기
- 머지하고 나서 브랜치 꼭 지우기
- 풀 당기기 전에 패치하기
- 프로그래밍 컨벤션 준수하기
접기/펼치기
| 기술 | 선택지 | 이유 |
|---|---|---|
| Redis | 1. DB 저장 2. Redis |
유치원이라는 특성상, 선생님이 접속을 오래 하고 있기 때문에 Refresh Token이 필요하다고 생각이 들었다. Refresh Token을 DB에 저장 해서 사용을 해도 되지만, 그렇게 되면 스케줄러를 사용해서 직접 만료 된 Refresh Token을 삭제 해줘야 하기도 하고 , 캐시인 Redis가 더 가볍고 속도도 빠르고 TTL을 통해서 자동으로 삭제도 가능하기 때문에 Redis를 적용 해보기로 했다. |
| ImageIO | 1. Marvin open source Library 2. Graphics2D 3. ImageIO | 처음에는 이미지를 S3에 업로드만 했기 때문에 별도의 이미지에 대한 처리를 하지 않았지만, 이미지를 리사이징해야 할 필요성이 생기면서 이미지 리사이징 방법을 고민해야 했다. 가장 먼저 Marvin open source Library를 사용해 리사이징했지만 이미지가 심해게 도트화되는 문제와 프로젝트 전체 용량보다 marvin 라이브러리의 용량이 약 3배 더 컸으며, 처리 성능 저하 문제도 있었다. 따라서 java.awt 패키지의 Graphics2D 클래스를 이용해 별도의 라이브러리 추가 사용 없이 구현을 해 보았지만 성능은 개선되었지만 도트화가 더욱 심각해지는 문제가 있었다. 따라서 Graphics2D 대신 ImageIO클래스를 이용해 리사이징하는 방법을 채택했다. 도트화가 아예 없는 것은 아니었지만 다른 2개의 방법에 비해 정도가 낮았으며 별도의 라이브러리 설치도 필요없었고, 성능도 Graphics2D와 큰 차이를 보이지 않았기 때문이다. |
| 카카오 알림 기능 | 1. 프론트엔드에서 알림 구현 2. 백엔드에서 알림 구현 |
프론트엔드, 백엔드 모두 카카오 알림 기능을 구현할 수 있지만 다음과 같은 이유로 백엔드에서 처리하기로 했다. 1. 트랜잭션 단순 카카오 알림 기능 뿐만 아니라 아이의 등하원 상태도 바뀌어야 하므로 프론트엔드에서 처리 시 카카오 알림 메시지 API 뿐만 아니라 등하원 상태 변경 API도 필요했다. 하지만 서버에서는 API 하나로 같은 트랜잭션에서 처리할 수 있다. 이로인해 카카오 알림 기능과 등하원 상태 변경을 묶어서 일관성을 보장할 수 있었다. 2. 보안 카카오 메시지 API를 사용하는 경우, 보안상 중요한 kakaoId와 AccessToken이 필요하다. 이를 프론트엔드에서 처리하면, 이 정보가 브라우저에서 노출되거나 탈취될 수 있다. 따라서 백엔드에서 처리하면, 안전한 환경에서 이 정보들을 처리할 수 있다. |
| 복잡한 동적 쿼리 작성 | 1. JPA 쿼리 메서드 2. @Query 3. QueryDSL |
기존의 JPA 쿼리 메서드는 동적 쿼리를 작성하는데 한계가 있었다. 그래서 스프링 데이터 JPA의 @Query를 사용하려 했다. @Query도 동적 쿼리 작성이 가능하므로 좋은 대안이라고 생각했으나 그래도 주어진 문제에 적용하기에는 고려해야 할 조건이 너무 많다고 생각했다. 무엇보다도 가독성이 너무 떨어져 유지보수하기 어렵다고 생각했다. 반면 QueryDSL의 where 다중 파라미터 방식은 주어진 문제의 조건들을 동적으로 커스튬할 수 있을 거라 생각했다. 이 외에도 컴파일 에러를 잡을 수 있을 뿐만 아니라 @Query보다 쿼리 자체의 가독성이 훨씬 좋다는 점도 QueryDSL을 도입한 이유였다. |