11월 14일 (마스터 클래스, 조은) - boostcampwm-2022/web33-Mildo GitHub Wiki

마스터 클래스 (조은)

헷갈리기 쉬운 FE 지식들

  1. 렌더링이 진행되는 과정
    1. DOM Parsing
    2. CSSOM Parsing
    3. Render Tree 생성
    4. 레이아웃
    5. 페인팅

→ HTML 파일을 서버로부터 받아온다 → HTML 파일을 파싱한다 → 마크업들을 찾아서 특정한 동작을 수행한다 → DOM Tree를 생성한다 → 만약 CSS를 만나면 CSSOM을 만든다 → (JS 코드가 Defer등으로 설정되지 X) 만약 JS를 만나면 파싱을 멈추고, JS 해석을 시작한다 → Render Tree 생성 → Layout (위치를 잡는 과정, 비용이 비쌈. 이유: 연산이 필요한 작업이니까, CPU 작업이 필요) → Painting (그래픽으로서 그리는 과정, 비용이 쌈, 그리기만 하면 된다! → GPU)

  1. SPA(Single Page Application) vs Server Side Rendering(SSR) vs Static Site Generation(SSG)

    1. SPA ⇒ 하나의 HTML 파일만 사용한다.
    2. SSR ⇒ 요청(HTTP Request)이 올 때마다 해당하는 HTML 문서를 생성해서 내려준다
    3. CSR ⇒ HTML은 불완전한 상태로 다운로드 받고, 브라우저가 나머지 요소를 렌더링 → JS를 이용하여 DOM을 직접 생성하고 렌더링 → HTML의 완성은 브라우저가 진행한다. →
    4. SSG ⇒ HTML을 빌드 타임에 각 페이지별로 생성 ⇒ 해당 페이지로 요청이 올 경우 이미 생성된 HTML 문서를 전달함

  2. Single Page Application

    1. Client에서 라우팅을 처리하고, 특정한 라우팅에 따라 데이터를 불러와 렌더링한다.
    2. 장점: 깜빡임이 없다, 서버에서 Data를 불러오는 부분과 클라이언트를 렌더링하는 부분을 분리할 수 있다 → 서버는 API를 만들어서 클라이언트에 제공하고, 클라이언트는 API를 받아서 화면에 노출시킨다 (기존의 방법)
    3. 단점: 로딩(그러나 MPA도 마찬가지), 굳이 따지자면 초기 로딩(JS 파일이 너무 크다) ⇒ Chunk로 쪼개서 JS 파일로 관리하면 크게 이슈가 생기지 않음. 따라서 툴에 따라서 달라짐. SEO? SPA가 항상 SEO에 안좋은 것은 아니다. 사용자 환경에 의존적이다. 렌더링 관심사와 인터렉션 관심사가 섞이면서 점점 스파게티가 만들어진다 → 에러가 나기 쉬움
    4. 그러면 뭐가 좋아서 SPA를 할까?
      • 그래서 요즘 많이들 SSR로 넘어간다…

    • SPA 초창기 → Facebook, Twitter (말 그대로 웹 애플리케이션 → 페이지 전체를 로딩하지 않고, 일부분만 불러오는 게 훨씬 효과적이다 → SPA)

    • 대부분의 웹사이트 + 현대의 웹 애플리케이션 → 네트워크 성능이 굉장히 발전 → 일부분만 불러오기 위해 사용하는 스크립트의 양과 리소스가 더 비효율적

      e. SPA는 어디에 쓰면 좋을까?

    • 레이아웃이 이미 고정되어 있는 상태고, 그 레이아웃이 특별히 변하지 않는 상태에서, 콘텐츠가 어느 정도 정형화되어 있는 경우에는 SPA가 더 유리하다 (트위터, 페이스북, 인스타그램, 채팅)

    • ReactJS(==Meta)

    • Angular(==Google, YouTube, Gmail)

  3. Multi Page Application

    1. 라우팅 처리를 보통 서버에서 하게 된다

    2. 멀티 페이지

    3. 페이지의 관심사별로 HTML 파일 혹은 서버 탬플릿을 분리해서 관리한다 → 관심사 분리가 수월

    4. 보편적으로 서버에서 이미 만들어진 HTML 파일을 내려준다 (SSG, SSR, Hybrid Rendering(SSR + CSR))

    5. 장점: 서버 리소스를 사용하고, 서버 리소스는 내가 제어하기 때문에 클라이언트의 영향을 상대적으로 덜 받을 수 있다. HTML을 생성하는 부분과 인터렉션을 처리하는 부분의 관심사 분리. 클라이언트에 의존적이지 않음, 로딩시간 줄어듬, SEO 대응 유리, 정적 컨텐츠가 많을 시 유리하다.

    6. 단점: 어쨌든 요청이 있을 때마다 페이지 생성 → SPA에 비해 서버의 리소스를 더 많이 사용할 수 있음. 특정한 데이터만 불러와서 페이지를 리렌더하면 되는데, 굳이 전체 페이지를 다시 재렌더링하는 케이스를 만들어낼 수 있다. MPA는 기본적으로 서버 리소스를 사용함 → 서버에 대한 지식이 필요 → 클라이언트 개발자가 서버에 대한 이해도를 충분히 가져야만 한다

      • 예시) Server + Template Engine (Express + JSX or Koa + JSX)

      → 보편적으로 난이도가 더 어려우나, Next / Remix 등을 쓰면 훨씬 쉽게 제작이 가능하다

  4. CSR vs SSR vs SSG

  • 언제 HTML을 생성할 것이냐?
  • CSR → 브라우저 / SSR → 요청이 오면 서버에서 / SSG → 미리 서버에서
  • 어떤 렌더링 방식을 어느 시점에 사용하는 것이 좋을까? → 사실 꼭 그렇게 할 필요는 없다
  • 만약 콘텐츠가 자주 안바뀌고, 보안도 별로 안 중요한 경우에는 보편적으로 SSG
  • 보안이 엄청 중요한 경우에는 SSR
  • 서비스의 일부 영역만 리렌더하고 싶다 → 보편적으로 CSR
  • 예시) 쇼핑몰 → 목록 페이지, 상품 상세 페이지 → SSR (품절, 가격 변동, 상품 목록의 랭킹 변경) → 가격이 달라도 결제 들어가서 다르게 보여주면 되지 않을까? → 유저의 신뢰도가 하락할 수 있음 → CSR도 살짝 섞자 (가격 변동 API를 호출해서 가격은 실시간을 반영함)
  • 예시) 슬랙 → 아무리 봐도 SPA (CSR) → 레이아웃 고정 → 콘텐츠 형태 비슷, 데이터만 달라짐
  • 그래서 기준은? → 콘텐츠의 실시간성이 얼마나 보장되어야 하는가 → 콘텐츠의 보안은 얼마나 중요한가 → 유저의 퍼포먼스와 상관 없이 페이지가 빠르게 노출되어야 하는가 → 서버 비용이 빵빵한가 → 돈이 많은가?
    • SSR: $$$ > CSR: $$ > SSG: $
  1. 라이브러리 vs 프레임워크
  • 라이브러리와 프레임워크의 차이
  • 리액트는 라이브러리일까 프레임워크일까? → 면접에서 명확하게 자신의 주관을 기준으로 대답해야 함
  • Vue는 프레임워크라고 지향하나, 인터페이스는 라이브러리 형태에 가까움 → 우리는 프로그레시브 프레임워크이다!! (자유도는 높지만 프레임워크!)
  • 프레임워크는 해당 도구에 의존하여 설계부터 코드 작성 스타일까지 모두 해당 도구에 의존하면 된다. → 말 그대로 짜여진 ‘프레임’ 내부에서 일하면 되니 ‘프레임워크’
  • 라이브러리는 해당 도구를 사용하여 일부의 생산성을 개선하는 것에 초점 → 인터페이스를 아주 크게 제약하지는 않음 → 따라서 전체 설계까지 영향을 미치지 않는 것이 보편적임(jQuery, TinyMCE)
  • React, Vue ⇒ 얘네, 라이브러리야?
  • React → 라우팅: React-Router, 컴포넌트: JSX(TSX), 빌드도구: CRA, babel, webpack
  • React, Vue는 하나의 페이지에 동시에 쓸 수 있음! 그러나 보편적으로 프레임워크는 그게 안된다 (예시: Next.js)
  1. SEO
  • Search Engine: 구글, Yandex, 네이버, DuckDuckGo
  • 검색 엔진의 규약 → 검색 엔진은 어떻게 동작하는가? → 크롤러가 공개된 IP의 데이터를 전부 긁어옴 → 데이터를 적당이 가공하여 화면에 노출 → 이 과정에서 데이터에 따라 어떤 것을 먼저 노출시킬지를 결정(⇒ 이게 SEO)
  • SEO는 검색 결과에서 상위 노출되기 위한 노력 → 내가 가진 서비스(네이버, 티스토리, medium)의 유저 접속자 수가 얼마나 많은가 (네이버 블로그는 어지간하면 구글 검색 상위 노출, tistory), 페이지의 렌더링 속도 (lighthouse를 기준으로 판단)
  • SSR은 SEO에 좋아요! → 왜요? → Google 크롤러는 JS를 동작시키지만 다른 크롤러는 그렇지 않을 수도 있다, SSR이 보편적으로 CSR보다 빠르다, SSR이 Lighthouse 스코어를 더 높게 받을 수 있다.
  • Google 검색 센터에서 SEO에 대한 내용을 숙지하면 좋다. 자세한 내용은https://developers.google.com/search/docs/fundamentals/seo-starter-guide
  • 지연 렌더링하는 경우에 검색엔진이 긁어갈까? (예시: 쿠팡 링크 클릭 후 상세 내용 보기) → 특정한 인터렉션이 필요한 동작에 대해서는 긁어가지 않는다. → 기본적으로 페이지 내의 A요소만 클릭해서 확인한다.
  • SEO가 중요해요!
    • 이 데이터는 기본적으로 로그인하지 않아도 볼 수 있어야 한다 → 보안이 걸려있지 않은 public 상태로 만들어야 한다
    • 페이지 내의 링크 이동은 A 요소로 만들어놔야 크롤러가 제대로 사이트맵을 생성해서 긁어간다.
  1. 클라우드는 왜 비싼가?
  • 서버 → 랙 설치 → 서버 전용 컴퓨터 설치 → 24시간 내내 돌림 (DNS, 클라이언트 서버, 데이터베이스, …) → 단순히 생각하면 24시간 내내 동작하는 컴퓨터이다.
  • 서버는 크게 두 가지 공간을 차지
    1. 물리적인 공간 (IDC, 서버실), 예시) 춘천 데이터센터 각
    2. 가상 공간 (트래픽) → 더 비싸다 → 트래픽은 전세계로 향하도록 되어있고, 그 과정에서 통신사 등에 결제를 하게 되어있다. → 망은 다 ‘유료’ → 트래픽이 많이 발생한다 === 통신사에 내야되는 비용이 많아진다
      • 트래픽은 발생하는 대로 족족 내야되기 때문에 유지비가 비싸다.
  • 비용이 비싼 것들
    • 스토리지(그냥 데이터를 저장하기만 하는 곳) → 싸다!
    • 트래픽이 자주 발생하고, 캐싱을 할 수 없을수록 비싸진다.
    • AWS Cloudfront는 상대적으로 저렴하나, 그냥 EC2를 쓰거나, EKS를 쓰거나 하면 비싸짐
    • DB는 어쨌든 비쌈
    • 따라서 비용이 억대로 발생하는 것은 의외로 흔하다 (예시: 메가존 클라우드(중간 거래 회사) → 매출이 연간 5000억)
  • 게임 회사 → 트래픽이 너무 많이 발생하는 경우 → 직접 물리 서버를 만들고, 클라우드로 인해 들어가는 비용을 줄이려고 함
  • 게임 서버 대기열 → 서버 클라우드로 하면 오토스케일링하면 되는데 왜 안해? → 너무 비싸…
  • 일정 수준 이상의 트래픽을 받을 거면 직접 서버를 만드는 것이 훨씬 더 싸다 (예시: 카카오, 네이버 → 자체 IDC)
  • Google, Meta, Apple 전부 자체 IDC
  • 드라이브를 무료로 주려면 스토리지 비용을 절감 → 스토리지를 자체 구축하는 경우에는 경우에만 가능한 시나리오이다.

