- React
사용자 인터페이스를 만들기 위한 라이브러리
사용 이유 ?
동적인 웹 페이지를 효율적으로 유지보수, 관리 목적
어떤 문제를 해결 하는지 ?
프로젝트 규모가 커지고, 다양한 유저 인터렉션 전달에 따른
DOM요소 변화시 렌더링 과정을 거치면서 브라우저 많은 연산
프로세스의 비효율성
=> DOM 관리와 상태 변화 관리를 최소화해서
개발자는 기능 개발, 사용자 인터페이스에 집중 가능
특징
-- 컴포넌트 단위 작성
생산성과 유지 보수 용이
-- JSX => JS + xml
리액트에서 element 요소를 제공해줌
--Virtual Dom
어떤게 바뀌었는지 파악하여 필요한 DOM 트리만 업데이트할 수 있게 해준다.
- 불변성 ( Immutable )
변하지 않는 상태를 유지하는 방법
메모리에 이미 담겨있는 값을 변경하지 않는것
=> 예측하지 못한 상태의 변경을 방어할 수 있다.
--리액트에서 this.x로 state 값 수정 가능한지 ?
state를 직접 조작해서는 안되고 setState를 사용 해야한다.
그래야 변경을 감지하고 리렌더링을 한다.
--리액트 라이프 사이클
componentDidMount
컴포넌트 출력물이 DOM에 렌더링 된 후에 실행 됨
componentWillUnmount
컴포넌트가 해제될시에 호출
shouldcomponentUpdate
렌더전에 false를 리턴하면 렌더를 취소할 수 있다 (성능 최적화)
-리덕스
하위, 상위 컴포넌트에 데이터를 props로 넘겨주는것을
프로젝트가 커짐에따라 관리하기가 힘듦
=> 한곳의 store에서 데이터를 관리하기 위해서 만들어짐
-- Redux-Saga, Redux-Thunk 만들어진 계기
리덕스의 규칙인 리듀서는 순수함수 이어야 한다.
즉 부수적인 효과 작업 불가능 (비동기 등)
부수적인 작업 처리를 위해 미들웨어가 생성됨
- Redux-Saga
리덕스의 사이드이펙트만을 담당하는 미들웨어
액션을 모니터링하고 있다가, 액션 발생시 해당 작업을 처리
특징으로 자바스크립트의 Generator 문법을 적극적으로 사용,
비동기 작업에 유용한 기능과, effects의 다양한 유틸 함수들 사용 가능
--Generator 문법은 뭔가 ?
함수의 흐름을 도중에 멈추었다가 이어서 진행 가능하게 해줌
yield => 값을 반환 코드 흐름은 멈춤
next => 코드 흐름이 이어서 시작 됨
-- Redux-thunk는 무엇인가 ?
리덕스 비동기 작업 처리시 사용하는 미들웨어
액션 객체가 아닌 함수를 디스패치 할 수 있다.
함수를 디스패치할때 dispatch, getState를 피라미터로 받아와야한다
이 함수를 만들어주는게 thunk 이다.
-- redux-Saga, redux-thunk의 차이점 ?
1. 액션 크리에이터 모양이 다르다
썽크: 썽크 크리에이터 함수 -> 타입 객체 디스패치
사가: 순수한 객체
2. 하나의 액션으로 store에 업데이트 가능 유무
썽크: 하나의 action으로 store에 업데이트 해줄 수 없다.
=> 컴포넌트단에 thunk creator => 그 안에서 dispatch를 통해 여러가지 원하는
작업을 진행
사가: 컴포넌트단에서 액션 디스패치 => 사가와 리듀서가 한번에 액션을
감지하고 알맞는 동작을 함 (store 업데이트, 비동기 작업)
-- 왜 Redux-Saga를 사용 했는지 ?
1. action이 순수한 객체라서 코드가 깔끔, 가독성이 좋음
2. 비동기 데이터 흐름을 보다 쉽게 테스트 가능
=> 액션은 리듀서와 통신 역할을 하고 사가는 액션 타입과 일치한 제너레이터 함수를 실행
3. effects 유틸 함수들이 굉장히 유용하다. (delay, take astest, put)
- 내가 만든 포폴 구조 설명
--프론트, 백엔드 서버구조
서버 앞단에 nginix 사용했고
http, https로 접근시 해당 포트로 이동해주는 reverse proxy 적용
--핵심 기능 speech-to-text 작동 원리
프론트:
인터뷰 진행 페이지::
소켓Io를 사용헤서 백엔드에서 stt 실행과
음성 인식된 실시간 데이터를 받고 브라우저에 값을 렌더링
백엔드:
타임스탬프 기능을 위한 해당 질문의 음성인식 시작 시간, 답변한 문장을 누적해서 저장
다음 문제로 넘어갈때:
소켓Io를 통해서 프론트 -> 백엔드에 다음 문제로 넘어간것을 알려주어서 알맞게 데이터를 저장함
=> 인터뷰가 끝날시에 타임스탬프 데이터를 프론트에 넘겨주고
프론트단에서 렌더링
-- 데이터 흐름
페이지에 서버사이드렌더링으로 로그인 유저 정보, 글 목록 등을 불러옴
사용자 인터렉션에 따른 액션 디스패치 -> 사가 제너레이터 함수 실행 -> 리덕스 상태에 저장 -> 바뀐 상태 리렌더링
--sql
관계형 데이터 베이스
엄격한 데이터 스키마
데이터를 동일한 테이블에 저장하고 참조하는 방식
장점
데이터의 무결성
데이터의 중복이 없음
정해진 스키마 틀이 있기 떄문에 구조 예측 용이
여러 데이터를 합쳐서 불러오기 수월
단점
테이블 재구성이 어렵고, 구조가 복잡
수직적 확장 가능, 수평적 확장 어려움
데이터 분산이 불가
--nosql
비관계형 데이터 베이스
스키마가 없음
모든 데이터를 하나의 컬렉션 안에 저장
데이터를 분산
장점
스키마가 없어서 유연하게 데이터 조정
데이터 저장이 편리
수직, 수평 확장이 가능
복잡한 조인을 사용 X
단점
유연성 데이터로 구조 결정이 힘듦
데이터의 중복으로 불완전한면
원하는 데이터 한번에 추출이 어려움
--어느때 어떤 sql을 사용?
sql
데이터가 자주 변경
변경 여지가 없는 명확한 스키마가 사용자,데이터에게 중요할때
nosql
정확한 데이터 구조를 알수 없거나 변경/확장 될 가능성이 있을때
데이터 읽기를 자주하고, 변경을 자주 안할때
데이터를 수평 확장 고려
- sql, nosql 차이
sql: 관계형 데이터베이스
nosql: 비관계형 데이스 베이스
sql: 엄격한 스키마
nosql: 스키마 없음
sql: 데이터를 여러 테이블에 나누어 담는다
nosql: 관련 데이터를 한 컬렉션에 모두 포함한다.
sql: 수직적 확장
nosql: 수평적 확장
-- MongoDB 사용 이유 ?
왠만한 서비스에서 데이터들은 서로 관계를 가지고 있기떄문에
sql이 적합하다고 생각
1. 이번 프로젝트 경우엔 기존에 사용했던 몽고디비를 더 능숙하게 다루고 싶었음
2. 데이터 스키마 구조가 복잡하지 않았음
3. 간결한 문법으로 사용 편리
=> issue:
해당 유저의 피드백글들을 렌더링할떄
어떤 인터뷰 글에 대한 피드백 글인지가 중요한 정보이기 때문에
유저 -> 피드백 -> 진행한 인터뷰 깊게 populate해서 데이터를 가져오고
오름차순 정렬, 글 8개씩 조건을 붙여서 가져오는
쿼리를 작성하는게 정말 힘든 작업이었다.
--------------------------------------
(0) 이 기술이 무엇인지?
(1) 왜 이 기술을 사용했는지
(2) 이 기술을 사용했을 때 장점/단점
(3) 이 기술말고 다른 방법은 뭐가 있는지