이번주의 좋은 점과 아쉬웠던 점이 무엇이 있었나요?
아쉬웠던 점이 있었다면 개선하기 위해 필요한 것은 무엇인가요?
-
회원가입, 인증을 마무리해서 홀가분한 것이 가장 좋았다.
-
유효성 검사를 어떻게 하면 깔끔하게 할 수 있을지 requestDTO와 Entity에 둘 다 해야하는 것인지 고민해왔다. 이번 프로젝트에서 팀원분이 하신 방법은 Entity의 각 필드를 값 객체로 받아서 값 객체 안에서 유효성 검사를 하는 것이었다. 너무나 인상 깊은 방법이었다! 나는 생각지 못한 방법을 코드 리뷰하면서 발견하고 소통하는 과정이 재밌었다.
-
9월 9일부터 API개발을 시작하면서 API 개발 목표를 타이트하게 잡았었는데 생각보다 회원가입, 인증부분에서 오래걸렸다. 다음부터는 회원가입, 인증부분이 시간이 더 걸릴것으로 예상하고 계획을 짜야겠다고 생각했다.
-
PR 작성할 때도 어떤 설명을 빼먹었는지 고민하는 등 시간이 꽤 걸렸다. 코드를 구현하면서 언급할 점을 미리 메모를 해두면 시간을 단축할 수 있을 것 같다.
-
추가적으로는 지난 2주동안 기획 회의를 할 때 말을 두서없이 하는 점이 고민이었다. 기획 기간이 지나니까 서로 개발하랴 소통할 일이 그렇게 많지 않았을 뿐더러 의견낼 일이 있으면 일단 텍스트로 먼저 정리하고 최대한 간단하게 말하려고 노력하면서 고민이 어느정도 해소가 되었다. 그래도 의견 낼 일이 많을 때 어떻게 하는 것이 잘 소통하는 것인지 계속 연구해봐야겠다.
이번주 진행했던 학습/개발 내용은 무엇이었나요?
- querydsl 공부
- 보호자, 유치원 Entity 생성
- 약관 조회 기능
- JWT 토큰 인증, 발급 기능
- 일반회원, 유치원 인증 객체 통합
- 회원가입 기능
- 로그인 기능
저번주에 개발되었던 코드들 리팩토링도 틈틈이 했다.
- 리팩토링 예시) 응답 객체 수정
어차피 error(String errorCode) 메소드도 error(String errorCode, String message)를 이용해서 return을 하므로 error(String errorCode, Stirng message) 에서 null 처리하는 게 낫다고 생각했다.
APIExceptionHandler에서도 error(String errorCode, String message)가 쓰이므로 error(String errorCode, String message) 에서 null 처리를 하는 게 맞다고 생각한다.
public static Response<Void> error(String errorCode) {
return errorCode == null ? null : error(errorCode, null);
}
public static Response<Void> error(String errorCode, String message) {
return new Response<>(errorCode, message, null, null);
}->
public static Response<Void> error(String errorCode) {
return error(errorCode, null);
}
public static Response<Void> error(String errorCode, String message) {
if (errorCode == null) {
return null;
} else {
return new Response<>(errorCode, message, null, null);
}
}가장 고민을 했던 부분은 무엇이었나요?
[API 관련 고민]
개발을 할 때 API CALL과 SQL CALL 이 적은 게 좋다고 생각해서 프론트 화면에 의존적인 API를 개발해왔다. 이번 프로젝트에서도 그렇게 했는데 나중에 이메일 인증, 유치원 사업자 등록증 인증을 하게 되면 정보 수정 페이지가 변할텐데, 그럴 경우에는 API 구조를 바꿔야한다. 이래서 화면에 의존적이지 않은 API를 만들어야하는구나 체감할 수 있었다.
이걸 고민하면서 많은 stackOverflow 의 답변들을 읽어봤다.
참고한 답변들
- https://stackoverflow.com/questions/43729695/rest-api-relationships-pros-cons-of-fetching-modularly-multiple-requests-vs-i
- https://stackoverflow.com/questions/16888975/multiple-restful-web-service-calls-vs-mysql-joins
- https://www.reddit.com/r/golang/comments/r642wm/multiple_queries_vs_joins_fetching_and_handling/
- https://softwareengineering.stackexchange.com/questions/341872/rest-api-design-multiple-calls-vs-single-call-to-the-api
- https://stackoverflow.com/questions/9363993/a-single-query-with-many-joins-in-one-api-request-or-a-few-queries-with-some-jo
- https://www.reddit.com/r/golang/comments/ow8gc3/should_i_create_multiple_apis_that_each_do/
- https://stackoverflow.com/questions/34655884/rest-return-complex-nested-data-vs-multiple-calls
처음에는 seperate api calls 로 만들고 나중에 완전히 화면이 픽스가 되거나 성능상 이점이 뚜렷하다면 complex response 로 바꾸는 게 일반적인 것 같다.
[유치원과 일반 회원의 인증 객체 통합]
처음에는 유치원의 인증객체는 KindergartenDto, 일반 회원의 인증 객체는 ParentDto로 분리해서 사용하고자 했다(KindergartenDto, ParentDto는 UserDetails의 구현체). 개발을 하다보니 일기, 공지사항, 투약 의뢰서 등은 유치원, 일반 회원이 공통으로 접근할 수 있는 리소스라 api path로 접근을 제어할 수 없어서 컨트롤러 메소드마다 접근을 제어해줘야한다.
현재 securityContext 에 담겨있는 UserDetail 객체에서 authorities 를 확인하면 되는데, authorities 필드는 컬렉션으로 되어있어 깔끔하게 접근하기 어렵다. 이 문제를 해결하기 위해 KindergartenDto, ParentDto 에 RoleType 필드를 추가하는 방법을 고려했다. 그러나 이렇게 하면 유치원, 회원이 동시에 접근할 수 있는 api 에서는
public void test(@AuthenticationPrincipal KindergartenDto kindergarten) {
}
public void test(@AuthenticationPrincipal ParentDto parent) {
}이렇게 두개의 별도 컨트롤러 메소드를 작성해야된다.
이런 고민 끝에 유치원과 일반 회원에는 공통되는 필드들이 대부분이고, 유치원의 주소나 원장님 성함과 같은 정보는 인증 객체에서 필요하지 않다는 판단을 하게 되어 인증 객체를 하나로 통합하기로 결정했다.
이렇게 수정한 후
public void test(@AuthenticationPrincipal UserDetailsImpl userDetails){
// userDetails.name()
// userDetails.role() // RoleType.KINDERGARTEN, RoleType.PARENT
// userDetails.email()
// userDetails.id()
}유치원, 일반 회원 모두 하나의 컨트롤러 메소드로 로그인한 유저의 정보에 접근할 수 있게 되었다.
[SecurityFilter 코드 정리]
API path로 접근 제어를 하는 코드에서 추가할 api path가 많아지면 코드가 더러워질 것 같다. security filter 코드를 어떻게 관리하는 것이 좋을지 레퍼런스를 찾아봐야할 것 같다.
다음주는 어떻게 보낼 예정인가요?
- 일반회원 api 완료
- 유치원 api 완료
- 반려견 api 완료
가 목표입니다.
