230714(금)

🚤 성장일지 6.0

책 행복한 이기주의자(웨인 다이어)의 내용에 자극받아 시작하는 소박한 성장기록

살아있는 꽃과 죽은 꽃은 어떻게 구별하는가?
성장하고 있는 것이 살아 있는 것이다.
생명의 유일한 증거는 성장이다!

🌾 (4.0)학습 키워드에서 최대한 간단한 정보 제공, 고민에서 내 경험을 자세히 적자!
🥊 (5.0)학습 키워드는 한줄의 핵심으로만 정리, 성공/실패 일지 작성하기! 이 때, 실패의 경험은 자세히 적기!
🍉 (6.0)<완전 개편!!!> 매일 습관적으로 핵심만 적을 수 있게 프레임 변경. 성공보단 실패에 초점을 맞추기.

• 🍉 (6.1)<수정> 매번 성공, 실패를 따로 적는 것보단 경험으로 표현하자

🌈 오늘의 감정

진짜 열심히 살고 있다. 뿌듯하고 보람차다. 더 계속 나아가고 싶고 더 많이 배우고 싶다. 이런 감정을 느끼고 적을 수 있음에 감사한 하루다.

🫧 오늘의 고민

각각의 reducer에서 초기 상태값을 전달하지 않고, combineReducers 후에 createStore할 때 초기 상태를 전달할 수 없을까?

결론만 말하면 안되는 걸로! rootReducer를 생성할 때, combineReducers에 각 reducer들을 담아 호출하게 되는데 이 때, 리덕스가 내부적으로 각 reducer를 호출하여 값을 받는다. 즉, 초기값이 없으면 에러가 발생한다는 이야기다. 그러므로 각각의 reducer에 초기 상태값을 전달해줘야 한다.

HTTP의 stateless 면에서 봤을 때, session 기반의 방식은 적절하지 못한 거 아닌가?

stateless의 의미만을 살펴보면 세션은 stateless하지 않기에 적절하지 않다고 할 수 있다. 하지만 예를 들어 로그인 후 회원의 로그인 유무를 유지하는 기능을 구현할 때, HTTP의 stateless한 성질을 유지하면서 매 요청마다 회원의 로그인 정보를 전달하는 것은 효율적이지 않다. 이를 극복하기 위해 세션과 같은 state를 부여한 것이므로 기능의 효율면에서는 적절하다고 생각한다.

☀️ 오늘의 경험

Redux의 Action, Action Creator, Reducer 그리고 combineReducers

리덕스를 Flux 아키텍처의 구현체라고 하는데, 왜 그런지 조금은 알 것 같다. state를 변경하기 위해 action을 create하고 해당 action을 dispatch를 통해 reducer에게 발송한다. 이를 받은 reducer는 action에 따라 업데이트된 state를 내놓게 되고 이를 통해 UI를 그린다. 이렇게 단방향 흐름인 Flux 아키텍처가 구현된다. 처음엔 왜 이런 흐름을 가져가야하나 했는데 아직 코드가 짧아서 그런가… 굉장히 편한 것 같다. 이전에 진행했던 리액트 프로젝트들은 도대체 상태가 어떻게 흘러가는지 알기가 어려워서 추후에 리팩토링이나 디버깅하려면 한참 cmd + 클릭으로 타고타고 가야했는데… 단방향 흐름을 잘 유지해주면 참 편리한 것 같다. 어떤 면에서는 TS를 처음 썼을 때 느낌이다. 앞에 준비할 게 많지만 잘 준비하면 그 뒤에는 정말 편한 느낌..?!

세션과 쿠키

그 동안 그냥 단순하게 쿠키는 클라, 세션은 서버에 저장하는 사용자 정보 느낌으로만 알았다. 그리고 대충 클라에서 관리하니까 보안 상 좋지 않을 거 같고 서버에서 관리하니까 그나마 보안에 유리하고… 그런데 이런 부분들말고도 쿠키와 세션의 라이프사이클이라든지, 전달 방법, 등장 이유(HTTP가 stateless하니까), 세션도 보통 쿠키를 같이 쓴다는 것 등등을 알게 된 게 참 좋았다.

🐾 오늘의 교훈

배워보자. 처음엔 두려운 것들도 막상 배워보면 그리 어렵지 않더라.

🪵 참고

• 쿠키와 세션 개념
• 로그인 인증 방식 어떤 게 좋을까? Session VS JWT
• Session 그리고 Stateless
• 다중 서버 환경에서 Session은 어떻게 공유하고 관리할까?