TIL 👩🏻‍💻

http요청을 처리하여 알맞은 응답을 보여주는 프로그램을 웹 서버라고 함

❖ CORS

=== Cross-origin resource sharing
이전에는 서버에서 다운로드된 클라이언트으로 통신하였으나, 웹앱이 고도화되면서 외부의 api를 가져오는 등 여러 곳의 리소스를 활용할 필요성 증가
*same origin이 아닌 다른 cross-origin에 request를 보내고 response를 받기 위해 허용한 범위 내 가능하도록 수정됨
웹어플리케이션, 브라우저의 클라이언트를 보호하기 위한 보안정책

❖ node server 구현

=== node.js 내장 http모듈을 사용하여 단순한 서버 구현

• 일종의 문법(http 요쳥, 응답을 처리하는 문서 작성)
  • createServer, writeHead 등
  • .on 으로 (addEventListener과 같은 느낌으로 이벤트 발생 시 콜백 수행)

    Express 에서 .next가 .then 과 같은 느낌

  • .end() (요청이 끝남, 'endgame', .json(), .send()**express 과 차이를 논하는 글이 많은 걸 보니 유사한 듯)
    - data는 여러번 올 수 있음, end는 한번만!(stream, buffer개념), chunk는 buffer, request객체는 stream임.(공식문서 참고)
    buffer : 데이터의 조각들이 쌓여서 스트리밍할 데이터가 완전히 다운로드됨(요청이 한번에 가지 않음, 사진img데이터 하나만 요청하여도

      .on('data', (chunk) => {
      body. push(chunk);
      }.on(...

    ⏏︎ 이 부분이 반복되는 것임

    * Node.js 의 buffer 크기는 일반적으로 사용자의 메모리 크기까지 유동적으로 커진다? fs 모듈의 stream 관련 함수들은 기본적으로 64kb이고 highwartermark로 따로 크기를 지정해줄 수 있다고.

• 🔗 Nodejs 공식문서의 HTTP 요청/응답 해부

const http = require('http');
http.createServer((request, response) => {
// const { headers, method, url } = request;
  let body = [];
  request.on('error', (err) => {
    console.error(err);
  }).on('data', (chunk) => {
    body.push(chunk); // 버퍼 축적
  }).on('end', () => {
    body = Buffer.concat(body).toString(); // 축적된 Buffer데이터 concat
    response.on('error', (err) => {
      console.error(err);
    });
    response.writeHead(200, {'Content-Type': 'application/json'})
//  const responseBody = { headers, method, url, body };
    response.end(JSON.stringify(responseBody))
  });
}).listen(8080); // 8080port에서

• 헤더 세팅

const defaultCorsHeader = {
  'Access-Control-Allow-Origin': '*', // 모든 주소를 클라이언트로 허용
  'Access-Control-Allow-Methods': 'GET, POST, PUT, DELETE, OPTIONS', // 허용하는 요청메소드
  'Access-Control-Allow-Headers': 'Content-Type, Accept',
  'Access-Control-Max-Age': 10 // preflighted request는 10초까지만 허용, 10초 이내에 요청이 왔다갔다 하는 경우는 preflight 안 보낸다는 의미
};

** cors 헤더도 express를 이용하면 미리 일일이 선언하지 않아도 된다.

🔎 header 내 'Access-Control-Allow-Origin'에 다른 도메인주소를 넣는다면?
❗️ 특정 origin(클라이언트 주소) 지정 시, 다른 포트에서는 접근 불가
serve 유틸리티를 활용하여 origin을 설정 npx serve -l 3000 > serve listen (Specify a URI endpoint on which to listen)

// client 서버가, 지정된 origin과 불일치 시 콘솔창에서 확인되는 에러
Access to fetch at 'http://localhost:3000/upper' from origin '~~' has been blocked by CORS policy: 
Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. 
If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

💱➿ When Harry met not Sally it's Error 🔣 ⚠️
내가 만난 에러

• Content-type 관련
  Uncaught (in promise) SyntaxError: Unexpected token ${sth} in JSON at position 0
  json 데이터를 보내주는 서버에서 데이터타입이 json 형식임을 명시하지 않아서 뱉는 에러
  → fetch 함수 내 header 항목의 Content-type, Accept를 설정해줌 'application/json'으로 해결
  🔎 'text/plain'으로 설정한다면? preflighted request(OPTIONS) 보내지 않음 즉 데이터 타입을 정확히 써줘야 된다는 의미로 보임
  ❗️ options요청은 cross-origin request가 들어왔을 때, 서버가 allow하는 조건을 충족하는지 사전에 확인하는 'preflighted request'이다. MDN

• Error 핸들링 관련

// node terminal에서
xxxx.js:$$$
      throw er; // Unhandled 'error' event
      ...
Emitted 'error' event on Server instance at:
...

🤔 에러를 throw하고 있으나 에러를 핸들링하는 게 없다는 뜻, createServer사용한 http요청/응답 처리 함수 내 로직에서 조건이 잘못 걸린 것으로 보여짐.
구현한 서버의 테스트케이스로는 에러발생할 로직이나 이벤트가 없어서 '에러'로서 핸들링하지 않고, 요청에 대한 응답을 에러 코드(http status code 400, 404, ..etc.,)를 writeHead로 처리.(?)

// console 창에서
ERR_STREAM_WRITE_AFTER_END

🤔 들어오는 요청의 형태(GET/POST/..)와 주소path에 따른 조건별로 응답을 end처리 할 것임(조건에 따른 분기, 라우팅), 따라서 조건 외 함수 내 젤 바깥 스코프에서 end로 응답처리를 해버린 것(조건 로직 위에서든 맨 마지막에서든)이 에러를 냄(조건을 다 거치고도 마지막 응답처리가 뒤집어씌워지는 것처럼 발견되었음) 응답을 한번만 할 수 있다고 생각하면됨. 실수 방지를 위해 return;을 해주기도 함

❖ 웹 서버와 앱 서버

웹 서버 (Web Server)
App Server는 웹 서버(Web Server), 웹 앱 서버(WAS, Web Application Server)를 포괄하는 상위 개념
웹 서버는 정적인 페이지 (이미지, html, js 등 컴퓨터 내 파일)를 반환,
동적 페이지는 들어온 요청에 맞게 동적으로 만들어진 컨텐츠
WAS는 Database, 로직을 거쳐야 하므로 정적인 컨텐츠는 Web Server에 처리하여 빠르게 제공하도록 => 기능을 분리하여 서버 부하를 방지
그 외 물리적으로 분리하여 보안을 강화하는 등 결론적으로, 자원 이용의 효율성 및 장애 극복, 배포 및 유지보수의 편의성을 위해 Web Server, WAS를 각기 사용한다.

• 디버깅
  (에디터 내 디버깅 기능과 크롬(웹브라우저) 개발자 도구의 node.js)
  package.json에서 dependency

  • nodemon
    • " --inspect; 디버깅
    • " --inspect-brk ; 코드 최초 로드(실행) 때 브레이크 포인트 잡음

• 주소창에 입력하는 것: GET 요청임

• 요청 body 받기

  • 응답 body 받기와 달리 어려움
  • 개념 두 가지 등장
    • stream
    • buffer
  
  

👩👩🏻‍💻 💻
내일은 Express Library로 mini node 서버를 리팩토링할 예정.
오늘 fetch로직과 http요청,응답 처리를 작성하는 등의 방식으로 서버를 구현해본 것과 달리 Express라이브러리가 단순화시켜주는 작업이 무엇인지, 그리고 미들웨어를 중점을 두고 학습