원티드 FE 챌린지 3월 노트 1

2023-03-06
session
로그인이란 무엇인가

🌟 로그인 / 로그아웃 이란 무엇인가

  • 액세스를 제한함. 👉 유저를 구분하고, 인증하고, 그에 따라서 적절한 행동을 할 수 있고 할 수 없게 하는 것
  • 시스템 로그를 남길 수 있게 함. (“누가” 무엇을 했는지를 기록하자)
  • 로그아웃 : 로그인 된 상태를 제거하는 것, 토큰을 만료시킨다거나, 세션을 끊어버린다거나 하는 것.

🌟 로그인 구현을 위해 필요한 것

✨ 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. 내가 뭘 질문해야 발전할 수 있는지를 아는 능력