> [!date] published: 2023-03-06 ## 🌟 로그인 / 로그아웃 이란 무엇인가 - 액세스를 제한함. 👉 유저를 구분하고, 인증하고, 그에 따라서 적절한 행동을 할 수 있고 할 수 없게 하는 것 - 시스템 로그를 남길 수 있게 함. ("누가" 무엇을 했는지를 기록하자) - 로그아웃 : 로그인 된 상태를 제거하는 것, 토큰을 만료시킨다거나, 세션을 끊어버린다거나 하는 것. ## 🌟 로그인 구현을 위해 필요한 것 ### ✨ BE - 사용자 식별 : 암호화되어있는 사용자 정보를 이용해서 사용자를 식별함 - 접근 및 동작 제어 : 내 정보는 나만 볼 수 있어야 함. ### ✨ FE - 권한이 없는 자원에 접근할 수 없게 함 : 정보 조회 제한 뿐만 아니라 아예 구조적으로도 접근할 수 없게 하기 (사장님 페이지 존재 자체를 손님이 알 수 없는 것이 좋다.) - 로그인 / 로그아웃 : 단순히 input form 뿐만 아니라 그 로그인과 관련된 기능들을 모두 포함하는 내용임. - 로그인 인증 관련 데이터도 관리하기 ## 🌟 실습 form + input 조합을 useState를 사용하는 경우가 많은데, 리랜더링이 계속 일어나기 때문에 성능 저하가 일어날 수 밖에 없다. => FormData로 사용하는 것이 성능면에서는 더 좋은데 필요에 따라서는 state를 사용하는게 더 좋은 경우가 있을 수도 있다. (상황에 맞게 사용하는게 맞다는 뜻) type vs interface : type은 fix된 느낌, interface는 이후에 확장성을 고려하는 느낌 변수 앞 언더바는 제한된 스코프 안에서 사용하는 변수 (외부에서 호출되면 안되는 변수) 를 의미하는 명명규칙 삼항 연산자는 가독성이 좋아진다면 쓰고, 가독성이 좋아지지 않는다면 쓰지 않는다 (뭔가 당연함..) Token : env로 빼든가, 외부 storage에 저장한다. ## 🌟 실제 서비스의 로그인 구현시에 생각해야 할 부분 + a - 토큰이 무엇인가 - 토큰을 어디에 저장해야 하는가 - Cookies - Local Storage - Session Storage - 토큰을 매번 넣어줘야 하는가 : 개발자에게나 유저에게나 당연히 불편함. 어디다가 저장해두고 꺼내써야 한다. - 이미 받아온 유저 정보를 다른 곳에서 사용할 수 있게 하자. - 로그인 페이지와 실제 서비스 페이지를 분리해야 한다. --- 로그인 여부에 따라서 접근할 수 있는 페이지가 달라져야 한다. - 로그인이 필요없는 페이지 - main - login - 로그인이 필요한 페이지 - page - setting - ... 로그인이 필요한 페이지마다 로그인 여부를 확인하는 훅 (또는 다른 방법이든)을 넣는 방식은 굉장히 비효율적임. 👉 로그인을 체크하는 부분을 모듈화해야 합니다. 로그인을 체크하는 컴포넌트로 감싸준다. 로그인이 되지 않은 경우에는 return해주고, (return하지 않으면 함수가 동기적으로 동작하는 것이 아니기 때문에 잠깐이라도 허용되지 않은 내용이 랜더링 될 수 있다.) 로그인 된 경우에는 감싸진 children 컴포넌트를 랜더링하는 방식. => early return pattern --- **라우팅 관련된 정보들을 모두 객체에 담아서, 객체 배열로 관리하면 여러 부분에서 유용하게 사용될 수 있다.** (Private route, nav bar 등등.) --- reduce vs filter : 값을 그대로 가져다 써야 할 때에는 filter를 사용하는 것이 공간복잡도 측면에서 효율적이다. 하지만 형태를 바꿔서 넣어야 할 때에는 reduce를 사용하는 것이 더 효율적이다. (아마도 다른 방법이 있긴 하겠지만 시간복잡도 측면에서 reduce가 가장 효율적인 듯) --- **감싸는 개념**(내가 임의로 만든 용어임)은 중복된 코드를 제거하기에 좋은 방법임 (예를 들면 로깅 관련 동작을 할 때에도 외부의 global component에서 처리하는 것이 적당한 양의 데이터를 수집하기에 좋다? (각각 세부 페이지에서 모두 로깅 함수를 호출하면 너무 많은 데이터가 쌓인다는 문제가 있다.)) ## 🌟 CSR, SSR에 대하여 - CSR : 클라이언트 사이드 랜더링 👉 조립을 온전히 브라우저에서 한다. - SSR : 서버 사이드 랜더링 👉 서버에서 랜더링한다기보다는 반조립상태의 HTML을 서버에서 클라이언트로 - SSG : Static Site Generation 👉 빌드 단계에서 이미 HTML이 있음. 랜더링이란 - 브라우저에서 ? : HTML, CSS 를 가져와서 화면에 그리기 - CS에서 ? : 어떤 개체를 그려내는 것 당연히 여기서는 브라우저 랜더링을 다루고 있습니다. --- 유명한 차이들... SEO, 속도 등등 CSR은 크롤링된 데이터가 완성본이 아니기 때문에 SEO가 어렵다. 이런 특징들만 보면 SSR을 쓰지 않을 이유가 없지만 그럼에도 불구하고 CSR이 여전히 사용되는 이유 => "서버" 사이드 랜더링이기 때문 랜더링을 위한 추가적인 서버가 필요하다 👉 추가로 관리해야 할 지점이 늘어난다. 👉 장애가 발생할 수 있는 가능성이 있는 지점이 늘어난다는 것은 꽤 큰 단점이 될 수 있다. 이런 뭔가의 특징이 결정의 절대적인 기준이 되어서는 안된다 (예를 들면 SEO가 잘 되기 때문에 SSR을 씁니다!!! ❌❌❌) 1. 실제로 서버가 필요한지. (진짜 필요한가요? 진짜요?) 2. SEO가 필요하다면 (이 경우에는 어쩔 수 없음) 3. 그 외에도 어떤 유저 인터렉션이 많은지... 등등 위와 같은 현재 상황의 특징 + 그 방식의 특징을 종합적으로 고려해서 선택을 하는 것이 옳다! ## 🌟 ETC CSR ➡️ SSR ➡️ 인프라 순으로 공부하는 것이 좋다! (인프라를 왜 공부해야 할까요? 어떻게 유저에게 전달되는지 알아야 하는 상황이 언젠가는 옵니다... 우선순위가 높진 않지만 여유가 된다면 공부하는 것이 좋다.) storybook 써보고싶었는데 어떻게든 써봐야겠다는 생각을 함. 1. 코드를 읽는 능력 2. 내가 뭘 모르는지를 아는 능력 3. 내가 뭘 질문해야 발전할 수 있는지를 아는 능력