무물보

  • 개인정보는 가급적이면 저장하지 마..

  • 이메일만 있으면 개인정보는 아님 → 그러나 여러 개의 정보를 기반으로 이 사람이 누군지 식별이 가능하면 개인정보라고 볼 수 있음

  • 유저의 프로필 사진 & 닉네임 → 개인정보일수도 있으나, 체크를 해보자

  • GraphQL은 SQL의 대체재 → SELECT FROM 뭐시기를 대체한다 → RESTful API와는 별개의 문제이지만, GraphQL을 호풀하는 방식 자체가 다르기 때문에 보편적으로 RESTful과 비교해서 사용한다.

  • 선호하는 상태관리 라이브러리 없다.

  • 요즘 보고 있는 거 → GRPC Web

  • Webpack보다 Vite가 빠른 거 같은데.. 시간이 한정적이면 그냥 Vite가 더 나을 수도… 생산성은 webpack이 더 나음

  • zero runtime css in js → 빌드 시점에 CSS를 미리 생성해야 할까…

  • dehydrate

  • Jenkins < Github Actions (사내에 배포 도구가 안정적이면 Jenkins, Travis CI, 그렇지 않으면 Github Actions)

  • 11월 15일 (수료생 MeetUp, 화)

    <김동환 연사님>

    • 기능 개발에’만’ 너무 몰두하지 말자
    • 그러면 무엇을 해야 할까? → 자기가 ‘하고 싶은 것’을 해보자!! → 완성도, 쉽고 편리한 개발, 현업에서는 어떻게 개발할까? 등등…
    • ‘성능 테스트, 무중단 배포, CI/CD 자동화’를 키워드로 진행함
    • 성능 테스트: 별도의 테스트 툴 → 완성도를 올려준다 → [https://velog.io/@znftm97/스트레스-테스트-툴로-성능-측정하기](https://velog.io/@znftm97/%EC%8A%A4%ED%8A%B8%EB%A0%88%EC%8A%A4-%ED%85%8C%EC%8A%A4%ED%8A%B8-%ED%88%B4%EB%A1%9C-%EC%84%B1%EB%8A%A5-%EC%B8%A1%EC%A0%95%ED%95%98%EA%B8%B0)
    • 무중단 배포: 도커 + nginx
    • CI/CD: Github Actions
    • 결과보다 값진 과정! → 스스로 많은 것들을 공부하고, 팀원들과 많은 이야기를 나눌 수 있었다. → 이것들이 나중에 큰 도움이 될 수 있다!
    • 중요한 점은 그룹프로젝트에서 얻어갈 수 있는 것이 무엇인지 곰곰이 생각해보는 것
    • 가장 중요한 것은 ‘대화’이다. → 반드시 개발하고 싶은 부분을 정하자
    • 최대한 기록을 남기고 나면 앞으로 무엇을 해야 할 지 파악하기 쉬워진다.
    • 페어프로그래밍은 생각보다 도움이 많이 된다
    • 그룹프로젝트에서 가장 중요한 것은 바로 ‘부드러운 커뮤니케이션’이다. → 그룹 프로젝트에서 신경을 써주자
    • 중요한 것: 팀원들과 놀러가세요, 잘 쉬는 것도 실력이에요

    <김민지 연사님>

    • 그룹프로젝트의 실패 → 문제점이 무엇이었을까? → 서로 배려하느라 솔직하게 말하지 못함, 선택의 기로에서 ‘왜’를 생각하지 못함, 트러블슈팅 기록하지 못함, 구현에만 급급함, ‘이벤트 수집’이라는 주제를 제대로 살리지 못함
    • 괜찮지 않으면 솔직하게 말하자!, 기록하자! 많은 기능보다는 어필할 수 있는 기능이 중요하다!
    • ‘왜 이 기능을 선택했는 지’ 말할 수 있어야 한다!!
    • 기술적인 고민을 하는 것이 중요하다. → 프로젝트가 내세울 수 있는 강점을 꼭 내세워야 한다 (예시: 아키텍쳐)
    • 개발을 하는 데에 있어서 실버불렛은 존재하지 않는다. 아키텍쳐마다 각자의 장/단점이 존재한다. → 기록하고 발전시킬 수 있어야 한다!!
    • 전 기수를 너무 따라하려고 하지 말자…
    • 일단 도전해보자. 도전하지 않으면 아무것도 되지 않는다. 면접 단골 질문에 대해 “기술적으로 가장 어려웠던 점은 무엇인가?” → 기술적인 도전에 실패한다고 해도 얻는 것은 반드시 존재한다!
    • 어려우면 이것을 작은 문제로 나누어보고 차분하게 정리해보자 (예시: A 알고리즘 몰라 → 무엇을 모르는 지 아는 상태이다)
    • 공식문서 → 블로그 순으로 읽어보자
    • 기록! 기록! 기록! (부담을 가지지 말고 기록하자), 간단하게라도 기록해보면 훨씬 빠르게 성장한다
    • 칭찬을 자주 하자!
    • 그룹프로젝트 끝이라고 다 끝난 것은 아니다 → 채용 연계를 위해 준비하자 (스터디 등등..) / 위안이 될 수 있는 관계
    • 가벼운 마음으로 사이드 프로젝트 진행해보기
    • 서로 회사/기술/트렌드/기타 등등에 대해서 얘기를 해보자

    <심은석 연사님>

    • 👍🏻
    • 그라운드 룰은 가꾸는 데 의미가 있다 → 그라운드 룰은 영원하지 않아요. 처음에 룰을 세웠을 때와 나중은 달라질 수 있어요. 그러나 너무 자주 변경하게 되면 너무 잦은 회의 때문에 힘들 수 있어요..
    • 히딩크 전략 → 반말, 불필요한 말 줄이기 (저는 안할래요.. )
    • 좋은 아이디어와 좋은 개발을 구분하자
    • 완벽한 계획은 존재하지 않는다.. 시간 제약을 염두해야 하고, 추가적으로 개발하고 싶은 경우에는 프로젝트가 끝난 다음에 진행해도 좋다.
    • 가장 큰 문제는 바로 개발 실력의 격차!
    • 내가 습득하지 못하고, 이해하지 못했다면 그것은 ‘무용지물’이다. → 우리의 목적은 서비스가 아닌 학습이다. 이해하지 못하는 코드는 레거시가 되고 이는 다른 팀원에게 폐가 된다 → 결과적으로 면접 때 할 말이 없어진다. → 말하는 감자가 되어버린다 🥔
    • 문서화는 선택이 아닌 필수!! 사용한 기술은 문서화하자. 특히 새로운 기술은 문서화가 꼭 필요하다! 문서화는 미루면 절대 안된다!
    • 기술 공유는 선택이 아니라 필수이다. 팀 내부에서 기술 공유 시간을 가져야 한다. 기술 공유는 개인의 성장과 프로젝트 성공을 동시에 추구할 수 있다. → 시간 내서 하자!!!
    • 경쟁이 아니라 성장! 스트레스 받지 말자!
    • 모든 것들을 알기에는 힘들기 때문에 조급하지 말았으면..
    • 지치고 힘들 때 동료가 있다는 사실을 잊지 말자!

    <정현민 연사님>

    • 멘토링 잘 활용하기 → 우선 친해져라 (실제로 기업에서도 커뮤니케이션의 코스트를 줄이기 위해 팀빌딩을 진행함), 멘토의 조언을 그대로 수용하기 보다는 멘토의 말을 기반으로 나의 생각을 들여다보자. 좋은 질문을 해보자. 좋은 답변을 얻기 위해서는 좋은 질문을 해야 한다.
    • 좋은 질문 → 검색(충분히 구글링을 해보자) / 되새김(질문과 문제에 대해 충분한 배경지식을 익히자, 스스로 문제에 대해 정리하자) / 질문(이전 과정에서 정리한 내용을 기반으로 질문) / 공유
    • 정답이 있는 질문의 경우에는 ‘예/아니오’, 정답이 없으면 최적의 조건을 말할 수 있도록
    • 멘토는 그 회사에서 면접관일 가능성이 높다. 그리고 면접관이 말씀해주신 정보는 값진 정보라고 볼 수 있다. 현업의 정보를 활용해서 가고 싶은 회사 / 가치관에 맞는 회사를 결정할 수 있다.
    • 좋은 기술적 고민과 문제의 해결은 스토리와 같다! → 게시글을 보여주어야 한다 → 페이지네이션 or 무한스크롤 → RESTful API ?? 목록 가상화??
    • 줄거리를 만들게 되면 문제 해결 과정에서 학습했던 과정들을 까먹기가 힘들 것이다.
    • 노드 엣지 공부법 → 노드와 엣지를 기반으로 두 노드 간의 응집도를 높인다. → 결국 쉽게 휘발되지 않도록 한다.

  • 11월 16일 (기업네트워킹, 마스터 클래스, 수)

    기업 네트워킹

    • 작년과 올해는 확실히 분위기가 다르다.. 그러나 모든 회사가 다 그런 것은 아니다.

    • 기업마다 속도가 바뀌는 텀이 달라진다.

    • 12월 1일 ~ 12월 6일 → 채용 연계 및 이력서를 취합해서 넣어아 햔다. 기한이 지난 이후에는 수정을 할 수 없다.

    • 12월 16일 수료 직후부터 개별적으로 컨택할 수 있음

    • 12월 19일 ~ 12월 20일: 네트워킹 데이 진행

    • 2월까지: 파트너기업에서 우선적으로 채용 지원

    • 네트워킹데이: 인재들과 기업이 서로 만나는 자리입니다.

      • 오전: 수료생 부스를 통해서 프로젝트 소개 → 데모 시연
      • 오후: 기업 부스 → 부스 운영 및 프로그램은 기업에서 자율적으로, 예약이 필요한 경우 사전 공지

    • 지금부터 준비할 수 있는 것: 네트워킹데이에서 예약을 못할 수도 있으니 꼭 컴퍼니데이에 참여해보자. 이력서는 미리 준비하자. 마지막 주는 마지막까지 손을 대는 팀들이 많다. 리팩토링과 디버깅하는 작업도 많을 수 있다. 따라서 지금부터라도 기술적인 문제를 해결하는 경험에 대해서 스토리를 다듬어 나가자.

    • 이력서는 어떻게 작성해야 할까?

      1 - 기본 인적사항 (이름, 연락처, 깃헙 또는 블로그, 학력 등)

      2 - 보유한 스킬 & 역량 간략히

      3 - 내가 진행했던 프로젝트 & 어떤 문제 해결했는 지

      4 - (옵션) 너네가 날 안뽑으면 후회할 이유 같은 거

      5 - 면접관이 이걸 보고 무슨 생각을 할까.

    • 4가지 능력: 문제해결 능력, 개발 퍼포먼스, 탐구 능력, 성장 포텐셜

    • 채용연계형 인턴십은 전부 다 정직원으로 뽑는다는 것을 가정하고 뽑습니다.

    마스터 클래스 (황준일)

    API 테스트코드 작성 시 가장 중점적으로 보는 부분

    • 백엔드 테스트 코드(도메인 로직) → 서비스 로직이 백엔드에 몰려있는 경우가 많음
    • 예시: 논문의 정보를 가져온다 → api에 대한 params, query, body → body의 양식이 적절한가??
    • 논문을 가져오는 요청 → 인자들을 클래스로 정의 → 클래스에 대한 검증 로직 만들기 → 검증 로직에 대해 테스트 (타입이 적절한 지, string(’A’, ‘B’, ‘C’) 등으로 고정값만 들어갈 수 있을 경우 다른 값이 들어가면 어떤 일이 발생해야 하는가) → 인수테스트(논문 정보를 가져옴 → 적절한 데이터들이 존재하는가)
    • 양식이 바뀔 수도 있음 → 응답에 대한 프로퍼티들이 다 존재하는 지, 각각의 값이 적절한 지 → 변경에 대해서 민감하게 반응하고 바뀌는 부분을 중점적으로 테스트해야 한다.
    • 현재 데이터들의 상태에 따라 노출되는 방식이 다른 것에 대한 테스트도 진행해보자

OAuth의 테스트

  • 보통은 token 기반

→ 로그인 상태일 때 어떤 행위들이 가능한가?

→ 로그인 상태가 아닌 경우에는 어떤 행동의 제약이 존재하는가?

일반 회원 vs 관리자 → 무엇이 가능하고 무엇이 불가능한가?

  • google, kakao, naver, github 등등… → 응답 형태 → 어떻게 정제를 해야 하는가에 대한 테스트도 작성해볼 수 있을 것 같다. → 이에 대해서 파싱을 해주는 함수를 만들 수 있다.
    • 그러나 OAuth 그 자체에 대해서 검증을 하는 것은 어렵지 않을까 (input → output(모킹)), 특정 input에 대한 output을 받았다고 가정하고, output을 테스트 코드로 사용한다 (mocking)

환경변수의 공유와 협업

  • 애초에 환경변수를 고정으로 해놓는다. 배포를 하는 경우 환경변수를 정제할 수 있다. → 배포를 github actions로 한다고 가정했을 때, Actions의 Secret에다 배포에 필요한 환경변수를 정의하고 삽입한다. (.env는 비어있는데, 이를 환경변수로 사용하기) → echo > .env.test
  • .gitignore로 env를 쓰고, .env.template을 이용해서 private한 공간에 어떤 환경변수들이 있는 지 정의를 해놓고 가져다 쓴다. → repository는 공개되어 있지만 노션/슬랙/위키 등에 환경변수를 올려놓을 수도 있고, 서버에 올려놓은 다음에 이것을 다운로드 받아서 쓸 수 있게끔 할 수 있다.

다양한 IDE

  • 결국 불편함을 인지해보자. IntelliJ에 있는 것들은 결국 vscode 내부에도 존재하는 기능인 경우가 많다. intelliJ에 있는 기능들은 VSC에서는 잘 찾아보면 있다.
  • editplus → sublime text → vscode → intelliJ
  • 어차피 회사를 가게 되면 강제하게 된다. 회사에서 webstorm만 쓰게 하거나, vscode만 쓰게 하거나…

HTTP GET 메서드 업데이트

  • 분명 GET의 용도가 있기는 하지만, 용도보다 중요한 것도 있다. (가령 돈..)
  • API의 사용량이 많을 수록 서버에 대한 사용량도 많아진다.
  • 내가 실제로 페이지에 방문한 경우 / API로만 호출하는 경우 → 어떻게 구분할 수 있을까?
  • 결국에는 분리하는 것이 나을 수 있다. 악의적인 사용자가 나올 수 있기 때문

Soft Delete의 HTTP Method

  • 그냥 DELETE도 괜찮다! (API라는 것이 그냥 데이터를 다루는 것일 수도 있지만, 클라이언트 입장에서 DELETE를 사용하는 것도 좋다)
  • DELETE /api/posts/1 호출 → GET /api/posts/1 호출 → 404 나온다 (실제로는 DB에서 상태만 바꾸어놓은 상태임)
  • API의 동작 측면에서는 합리적이지 않을까

데이터 로드가 오래 걸리는 경우 → SSR vs CSR

  • SSR로 html을 먼저 만들고, API를 호출해서 만들어진 데이터로 CSR? → 그렇게 하면 된다
  • 잘 생각을 해보면 API를 호출하지 않았을 때, 비어있을 때, 데이터가 아무것도 없을 때, 미리 렌더링을 그냥 해주면 되지 않을까?
  • 초기 화면 → SSR로 만들더라도 CSR로 해도 상관없는 부분
  • 따라서 가능하면 캐싱을 적극적으로 활용해보자!!

즐겨찾기 해제 → HTTP 메서드를 POST vs DELETE

  • POST, PUT, DELETE, 등등…
  • POST + DELETE → 추가와 삭제를 따로 / PUT → 한 번에 처리 / PATCH → 한 번에 처리
  • 이럴 때는 POST + DELETE로 해도 괜찮지 않을까…
  • nginx에서… → delete, put, patch 등을 다 막아버리는 경우 / 무조건 post만 허용하는 경우 / post 조차도 허용하지 않는 경우 → 웬만하면 POST로 진행해보고 나중에 리팩토링을 진행해보자. 고민에 대한 투자가 그렇게까지 중요한 것 같지는 않다. 그러면 최대한 단순하게 처리를 하자.
    • 이거는 항상 고민…

OT / CRDT

  • 쉽지는 않을 거 같다..
  • a, b, c, d → 프로토타입을 구현 → 어 할만하네? vs 안될 거 같다… → 결정
  • 버릴 수 있는 시간에 대한 리스크를 감수해야 한다. → ‘이정도는 투자해도 되겠다.’라고 판단되는 시간

동일 서비스 모듈 내에서 서로 참조를 하는 것에 문제가 없을까..

  • 동일한 서비스 파일 내에 생성해도 되는 지 잘 모르겠다
  • 보통 utils를 만들어서 쓴다. 그런데 아예 다른 layer(저수준)을 만드는 것도 좋은 방법이기는 하다
  • 그러면 service보다 더 낮은 단계의 (혹은 더 복잡한 단계의 일) → 어떤 Layer로 만들꺼야..
  • 예시) facade 패턴을 직접 만들어서 이 패턴에 의존시킬 수 있게끔 함
    • GithubFacade
      • GithubAuthService
      • GithubRepoService
      • GithubPullService
    • GithubReviewFacade
      • GithubAuthService
      • GithubRepoService
      • GithubPullService
    • 등등….

