> For the complete documentation index, see [llms.txt](https://injun-woo30000.gitbook.io/growth-log/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://injun-woo30000.gitbook.io/growth-log/daily-review/2021/feb/2021-02-15-mon.md). # 2021-02-15(Mon) | 항목 | 내용 | | ---------- | ------------------------------ | | 학습 날짜 | 2021-02-15(월) | | 학습 시간 | 08:00\~24:00 | | 학습 범위 및 주제 | Websocket, rails active record | | 학습 목표 | ChatRoom을 구현한다. | | 동료 학습 방법 | 스크럼 후 모각코(모여서x 모듈별 각자 코딩) | ## 상세 학습 내용 은휼님과 페어코딩을 하던 중 효율적인 진행을 위해 챗룸의 프론트엔드와 백엔드를 나눠서 각각 진행한 뒤 중간에 합치기로 하였다. 우선 나는 백엔드, 은휼님은 프론트엔드를 맡아서 진행했다. ### Q) GET이나 DELETE 요청 메서드를 쓸 때 유저 권한과 비밀번호는 어떻게 전송하고 확인해야할까? 유저의 권한에 따라 들어갈 수 있는 ROOM에 대한 정보와 삭제할 수 있는 멤버십이 달라서 이를 확인할 방법을 정해야했다. POST 요청 메서드의 경우, 메세지 바디에 패스워드와 유저 정보를 담아서 전송하면 어느 정도 데이터가 감춰진다. 그런데 메세지 바디를 포함하지 않는 DELETE 같은 HTTP 요청 메서드의 유저의 권한과 패스워드를 어떻게 확인해야할까? 단순히 URL 쿼리로 날리면 1) 보안상 좋지 않을 것이 뻔하고 2) 단순히 유저가 주소창에 숫자를 바꿔서 입력하는 것만으로도 유저 식별 및 처리가 어려워진다. ### A) 헤더에다가 담아서 보내자! 나 같은 경우엔 `current_user` 헤더에는 현재 로그인된 current\_user의 id 값을, `Authorization` 헤더에는 패스워드를 담아서 전송시켰다. 아래 두 가지를 기억하면 Rails에서 쉽게 받아서 쓸 수 있다. 1. 받은 헤더는 Rails controller에서 `request.headers`로 탐색하면 된다. 2. `Authorization` 과 달리 `current_user` 같은 사용자 정의헤더는 prefix로 `HTTP` 가 붙는다. 결과적으로 `request.headers["HTTP_CURRENT_UESR"]`로 탐색했다. ## 학습 내용에 대한 개인적인 총평 백엔드가 확실히 재밌다. 'POSTMAN'으로 테스트 셋을 구축해뒀기 때문에 바로바로 구현을 검증할 수 있었기 때문인 것 같다. 책에서 읽은 것처럼 엄밀하게 A to Z까지 TDD를 진행한 것은 아니지만, 테스트를 먼저 만들어놓고 개발하는 것의 중요성을 다시금 느꼈다. 이렇게 개발하면 안정성도 안정성이지만 재미가 보장된다ㅎㅎ 그리고 프로젝트 초반에만 해도 프론트엔드와 백엔드를 나누는 것에 대해 거부감이 들었었는데(각 사이드에 대한 학습 기회가 박탈될 수 있다는 생각 때문에) 지금은 백엔드에 좀 더 흥미가 가는 것을 느꼈다. 원래 나는 내 서비스를 만드는데 도움이 되는 수준으로 백엔드를 하고, 프론트엔드나 앱개발을 하려고 했었는데, 성향상 백엔드가 참 맞는달까? 객체 지향도 공부하면 공부할 수록 흥미롭고..흠 커리어를 좀 생각해봐야겠다. ## 다음 학습 계획 * 챗룸 메세지 구현