항해99_3주차 회고록

2주차 회고록을 쓴 게 엊그제 같은데 또 폭풍같이 일주일이 흘렀다.

마음같아서는 매일매일 TIL도 작성하고 싶지만 쉽지 않다.

 

이번주는 저번주 금요일 부터 시작된 주특기 입문에 이어 주특기 숙련 주차였다.

새로운 강의를 들어야 하나 싶었는데 이번 주차도 입문주차에 지급받은 강의를 토대로 개인과제를 하는거여서

조금은 다행이었다.

열심히 강의를 돌려보며 이해하려고 노력중인데, 확실히 1주차때는 강의를 1~5주차를 완강했을때 무슨말인지 몰랐었다면, 다시 처음으로 돌아가서 반복해서 듣다보니 이해가 되는부분이 점점 생기기 시작했다.

시간이 너무 빨리 지나가고, 그 안에서 해내야 할 과제가 있으니 시간이 조금만 더 있었으면..싶은 마음이다.

3주동안 이 많은 정보를 이해하고 학습할 수있을지 걱정이 되지만 그래도 1주차 개인 과제때는 스스로 할 수 없다는 생각이 머릿속을 지배했다면, 2주차 개인과제를 대하는 생각은 좀 달라졌다. 혼자 해내보고 싶다는 생각?

이것만으로도 아주 조금씩 발전하고 있는게 아닐까 싶다.

 

WIL(Weekly I Learnd)

: DOM / 서버리스

 

1) DOM

  : HTML 단위(요소) 하나하나를 객체 취급하는 모델. 트리구조!

 

가상 DOM은 뭐지?

: 눈에 보이지 않는 메모리상에서 돌아가는 가짜 DOM. 

 

어떻게 돌아가?

어떤 행동을 하면(변화) 일단 가상 DOM에 올려(새로 그리기) → 진짜 DOM과 비교 →  바뀐부분만 마지막에 진짜          DOM에 반영

 

진짜 DOM과 가상 DOM을 비교할 때 뭐가 바뀐지 어떻게 알지?

=>그래서 비교를 하기 위해서는 key값이 필요하다!

 

생성 → 업데이트 → 제거

 

constructor(생성자 함수) : 컴포넌트에 필요한 어떤 값을 넣어주는 것

 

render : 변경된 내용이 가상 DOM 에서 진짜 DOM으로 올라가는 과정. 

• New props : 부모가 자식에서 주는 데이터가 바뀌었을 때
• setState() : 내가 가진 데이터가 바뀌었을 때
• forceUpdate : 강제로 업데이트 일으킴(강제 수정)
• 부모 컴포넌트가 업데이트 되었을 때

나 이제 바뀔꺼야! 근데 뭘로 바뀔거야?

=>render 안 return 안에 넣어주기

(Mount는 끝난 상태임)

 

componentDidMount : render가 끝났을때(진짜 DOM에 잘 붙었을 때)

: 첫번째 렌더링이 끝난 후 진짜 DOM에 올라간 뒤 딱 한번만 실행됨. 업데이트(리렌더링) 시에는 실행되지 않음

• 돔 관련 처리 가능

 

componentDidUpdate : 나 변경사항 업데이트 됐어! (리렌더링)

: 리렌더링이 끝난 후 호출됨( 이미 가상 DOM이 실제 DOM으로 올라간 뒤)

• componentDidUpdate(prevProps, prevState)

                                                      → 업데이트 되기 전의 prop(부모가 준 거)와 state(내 꺼)

• 돔 관련 처리 가능

componentWillUnmount : 나 이제 사라진다!

 

 2)그럼 진짜 DOM은 언제 새로 그리지?

• 처음 페이지 진입 시
• 데이터가 변해서 마지막에 가상돔에서 변경된 부분이 적용될 때

왜 진짜 DOM에 바로 변경사항을 적용 안해? 그렇게 느려?=> 사이트 구조에 따라서 가상 DOM을 쓰는 것보다 진짜 DOM을 직접 만지는게 더 빠를수도! 아니면 더 느릴수도!

 

 

※ 서버리스(Serverless)

: 서버가 없다? 라고 생각할 수 있지만 사실상 서버가 없는건 아니다. 그저, 특정 작업을 수행하기 위해서 컴퓨터를 혹은 가상머신에 서버를 설정하고, 이를 통하여 처리 하는 것이 아님을 의미한다.

 

(클라우드 컴퓨팅의 모델 중 하나로 사용자가 서버를 직접 관리할 필요가 없는 모델을 의미!)

 

1)활용

 

서버리스를 활용하면 백엔드에 서버를 올리는 것이 아니다.

백엔드를 작은 함수단으로 쪼개서 직접 관리하지 않는 서버로 올린다.( ex. 파이어베이스, AWS 람다)

리퀘스트를 보낼때마다 잠들어있던 함수들을 깨워 요청을 수행한다.

 

2)추천 및 장점

 

사이드 프로젝트를 준비하거나 최대한 빠르게 프로토타입을 출시하고 싶은 경우 추천서버리스로 작업시 코드에만 집중 가능

→ 서버를 관리하고 설정하는데 시간을 아낄 수 있다는 것! 

 

3)단점

 

잠들어있던 함수를 깨울 때 항시 대기중인 보통 서버와는 달리 시간이 소요됨시간차가 많은 것은 아니지만 이 시간차도 허용이 안될 경우 서버리스 선택 고려 필요

 

이러한 단점으로 인해 일부 서버리스 모델은 리퀘스트 시 빠른 대응을 위해 자주 쓰이는 함수들을 보통서버처럼 대기 시킨다고 함

 

 

서버 제공자에게 너무 의지하게 됨. 무슨뜻이냐면 한번 서버리스 모델을 선택할 경우 다른 서버리스 모델로 마이그레이팅 하는 것이 쉽지 않음

 

서버리스로 작업시 서버에 대한 통제력을 잃어 어플리케이션의 구조자체를 변경해줘야 하기 때문