오늘 배운 것
- 클라이언트 - 서버의 통신 과정에 대해서 간략하게 정리
- Fetch API 호출 결과를 promise - then, Promise.all, async / await 세 가지 방법으로 핸들링.
- 프론트엔드 개발자가 왜 자료구조와 알고리즘을 알고있어야 하는가? - 스터디 주제
새롭게 알게된 것
API 요청과 응답은 어떻게 이루어지는가?
- 클라이언트(브라우저) 측에서 request 요청을 보내면, 서버가 그에 응답하여 해당하는 데이터를 클라이언트측으로 response 한다. 이를 Request-Response 모델 혹은 Client-server 모델이라고 한다.
- https://friedegg556.tistory.com/manage 라는 url이 있을 때, http 혹은 https 부분을 프로토콜, friedegg556.tistory.com 부분은 도메인 이름, /manage 는 리소스 (접근하고자 하는 타겟) 라고 부른다.
- 도메인 이름이란 말 그대로 이름일 뿐, 실제 서버의 주소는 아니다. 따라서 먼저 이를 진짜 서버 주소로 변환하는 작업이 필요하다. 이런 과정을 (어디선가 들어본...) DNS 라는 것을 통해 실행하는데, DNS는 Domain Name Server의 약자로, 인터넷 세상의 주소록과 같은 특별한 서버라고 할 수 있다.
- DNS에서 도메인 주소에 맞는 실제 서버의 IP 주소를 보내오면, 클라이언트 측에서는 최종적으로 프로토콜, IP주소, 그리고 서브 주소라고 할 수 있는 PORT 번호를 가지고 웹서버에 요청 request를 보내게된다. (port 번호는 리소스와 다름)
- TCP/ IP 소켓이라는 것을 통해서 클라이언트와 웹 서버가 연결된다. TCP/ IP라는 것은 클라이언트와 서버가 원활이 소통할 수 있는 약속? 통신 규약이라고 볼 수 있다.
- 클라이언트 측에서 서버측으로 HTTP 리퀘스트를 보낸다. HTTP란 HyperText Transfer Protocol의 약자이며, 이것도 뭔가 통신 메시지를 주고받을 수 있는 규약이라고 볼 수 있다. (프로토콜이 어떤 규칙, 체계라는 의미이다.) HTTP 리퀘스트 안에는 어떤 메서드를 사용하는지(GET이냐 POST냐), 요청 타겟 (리소스)는 무엇인지, HTTP 버전이 무엇인지와 같은 메시지가 있고, 그 뒤에 해당 request에 대한 정보를 담고있는 헤더와, post 처럼 데이터를 전달하는 경우 첨부하는 request body가 포함되어 있다.
- 전달된 request에 따라서 서버에서는 다시 클라이언트 쪽으로 HTTP response를 보내준다. 여기에는 성공적인 상태일때는 200코드와 ok 메시지가, 에러가 일어난다면 그 에러에 대한 코드와 메시지를 첨부하여 보내준다. (흔히 알고있는 404 NOT FOUND 가 여기서 오는 것이다...! )
- API에 요청을 하는 것도, 웹 상에서 어떤 페이지를 로드하는것도 전부 이런 HTTP request와 response를 통해서 이루어진다. 페이지에 접속하려는 경우에는 먼저 HTML 파일을 서버에 요청하고, 해당 html 파일을 통해 각각의 JS, CSS 파일을 요청하며 HTTP 통신이 발생한다.
Fetch API
- Fetch 란 url을 통해서 서버에 데이터를 요청하고 이를 받아올 수 있는 ajax 콜의 한 방식이다. fetch 함수에 url을 넣어 전달하면 result 데이터를 담고 있는 프로미스 객체를 리턴하기 때문에, 이를 then이나 catch로 체이닝해서 활용할 수 있다. fetch가 프로미스 객체를 리턴한다는 사실을 알고있으면 비동기 처리를 다루는 여러 방법들을 가지고 (then 체이닝 혹은 promise.all, async/awiat) 다양하게 활용할 수 있다.
promise 연습 과제를 진행하면서 겪은 것들
- 에러라고 표현하기 민망한 수준이어서 그냥 겪은 것들 이라는 이름을 붙여보았다. 어제 오늘 promise 객체를 활용해 여러 방법으로 데이터를 가공하고 리턴하는 연습을 했다. 그 중에서 문제 풀이를 어렵게 만들었던 개념이 있어서 정리해보려고 한다.
비동기 함수의 처리 결과는 무조건 프로미스 메서드 체이닝 내부에서만 사용할 수 있는것인가? 메서드 체이닝 바깥쪽에서는 접근할 수 없는 것인가?
- 실시간 세션에서 질문했던 것이다. 이런 질문을 하게 된 계기가 프로미스 객체에서 then 체이닝으로 객체를 가공하고 그것을 체이닝 바깥쪽에서 접근하려고 했는데, undefined이거나 결과값이 적용이 안된 빈 객체였다.
- 일단 여기에서 크게 두 가지 포인트를 짚고 넘어가야 한다. 하나는 프로미스가 비동기 처리 결과라는 것, 그리고 then 메서드들이 각각의 스코프를 형성하고 있다는 것.
- 먼저 전역변수 result라는 배열을 생성하고, then메서드 안에서 result에 결과값을 넣은 뒤 콘솔에 출력을 했을 때 결과값이 담긴 배열이 아닌 그냥 빈 배열이 출력되었다. 문제를 풀 당시에는 도대체 뭐가 문제인지 몰랐는데, 다시 생각해보니 프로미스가 비동기 처리의 결과라는 것은 프로미스가 이행이 될 동안 그 다음 코드가 먼저 실행된다는 것이다. 따라서 프로미스는 백그라운드에서 이행이 되고 결과값이 반영되지 않은 시점의 콘솔이 출력되기 때문에 계속 빈 배열이 출력되었던 것이다.
- 그 다음으로, 각 메서드가 스코프를 형성하기 때문에 스코프의 규칙에 따라서 그 내부에서 선언된 데이터들은 스코프 외부에서는 접근할 수 없다. 따라서 메서드의 스코프 내에서만 데이터에 접근할 수 있다.
- 일단 라이브세션에서 이 개념에 대해서 설명해주신 뒤 덧붙여서 이벤트루프에 대한 것도 알고있어야 한다고 말씀해주셨는데, 시간을 내어서 공부해보아야겠다.
프론트엔드 개발자가 왜 자료구조와 알고리즘을 알아야할까.
- 사실 모든 내용을 이해한 것은 아니라서 자세하게 정리할 수는 없다. 그래도 정리해보자면 과거에 비해 프론트엔드의 영역이 점점 늘어나고 디자인이나 퍼블리싱보다 UI 기능 개발에 더 초점이 맞추어지다보니 자연스럽게 데이터와 관련된 지식에 대해서도 많이 알아야하는 것 같다.
- 일반 소비자의 입장에서 보아도 보여지는 웹페이지들이 성능이 좋아지고 더 복잡한 기능을 갖게 되었다는건 확실한 것 같다. 그저 HTML로 짜여진 웹페이지를 보여주는 것을 넘어서 복잡한 구조와 기능을 하는 것이 요즘의 웹사이트이니까! 그만큼 프론트엔드의 전문성이 더 증가하고 요구되는 역량이 점점 더 높아지는게 아닌가라는 생각도 들었다.
- 서버를 직접 다루는 백엔드개발자 만큼의 알고리즘, 자료구조 지식은 아니더라도 이에 대한 충분한 이해도가 있는것이 역시 없는 것보다는 나을 것이고, 프론트엔드 개발자이기 이전에 개발자이기 때문에 필수적으로 알고있는게 좋지 않을까싶다.
SUMMARY
잘 한 점
- 오늘 페어를 하면서 페어님이 이렇게 열정적으로 하는 사람은 처음봤다는 말을 해주셨다. 이게 나한테는 엄청난 칭찬이었고 기분이 너무 좋았다. 설명을 잘 못했다고 생각했는데 그냥 하시는 말씀인지는 몰라도 이해하는데 도움이 많이 되었다고 하셔서... 정말 열정적으로 참여하길 잘한 것 같고, 앞으로도 그렇게 할 것이다.
- 문제를 풀고 그냥 넘어가는 것이 아니라, 본인이 짠 코드에 대해 설명하는 연습을 하고 사용한 개념에 대해서 정리하는 시간을 꼭꼭 가지고 넘어갔다. 그리고 모든 문제를 다 풀었을 때는 하나씩 리뷰하면서 어떤 점이 어려웠는지 모르는 부분은 무엇인지 정리하고 넘어갔다.
- 모르는 부분에 대해서는 무엇이라도 질문하기 위해서 미리 질문을 작성했다. 질문을 작성하는 과정에서 어떤 부분이 부족한지 명확하게 알게 되었고, 또 스스로 답을 찾아 해결할 수 있었던 문제도 있다. 심지어는 이미 질문을 했는데 질문을 하자마자 스스로 답을 깨우쳐서 답변 안해도 된다고 말한적도 있다. ㅋㅋ 혼자 아 이거 어렵네 하는 것 보다 정확하게 질문을 하는게 도움이 많이 되는 것 같다.
보완할 점
- 경청하기
: 많은 사람들과 페어를 하면서, 그리고 스터디를 진행하면서 상대방의 말을 경청하고, 요점에 맞는 답변을 하는 연습이 필요하다고 느꼈다. 내가 알고 있는 개념을 조리있게, 알아듣기 쉽게 '말하는 것'도 중요한데 그만큼 듣고 원하는 답변을 해주는게 어려운 것 같다. 근데 오랜시간 과제를 진행하다보면 집중력도 흐려지고 힘이들어서 의식적으로 그렇게 하기가 힘든 것도 사실이다 ㅜ. 근데 협업에서는 엄청 중요한 역량이기 때문에 지금부터 연습해야겠다. - 스터디 개선점 찾기
: 우리 스터디에서는 매주 1회 발표를 하는데 그 발표 주제를 다른 스터디처럼 명확한 가이드라인에 맞춰 진행하는게 좋은건지 아니면 곁다리 발표라는 목적에 맞게 원하는 주제를 하는게 맞는건지. 일단 정해진 범위가 있으면 부담이 될 것 같아 자율적으로 운영하려고 하는데 개선점에 대해서는 계속 고민을 해보는게 맞는 것 같다. 추후 다른 스터디를 할 때 도움이 많이 될 것 같다. - 프로미스 활용 연습하기
: 프로미스가 실무에서 정말 많이 쓰인다고 말씀해주셨는데, 아직 활용을 하는 것은 낯선 것 같다. 특히 일반적인 함수에서 값을 리턴하는 것과 달리 프로미스 객체를 리턴한다는 부분이 더 헷갈리는 포인트... 주말동안에는 예제를 꼭 만들어서 연습해봐야겠다...!
느낀 점
- 비동기를 진행하는 3일동안 너무 힘들었고 재미도 있었고 느낀점도 많아서 오늘의 잘한 점과 보완할 점은 평소랑 다르게 엄청 길어진 것 같다. 처음에는 이해가 안되는 부분도 많이 있었는데, 지금은 어느정도 개념이해는 된 것 같다. 도움이 되었던 부분은 역시 무엇을 모르는지 명확하게 짚고 넘어간 것과, 제대로 알고있는지 파악하기 - 설명해보기.
- 근데 공부도 중요한데, 건강이나 다른 삶도 중요하기 때문에 과몰입을 좀 자제해야겠다. 사실 오늘 과제 일찍 끝내고 한시간정도 누워서 쉬었는데 진짜 좋았다. ㅋㅋ
'TIL' 카테고리의 다른 글
[Day 29] 2022-0802 : props, state 활용해 SPA 만들기 (0) | 2022.08.03 |
---|---|
[Day 28] 2022-0801 : SPA와 리액트 라우터/ useNavigate (0) | 2022.08.01 |
[Day 25] 2022-0727 : 프로미스와 한 판 붙은 하루 (0) | 2022.07.28 |
[Day 24] 2022-0726 : 내장 함수 직접 구현하기, 비동기 Day (0) | 2022.07.26 |
[Day 23] 2022-0725 : 쉬운 듯 어려웠던 ES6 클래스 문법 + props (0) | 2022.07.25 |