M:N 관계를 구성해놓은게 있는데
TypeORM으로
문제는
joinTable 기능을 사용해서
테이블이 하나가 생겨난다.
나는 이게 직관적이라서
좋다고생각했고
이름을 join 으로했다. (이게 컬럼명일줄 몰랐다..)
테이블이름이
stacks_join_recruits 이렇게 나오니 보기좋아서 잘된줄 알았다.
문제는
나중에 접근할때
recruits.join () <이거 자체가 컬럼명 ㅋㅋㅋㅋㅋ
타입에 마우스로 올려서보면
stacks[] 이렇게뜨는거보고 아차 싶었다.
테이블이름이 불편하면 joinColumn? 이것을쓰면될거같다 .
뭔가 독이된느낌인데
recruits_stacks_stacks 이런 이름이 싫었던거같다.
조금만 생각하면 리크루트에 스택컬럼에 스택스가 들어간다.
이렇게 생각할만도 해서 직관적일수도 있엇는데
괜히 조인테이블엔 'join'이 들어가야 이뻐
라는 고정관념때문에
애매해졌다.
당장은쓰기로했지만
2주안에 변동사항이나 불편함이 심화된다면
얼른 조인컬럼으로 리펙토링하던가 해야겠다.
하지만 여젼히 아직 조인이어렵다.
다대다 개념자체를 까먹은거같다
1:n n:1 로 쪼개서 생각하면 어렵지않기도하고
뭐 어렵겠어 싶은데
은근 데이터 추가할때 어떻게했더라.
의존성이 있던가 ?
약간 여러 생각이 드는것..
일단 오케이 구현하고 생각해보자.
추가로 이번에 authChecker 구현할때는
res.redirect를 없앴다.
그냥 400 코드로 메시지 내려보냈다.
리다이렉트하니까 문제가 너무많았다. (배포과정에서 cors...)
물론 리다이렉트를 많이 안만나는게 맞다 (당시에는 액세스토큰을 스토어(리덕스)로 관리하는데)
스토어 업데이트되기전에 액세스토큰을 넣어서 보내야할 요청이 출발해버리는것이다.
이후 스토어가 업데이트가되니까 자꾸 액세스토큰이없으니 리다이렉트 요청을 날렸던것이다.
이번엔 로컬스토리지로 합의를보긴했다.
다만 걱정인게 로컬스토리지 자체는 선호하는편이 아니긴하다.
만약 액세스토큰을 로컬스토리지에 보관한다면, (실제로 그런 서비스는 많다)
쿠키로 리프레시를 관리하고싶은마음인데
이번 파이널프로젝트 Reciper는 꼭 aws단계에서 https 와 cookie의 이슈를 극복하겠다.
이번주 토요일에 만나는 백엔드 행님한테 꼭 조언 받아야겠다 ㅠㅠ
