Skip to content

[week2]mentoring

yongseok edited this page Nov 16, 2022 · 7 revisions

상황공유

  • 전체적인 프로젝트 일정 (마일스톤) => 추후 webRTC 부하테스트 정보를 알려주실 예정
  • 피처리스트 확인(스프레드시트)
    • 주차별 계획 -> 데모시나리오 -> 과업 분배
    • image => 피처단위 시작전 필요사항을 토의하고 이야기를 나누기가 필요함
    • Github project 사용
  • FE
    • 메인페이지, 로그인 모달, 모의면접 생성글, 모의면접 리스트 페이지 작성
  • BE

질문하기

  1. next 초기 로딩

    • 초기 로딩 속도를 올리기 위해 다음과 같은 방법을 적용했습니다.
      1. serverside에서 데이터를 불러오지 않고, 클라이언트에서 불러온다. => 서버에서 데이터 응답을 기다렸다가 뿌려주면, 렌더링 자체는 빠르지만 데이터 기다리는 동안 block 되기 때문에
      2. Suspense를 사용하여 데이터 로딩 부분은 늦게 렌더링하게 할려했다 => 이것만 적용해도 헤더 먼저 렌더링 된 후 데이터 응답에 따라 데이터 부분이 렌더링 될줄 알았는데 안됐다. (이유가 무엇일지 잘 모르겠다. hydration과 관려이 있을지도?)
      3. Suspense와 dynamic loding(lazy loading)을 사용하여 문제를 해결했다 => dynamic import의 옵션을 ssr:false로 줘야하는 이유??, 요런식으로 렌더링 해도 괜찮을지
  2. 화상회의 프로그램 접속-피드백-종료 로직

    • Q1. 통신방식 (API, Socket) => 실시간 성이 아니라면 API로 통신 추천
    • Q2. 피드백 임시 저장 위치(메모리, 레디스, DB) => 로컬 스토리지도 방법이 될 수 있음
    • DB 읽어서 클라로 내리고, 메모리(레디스) 저장, 클라에서 정보를 메모리(레디스)에 저장, 최종완료시(피드백하러가기) DB저장
  1. 모의면접 [시작하기]로 접속시 3개의 질문 테이블(user_question , interview_question , sample_question)에서 면접관 질문지를 생성 -> 메모리 저장
  2. 서버 메모리에 저장 -> 서버 터지면 보완해보는 것은 어떤가요? (산술적 용량 계산해보기)
  3. 피드백 입력후 다음 질문 선택 시 메모리에 임시저장 -> 재접속시 메모리에서 값을 찾아서 전달
  4. 호스트의[피드백 확인하기] 클릭시 피드백 내용 DB에 저장 -> 메모리에서 피드백 클라로 전달 후 삭제
  5. 전체 피드백 출력 image
  1. Q.MVP를 만드는 과정에서 하드코딩 어느 수준이 적절한가? => 스프린트 종료시점에 리펙토링 한다고 생각해함
    • A. (하드코딩)프론트에서도 이력서 항목을 고유번호로 다루면 더 간단할까? => 미리 합의한 고유번호 테이블을 만들어놓으면 이미 있는 항목인지 db를 조회할 필요가 없을것 같긴 하다.
    • B. (확장고려)DB item 테이블을 만들고 우선은 손수 값을 넣어두지만, 나중에 관리자페이지에서 추가, 순서, 삭제를 가능하게 만들기
  1. 프론트에서 user/resume로 post 요청, body로 {"item": 1, "content": "hi"}와 같이 보낸다.
  2. 백엔드는 item 테이블에 1을 찾는다. 없으면 거절
  3. resume 테이블에 해당 id값과 유저 id를 외래키로 해서 저장한다.
  4. 이후 이력서 조회를 요청하면 resume 테이블에서 해당 유저 id에 해당하는 모든 row를 찾고, 각 항목의 id와 문자열을 포함해 응답한다. ex) 쿼리 조회값이 (item:1, content: "hi"), (item:2, content: "hello") 이면 {content: "프로젝트 경험: hi\n업무경험: hello" } image

생각거리

  • 기술발표: 기승전결을 갖추면 좋지않을까요?

문제가 발생했다.(왜 그랬을까?) -> 어떻게 할 수 있을까? -> 왜 그렇게 생각했나? -> 그렇게 하는것이 왜 좋을까?

  • SEO test: 라이트하우스로는 애매한 부분이 있음. 여러 방법을 고려해 볼 것
  • 기술이 오버엔지니어링으로 판단 되면 포기도 가능하다.
  • 앞으로 하고싶은 분야(프론트, 백 등), 원하는 도메인(금융, 커머스, 의료 등)을 고민해 볼 것.
Clone this wiki locally