[iOS] 메이트러너: Firestore SDK 에서 REST API로

메이트 러너 앱 개발 과정을 공유하는 포스트입니다!

GitHub - boostcampwm-2021/iOS06-MateRunner: 함께 달리는 즐거움, Mate Runner 🏃🏻‍♂️🏃🏻‍♀️

여기서 저희 프로젝트를 더 자세히 볼 수 있어요!

 

그럼 시작하겠습니다!

 

앱이 너무 무거워요..

저희 팀은 서버 개발자가 없다 보니 최대한 API만으로 서버의 기능을 제공할 수 있는 서비스가 필요했고, 이런 기능들을 쉽고, 그리고 무료로 제공해줄 수 있는 서비스인 Firebase를 선택하게 되었습니다. 그런데 Firebase의 데이터베이스인 Firestore를 사용하기 위해서 SDK를 설치해야 했는데 이 때문에 빌드에 너무 많은 시간이 걸렸습니다.

그냥 빌드에서는 1분 30초 정도 걸리고, 테스트배포를 위해 아카이빙을 진행하면 10분 정도 걸렸습니다.

 

또, SDK의 용량이 60MB정도 되어서 앱의 총용량이 100MB가 넘어가는 문제가 생겼습니다.

 

REST API 있다던데?

SDK 때문에 알게모르게 스트레스를 받던 와중에 Firestore를 REST API로 사용할 수 있다는 사실을 알게 되었습니다. 그래서 안정성이 중요한 실시간 달리기를 제외하고 데이터베이스를 사용하는 Firestore 기능은 모두 REST API로 대체하기로 결정했습니다.

 

https://firebase.google.com/docs/firestore/reference/rest?hl=ko 

Cloud Firestore API  |  Firebase

아주 친절하지는 않지만 여기에 문서가 잘 정리되어 있어서 API를 구성하는건 크게 어렵지는 않았습니다.

 

충격과 공포의 Firestore JSON

단순히 정해진 엔드포인트로 요청을 보내고 응답을 받아 파싱만 하면 될 줄 알았는데, 생각보다 훨씬 더 단순하지 않았습니다.

Firestore에 GET 요청을 보내면 특정한 문서에 대한 응답을 이렇게 주는데요, 뭔가 심상치 않다는 걸 눈치채셨나요? 

 

모든 값들이 어떤 타입인지를 포함하는 JSON 형태로 한번 더 래핑되어서 들어옵니다. mate 같은 경우도 저희가 기대했던 건 

"mate": ["a", "b", "c"]

이거였는데 말이죠...

 

사실 응답을 받아서 디코딩 하는건 괜찮지만, POST나 PATCH 요청을 위해 바디에 담아야 하는 JSON 역시도 동일한 포맷으로 만들어주어야 하다 보니 위 같은 형태로 디코딩과 인코딩이 모두 가능하도록 만들어야 했습니다. 

 

각 타입을 인코딩/디코딩하기

이제 그냥 딕셔너리로 JSON을 디코딩할 수 없고 특수한 타입을 필드로 가진 형태로 만들어주어야 했습니다.

그래서 이런식으로 기본 타입들을 Firestore에서 주는 형태에 대응되어 인코딩하고 디코딩할 수 있는 특별한 타입들을 만들어주었습니다. 중간에 IntegerValue의 value 가 String인 거 보이시나요? 진짜 미쳐버리는 줄 알았습니다ㅋㅋㅋㅋ 근데 진짜로 문자열로 줍니다..

도대체 왜...

이제 저 타입들을 이용하면 파이어베이스가 원하는 대로 디코딩과 인코딩이 가능한데요, CodingKey에 필드에 대한 키를 주었기 때문에 이런 식으로 만들어집니다.

{
	"stringValue" : value
}

 

근데 여기에 실제로 이 값이 어떤 필드에 대한 값인지 그 키값이 또 필요하겠죠.. 

{
	"name" : {
		"stringValue" : value
	}
}

이런식으로요.

 