소켓서버 통신시 client에서 잘못된 요청을 보내게 되었을 경우의 처리 방법

  • Error에 대한 class 혹은 model을 하나 만들어 놓자!
  • 에러 → BadRequest에 대한 에러 / unAuthorize에 대한 에러 등등.. express/koa 등에서도 존재할 텐데, 이를 적극적으로 활용해보자!
    • 소켓 통신과정에서 HttpException이 발생하면 바로 특정 형태를 가진 Response를 만들어서 전달해준다. → 예시) graphQL → 얘는 무조건 200이다… 특정 형태로 응답이 오는데, 어떤 데이터는 데이터가 없을 수도 있고, 어떤 데이터는 request 형태가 잘못 되어 있을 수도 있다.
  • 소켓 통신도 rest api와 마찬가지로 unit testing, api 문서 만들기를 많이 할까?
    • 당연히 편하지 않을까? → 이거는 소켓 뿐만 아니라 다른 경우도 다 마찬가지다.. 소통 방법은 다양하기 때문임.

CI/CD

  • CI: toothless로 체크하는 것을 진행하기도 한다.. → 지속적으로 체크를 진행함 → 검증된 것을 올려야 한다 → 모두가 안전한 코드를 공유 → 브랜치에서 pull을 받았을 경우 이상이 없어야 한다
  • CD: 지속적으로 배포를 한다. 코드 변경이 파이프라인 이전의 변경을 모두 통과하면 Merge가 되면서 진행된다.
  • Naver Container Cluster → 코드 커밋 / 푸시 등등..
  • Jenkins(CD) + Github Actions(CI) 병행하는 편 → 하나만 쓰지는 않고 보통 두 개를 많이 씀
  • Github Actions를 실행해보는 환경을 무료로 제공해준다. (runners)
  • Workflow → Ubuntu / Window 환경에서 같은 코드를 테스트해본다. 그러나 runner에 대해 어느 정도의 제한이 존재할 수 있다.
  • 직접 Runners를 구현해서 사용할 수 있다 (actions-runner).
  • self hosted runner를 VPC에 넣어서 사용하는 것이 가능하다.
  • Actions Secrets에서는 비밀이라서 공개되지 않았던 부분들을 실행하는 것이 가능하다. → 어차피 secrets에서는 내용이 감춰진다.
  • json 파일을 미리 가져오기 → jobs / schedule → cron: “* * *” …. → 이런 방식으로 정기적으로 json 파일을 가져와서 저장소에 지속적으로 반영을 함 → 크롤러를 실행함 → 이러면 DB 안 써도 크롤링으로 가능함
  • jenkins로 콘솔을 출력 → Github Actions로도 할 수 있다. ← 크롤러로 실행을 하게 되면 workflow가 적용되는데, 이것을 기반으로 task들을 돌릴 수 있음
  • Lighthouse CI → PR이 올라오면 실행해서 성능 결과를 올려줄 수 있음 → Lighthouse CI를 올려줌 (성능을 올려주는 것이 가능하니 한번 찾아보자)
  • Jenkins의 좋지 않은 점은 Dashboard에 Jobs들이 직렬로 처리됨 (병렬 처리 X), 그러나 github actions는 병렬 실행이 가능하다는 장점이 존재함. 예를 들어, jobs가 여러 개가 실행되면 병렬적으로 다른 컴퓨터에서 실행됨. lint, tsc, unit test, e2e test, deploy 관련 job들에 대한 runner들을 각각 따로따로 사용할 수 있음
  • yarn 2 berry 같은 것을 사용하면 zero-install로 관리할 수 있음 (설치는 필요하지만 오래 걸리지 않음)
  • marketplace → checkout 보통 많이 사용함 (이것저것 설치하고 지정할 수 있음 → git log까지도 싹다 나옴) → commit과 push를 바로 해주는 작업도 존재함
  • 한번 cron scheduling과 관련해서 만들어보고 공유해보자
  • git hook, husky → 이 아이를 많이 쓴다! LifeCycle Hook과 관련된 command를 설정할 수 있다. package.json에 lint-staged를 통해 eslint 하기 전에 뭐뭐 하는 지 체크를 한다. 커밋을 하기 전에 yarn lint-staged를 수행한다. → 꼭 push를 해야만 할 수 있는 것은 아니다. 코딩 컨벤션 체크도 마찬가지로 할 수 있다. → eslint나 prettier → 이런 것들은 전체 코드에서 석용하면 너무 오래 걸리기 때문에 staged된 애들에 대해서만 실행할 수 있도록 하기!
  • main에 머지 prod에 배포 / dev에 머지 → …에 배포
  • Health Checking → 일정 주기마다 호출해보고, 정상적으로 확인해보기
⚠️ **GitHub.com Fallback** ⚠️