지난 편에 이어서,
우리의 프로젝트는 앱서비스로 RN을 지원하는 sse 라이브러리를 찾는 것부터 시작이었다.
나는 개발 공부를 시작하면서 지금까지 진행한 프로젝트에서 라이브러리를 선정할때 어떠한 기준 없이 막연하게 그냥 npm에서 검색했을때 누적 다운로드수가 가장 많은, 가장 최근까지 업데이트 된 라이브러리를 사용해왔다.
굉장히 리스키한 행동이었지만, 그럼에도 불구하고 큰 이슈 없이 잘 마무리 되었던 건 해당 라이브러리가 프로젝트에서 큰 비중을 차지하지 않고, 충분한 대체재가 있었기 때문이었다.(한마디로 운좋게 넘어간 셈😂)
반대로 우리가 설계한 서비스에서 해당 플로우는 시작단계였고, 굉장히 중요도가 높았기때문에 막연하게 선정했다가는 대참사가 날 것,,
동기 개발자분과 함께 서치 후,
react-native-sse라는 라이브러리를 사용하기로 했다.
우선, TypeScript를 지원하고 있었고, XMLHttpRequest를 sse를 연결하고 설정해 추가적으로 android나 ios구현(매우 중요)이 필요가 없었다.
(신입 개발자인 우리의 수준에서 가장 빠르게 구현이 가능할 것으로 판단했다.)
구현 과정 설계
우선 우리의 목표는 문자 인증을 통해 초기 토큰을 받아오는 것이었는데,
이 토큰들을 받아오기 위해서는 보이지 않는 자잘한 과정들이 필요했다.
 |  |
|---|
레퍼런스로 사용한 '핀다'앱의 moAuth UI
전체 플로우
- 우선 유저가 문자를 보내기 위해 버튼을 클릭하면,
- 해당 유저를 확인하기 위한 값을 인코딩해서 서버로 전달한 뒤,
- 서버로부터 sse를 열기위한 id값을 전달받고, 이때 받은 id를 통해 sse를 여는 api를 호출한다.
- 유저는 문자앱으로 이동해 암호화된 코드를 문자인증 서버로 전달하고,
- 문자인증 서버로부터 우리의 서버는 해당 데이터를 전달받아 그 데이터가 우리 서비스에 접근한 유저와 맞는지 확인한다.
(이때, 유저가 일치하면 서버는 유저의 연락처를 수집, 해당 토큰이 담긴 데이터를 반환한다.)
사수님께서 도식화된 자료와 함께 충분한 설명을 해주셨는데, 바로 와닿진 않았던 것 같다. 머리가 팽팽 돌아가는 느낌...
🔐 구현 코드
서버로부터 id값을 전달받았을 때 sse를 여는 api를 호출하면 되기 때문에, useEffect에 의존성 배열에 아이디를 넣어서 처리했다.
이때, sse의 특성상 클라이언트에서 페이지를 닫거나 연결되지 않은 경우에도 서버에서는 끊김을 감지할 수 없다고 한다.
그래서 꼭 마지막에 종료를 해줘야한다는 것, 처음에는 왜 연결이 안된 경우에도 계속해서 상태가 반환되는 건지 어리둥절, 동료 개발자분과 많이 헤맸다;
그동안 HTTP 통신에 너무 익숙해진 나머지 sse방식에서는 당연한 것이었다 😂
useEffect(() => {
const sseURL = "sse 호출 api 주소";
const es = new EventSource(sseURL, {
headers: {Accept: 'text/event-stream'}
});
es.eventListener("message", async evnet => {
/* 이벤트가 열렸을때 동작 */
})
es.eventListener("error", async evnet => {
/* 이벤트가 열리지 않을때 동작 */
})
return () => {
es.removeEventListener();
es.close();
}
},[sseId])🧨 구현 중 만난 블로커
우리가 가장 걱정했던 sse연결에서 해당 id값을 받아와 문자앱을 열어 보내기까지 겨우겨우 성공했다.
문제는 크로스플랫폼의 최대 단점, 두 플랫폼 중 하나만 동작할때,,, 대개 자유도가 낮은 iOS에서 발생하지만, 혹시나가 역시나였다 😂
안드로이드에서는 정상 동작했는데, iOS는 무한 로딩에서 멈춘 채 정상 동작하지 않는 이슈가 발생했다.
iOS를 담당하고 있었던 나에게 첫번째 시련이었다.
관련 내용은 3편에서,,,
