📮 개요

너는, 나는 프로젝트를 하며 약 3주간(10주차-12주차) 고민한 부분이 두 개 있었다.

1. 사용자 상태에 따라서 로그인 이후 적절한 페이지로 리다이렉트시키기
2. 사용자가 url로 특정 페이지에 직접 접근하는 걸 막기

이 두가지가 머릿속에서 합쳐져 어렵게 느껴졌고, 그래서 많은 고민을 했기에 고민한 과정을 기록해보았다.

이번 포스팅에서는 1번 리다이렉트 관련 문제를 다루고, 다음 포스팅에서는 2번 url 직접 접근 관련 문제에 대해 다뤄보려고 한다!

🔄 당시 로그인 이후 유저플로우

사용자가 메인 페이지에서 로그인 했을 때의 유저플로우는 아래와 같다.

<메인 페이지에서 로그인 했을 때>
1. 메인 페이지(/)에서 로그인에 성공하면 온보딩 페이지(/onboarding)로 이동한다.
2. 온보딩 페이지에서 서비스 안내를 받고(/onboarding?step=intro), 초대링크를 발급한 후(/onboarding?step=invite) 연인에게 링크를 전송한다.
3. 상대방이 초대를 수락할 때까지 기다린다.

처음에는 사용자의 상태가 로그인을 했는지, 안했는지만 고려했다. 그래서 로그인 버튼을 눌렀을 때 이미 로그인을 한 적 있는 상태면 무조건 대화 상세 페이지(/chatroom)으로 보냈다. 그리고 로그인을 처음 한 상태면 무조건 온보딩 페이지(/onboarding)으로 보냈다.

💥 발생한 문제들

1. 초대링크 전송 이후의 리다이렉트 문제

당시 발생한 첫번째 문제점은 온보딩 과정에서 상대방에게 초대링크를 보내기까지만 있고, 그 후 대화 상세 페이지(/chatroom)으로 이동하는 로직이 없다는 거였다.

기획을 할 때 커플이 맺어지면 대화 상세 페이지로 이동된다!고만 생각했었는데, 기술적으로 어떻게 구현할지는 생각하지 못했다.

그래서 이때 생각했던 해결방법은 nn초에 한번씩 대화 상세 페이지에서 대화 목록을 받아오는 요청을 보내는 거였다. 커플이 맺어져있지 않으면 요청이 실패할 것이었으므로 그대로 있고, 커플이 맺어지면 요청이 성공할 것이므로 대화 상세 페이지로 이동시켰다.

잘 동작했지만, 아래와 같은 두가지 문제점이 있었다. 그래서 다른 방법을 생각해보기로 했다.

1. 커플이 맺어졌는지 아닌지를 판단하기 위해 전혀 상관 없는 대화 목록 api를 쓰고 있다.
2. nn초에 한번씩 요청을 보내서 확인하는 것이 성능상 좋지 않을 것 같다.

2. 커플이 맺어지기 전 대화 상세 페이지로 리다이렉트되는 문제

상대방이 초대를 수락하기 전에 브라우저가 닫히는 상황이 생길 수 있다. 그럼 다음에 다시 로그인을 해서 접속하면 일단 '로그인은 되어있는 상태이므로' 대화 상세 페이지로 이동한다.

당시에는 로그인을 한/하지 않은 이렇게 두가지로만 유저의 상태를 파악했다. 그래서 로그인을 했던 사용자면 무조건 대화 상세 페이지로 보내고, 처음 로그인한 사용자면 무조건 온보딩 페이지로 보냈다.

따라서 상대가 초대를 수락하기 전에 다시 로그인을 했을 때, 대화 목록이 없어도 대화 상세 페이지로 이동되는 문제가 있었다.

이 문제를 해결하기 위해 생각한 방법은 대기 페이지를 만드는 것이었다. '초대링크를 보냄 -> 상대가 초대를 수락함' 이 둘 사이에 대기 페이지를 만들어서 곧바로 대화 상세 페이지로 이동시키지 않고자 했다.

하지만 아래와 같은 문제가 생겼고 고민은 더 깊어졌다.

1. 1번 문제점과 같이 전혀 상관 없는 대화 목록 api에 요청을 보내고 있다.
2. 요청을 보내 오류가 나면 커플이 맺어지지 않았다고 판단하여 대기 페이지로 이동하고 있는데, 다른 이유로 오류가 났을 때 이를 구별하지 못한다는 문제가 있다.
3. 대기 페이지로 이동되면 우리 서비스를 아예 이용할 수 없게 된다. 따라서 대기 페이지 대신 대기 컴포넌트를 만드는 것이 좋아보였다.

당시 머릿속이 아래 그림처럼 혼란스러웠다🥲

✨ 해결

프론트 -> 백 & 프론트 -> 프론트의 회의를 거쳐 새로운 api를 생성하는 것이 좋겠다는 결론이 내려졌다.

• api 엔드포인트: /api/v1/members/user-status
• 응답의 종류 3가지

  1. `COUPLE_USER`: 커플 사용자 -> /chatroom 
  2. `COUPLE_WAITING_USER`: 커플 대기 사용자 (링크키 생성 했고, 링크키가 유효함)-> /chatroom + api 요청에 대한 제한 
  3. `NON_COUPLE_USER`: 링크키 생성한적 없거나 + 링크키가 유효하지 않은 경우 -> /onboarding 

기존에는 사용자가 로그인을 했는지/안했는지만 고려했다면, 이제는 사용자의 상태도 함께 고려하게 되었다.

사용자의 상태 3가지가 추가되고 나서는 로그인 이후 사용자는 아래처럼 리다이렉트 되게 되었다.

사용자의 상태가 있으니 같은 대화 상세 페이지로 리다이렉트 시키더라도 대기하라는 설명이 있는 ui를 보여줄지, 아니면 실제 대화 목록이 있는 ui를 보여줄지도 설정할 수 있었다👍

그리고 이렇게 추가된 사용자 상태는 특정 사용자가 url로 특정 페이지에 직접 접근하는 걸 막는 걸 설정하는 것에도 큰 도움이 되었는데, 이부분은 다음 포스팅에서 다뤄볼 것이다!

🐹 회고

이 문제를 해결하기 위해 엄청나게 고민했는데, 새로운 api가 나오고 나서 해결이 되었다.

잘한 점은 그렇게 고민하다가 새로운 api가 필요하지는 않을까? 하는 생각이 든 시점에 바로 백엔드 팀원과 상황을 공유한 것이다. 덕분에 프론트 단에서는 해결하기 어려운 문제라는 걸 알게 되었고, 백엔드 팀원도 프론트엔드의 문제 상황을 알고 같이 고민할 수 있었다.

새롭게 알게 된 점은 나에게 api 변경 요청이 어렵게 느껴진다는 것이다. 백엔드와 협업을 처음 해보다보니, api 변경이나 추가를 요청하는 것이 너무 어렵게 느껴졌다.

그럴 때는 이렇게 백엔드 팀원과 함께 문제를 공유하고, 이러한 요청이 어려운 일인지 여쭤보는 것이 좋은 방법임을 배웠다.

다음에도 비슷한 상황이 생긴다면 조금 덜 고민하고 팀원들과 문제 상황 공유를 해볼 것 같다!