부스트캠프 그룹프로젝트 2주차 회고

그룹프로젝트 2주차(= 멤버십 10주차)에 들어서 본격적인 개발을 시작했다.

1주차는 주로 기획에 힘썼기에 본격적인 개발은 이번 주부터였다.

RxSwift 공부는 다시 처음부터,

역시나 멤버십 7-8주차에 진행되었던 학습 스프린트 프로젝트에서 RxSwift 사용과 클린 아키텍처 적용에 많은 애를 먹고, 완전히 소화를 못했다보니, 유즈케이스, 뷰모델의 메서드 리턴 타입을 어떻게 해야할지에 대해 많은 고민이 되었다.

레포지토리에서 데이터를 받아온 뒤 로그인 성공 여부를 유즈케이스 -> 뷰모델 -> 뷰컨트롤러 -> 코디네이터 과정에 따라 전달해야 했는데,

 

'성공 여부를 전달하는 거니 단순히 Single<Bool> 타입으로 리턴하면 되지 않을까?'
'그럼 성공하면 .success(true) 실패하면 .failure(Error) 를 전달하면 되지 않을까?'
'그러면 실패하면 전달할 Error를 하나 만들어야 겠네? 귀찮은데...'

 

생각의 흐름은 이상한 길로 빠져,

 

'굳이 Error를 새롭게 파야할까? .success(false) 를 적용하면 어떨까' 하는 요상한 코드까지 생각하는 지경에 이르렀다. 🫣

func signIn(withApple authorization: ASAuthorization) -> Single<Bool>
...
  guard let fullName = appleIDCredential.fullName,
      let email = appleIDCredential.email else {
        single(.success(false)) // 이 무슨.... 🤦‍♂️
        return Disposables.create()
      }
...
}

 

볼 것도 없이 당연히 바로 리젝당하고, PublishSubject<Bool> 에 로그인 성공 여부를 넘기는 방향으로 수정되었다.

var isLoginSucceeded = PublishSubject<Bool>()
func signIn(withApple authorization: ASAuthorization) {
...
    useCase.sendLoginRequest(email: email)
           .subscribe(onSuccess: { [weak self] _ in
                    self?.isLoginSucceeded.onNext(true)
           }, onFailure: { [weak self] _ in
                    self?.isLoginSucceeded.onNext(false)
           })
           .disposed(by: disposeBag)
...
}

일련의 과정을 거치고, 여러 생각이 들었다.

나는 분명히 PublishSubject는 지식으로서 알고 있었는데, 왜 이를 활용할 생각은 못했을까.
한 번 3시간 분량의 RxSwift 강의 수강, 그 한 번의 수강이라는 다소 어설픈 행위로 어떻게든 적용해보고,
모르는 게 생기면 구글링을 통해 단편적으로 해결하려다 보니 이런 필수적인 지식의 활용마저도 머릿 속에서 희미해진 것이 아닌가 싶었다.

 

팀원 분의 조언을 듣고 바로 곰튀김님의 RxSwift 강의를 다시 정주행했다.

3주 전에 들었던 강의를 다시 들으니 전에는 다가오지 않던 개념들이 이번엔 더 확실히 다가왔다. 역시 반복이 개발이라는 영역에서도 필수이지 싶다.

애플 로그인

우리는 자체 서버를 도입하기로해 파이어베이스의 활용은 현재 제한적인 용도에 그친다. 이에 따라 애플/구글 OAuth 로그인도 파이어베이스 Auth를 사용하는 것이 아니라 자체 OAuth API를 이용해보았다. 작년에 파이어베이스 활용해서 애플로그인 할 때는 Nonce다, 뭐다 해서 상당히 복잡했던 것으로 기억하는데 역시 퍼스트파티 모듈을 임포트하고 공식문서에 나와있는 코드로 구현해보니 의외로 간단하게 성공했다.
다만 2가지 문제가 있었다.
첫째로, 애플 로그인 최초 진행 시(가입 시)엔 토큰(Identifier)와 함께 사용자 이름/이메일을 함께 전달받을 수 있었는데, 이후 로그인 시엔 토큰(Identifier)밖에 받을 수 없었다. 우리는 사용자 이메일을 이용하여 자체 토큰을 만들어 사용자를 식별하기로 결정했기에 이를 어떻게 해결해야 할 지 고민이다. 다음 주에 직접 만나 해결방안을 모색해보기로 했다.
또한 애플로그인 코드들을 클린 아키텍처에 입각하여 어디에 어떤 코드를 작성해야 할지도 문제다. 우리가 발견한 예시들은 뷰컨트롤러에 로그인을 담당하는 코드들을 모두 작성해놓았다. 클린아키텍처를 적용한 코드는 대부분 파이어베이스 Auth모듈을 이용하여, 우리가 이를 직접적으로 참고하기엔 제한되는 부분이 있었다.
로그인 관련 델리게이트 메서드들을 어떻게 뜯어 ViewModel, UseCase, Repository에 위치 시킬지 역시도 고민이다. 역시 다음주에 차차...