그래서 파이어베이스에 올리고 받는 특수한 타입들, 달리기 결과, 프로필 정보 등을 DTO로 만들어주었습니다.

DTO 설계

DTO는 기존 모델에서 파이어베이스로 올릴 때는 위의 끔찍한 JSON의 형태로, 받았을 때는 모델로 변환해주는 객체의 역할을 하게 됩니다. 

 

위 예시 같은 경우는 사용자 정보에 대한 DTO인데요,

파이어베이스의 최상위 키값은 항상 "fields"로 시작하기 때문에 코딩 키에 fields를 주고, 그 하위 필드에 대한 키와 그 값을 기본 값에 대해 정의한 StringValue, IntegerValue 등으로 한번 더 감싸서 JSON과 같은 포맷이 만들어지도록 했습니다.

 

그래서 디코딩을 할 때는 fields로 한번 중첩된 JSON 구조를 풀어주고, 그 내부에 있는 필드들을 nestedContainer로 디코딩할 수 있도록 했습니다.

 

반대로 인코딩할 때는 String, Double로 되어있는 데이터를 받아서 StringValue, DoubleValue로 한번 바꾼 뒤에 DTO의 프로퍼티에 넣어주었습니다.

이렇게 하면 DTO를 JSON으로 인코딩했을 때 파이어베이스로부터 받았던 JSON과 동일한 형태가 완성됩니다.

모두를 위한 레파지토리 API 만들기

저희 팀은 꽤나 많은 부분이 SDK로 이미 구현된 상태에서 REST API로 전환해야 했기 때문에 기존 기능들에 대응되는 REST API를 모두 포함하는 Firestore REST API 레파지토리가 필요했습니다.

그래서 이렇게 프로토콜에 주석처리를 통해 어떤 파라미터가 필요한지, 반환 값이 어떻게 되는지 명확하게 명시해두었습니다.

그리고 전체 API 목록에 대해 MARK를 명시해서 원하는 정보를 쉽게 찾을 수 있도록 정리해두었습니다.

 

레파지토리 API에 대해서는 이 PR에 더 자세히 정리해두었습니다!

https://github.com/boostcampwm-2021/iOS06-MateRunner/pull/217

RestAPI 요청 레파지토리 구현 by jeonyeohun · Pull Request #217 · boostcampwm-2021/iOS06-MateRunner

 

저희 팀이 초기 설계를 잘해둔 덕분에 SDK에서 REST API로 중간에 변경이 되었음에도 불구하고 기존 코드는 크게 손댈 필요 없이, 유즈 케이스에 있던 레파지토리만 새로운 레파지토리로 변경하고 반환 타입을 기존 로직에 적용할 수 있는 코드만 조금 수정하면 되었습니다.

 

REST로 바꿔서 얻은 것

조금 시간은 걸렸지만 결국 Firestore에 대한 모든 SDK는 REST API로 대체할 수 있었습니다. 그리고 빌드 시간은 28초 정도로 크게 줄었고, 아카이빙도 2-3분 내외로 엄청나게 가벼워졌습니다!

앱의 용량도 40MB 정도로 더 가벼워졌습니다.

마무리

SDK를 사용하면 정말 편하긴 하지만, URLSession을 통한 네트워킹도 직접 경험해 볼 수 없고, 앱이 무거워진다는 단점이 있었습니다. REST API로 바꾸는 과정이 쉽지는 않았지만(실제로 이틀 정도는 시뮬레이터는 켜보지도 못하고 Postman과 함께 했습니다..) 인코딩/디코딩을 진하게 경험하고 주어지는 웹 API의 응답을 앱의 상황에 맞게 처리하기 위해 깊게 고민도 해볼 수 있는 좋은 기회였다고 생각합니다. 

 

읽어주셔서 감사합니다! 저희 앱이 더 궁금하시다면 깃허브에 방문해주세요!

GitHub - boostcampwm-2021/iOS06-MateRunner: 함께 달리는 즐거움, Mate Runner 🏃🏻‍♂️🏃🏻‍♀️