일단 왠만한 로직이 이미 구현되어 있지만 그냥 복사 붙여넣기 하기보다는 보면서 다시 작성하면서 리팩토링도 하고 로직을 천천히 이해해보자.
일단 이 서비스는 무조건 Strava의 API가 존재해야만 하는 프로젝트이다. 그랬었다. 하지만 꼭 그럴까? 이 프로젝트의 큰 문제점중 하나는 역시 외부 API에 의존해서야만 로직의 검증이 가능하다는 점이었다. 안그래도 API 호출하는것도 오래걸리는데 매번 코드를 다시 짜고 빌드하고 그 짓하는데 시간이 엄청 많이 들어갔다.
나는 지금 다른 프로젝트, 택배 배송조히 프로젝트에서도 마찬가지로 외부 API가 필수적으로 필요한 서비스 이지만 API로 가져올 데이터를 로컬에 저장하고 이 데이터를 가져오는 로직을 추상화 하여 실제 API환경이던 로컬 환경이던 동일하게 로직을 구성하여 테스트 시에는 빠르게 로컬 데이터로 테스트 할 수 있도록 설계 했다. 이것도 그렇게 할 수 있지 않을까?
하지만 아직 역시 구체적인 방법은 떠오르질 않는다. 우선 예전에 했던것 처럼 실제 API를 활용하는 코드부터 작성해보고 이를 점점 수정하면서 외부에 의존하지 않는 테스트를 작성해보자.
기본적으로 모든 로직의 시작은 사용자의 클라이언트가 Strava api에 요청하면서 시작된다.
이 API를 요청하게 되면 Strava 로그인 화면이 나오면서 로그인을 하게 되고 정보 공유 승인을 하면 API 파라미터로 넘겨준 리다이렉트 url로 해당 유저의 토큰에 접근할 수 있는 코드를 전달한다.
이 코드는 서버의 컨트롤러로 전달되어 서버의 로직이 시작되는 것이다.
우선 간단하게 어떤 정보가 서버로 넘겨저 오는지 출력해봤다.
여기서 우리가 사용하는 정보는 크게 Token과 athlete 이다 Token은 요청한 유저의 실제 데이터, 라이드 데이터에 접근할 수 있는 일종의 api key이다. athlete는 프로필 데이터이다.
Token은 access_token과 refresh_token으로 나뉘어지는데 access_token이 데이터에 접근할 때 사용되는 token이다. 하지만 이 token은 발급으로부터 6시간의 유효기간을 가지고 있어 유효기간이 지나게 되면 refresh_token으로 재발급 받아야 한다.
이제 access_token으로 실제 유저 데이터에 접근해보자