개발자로 취업하려고 node 공부중입니다.

동작 방식 

call stack과 callback(Task) queue를 지속적으로 감시하면서

call stack이 빈 경우 callback(Task) queue에 작업이 있는지 확인 하고

call stack으로 옮기는 역활

존재 이유

Node의 특징인 Single Thread와 Non Blocking I/O를 이루어 주는게 이벤트 루프이다.

call stack (호출 스택)

스택은 LIFO형태의 자료 구조이다. 그렇다면 콜 스택은?

자바스크립트 안에서 실해되는 모든 함수의 호출을 기록한 스택

callback queue (대기열)

큐는 FIFO형태 자료구조 Event Queue에 적재된 callback을 call stack에 올려준다.

스레드(thread)

프로세스가 할당받은 자원을 이용하는 실행의 단위

멀티 vs 싱글

멀티 : CPU의 최대 활용을 위해 프로그램의 둘 이상을 동시에 실행하는 기술 컨텍스트 스위칭을 통해 이루어짐

장 : 스레드 하나가 죽어도 다른 스레드로 작업을 이어간다

단 : 느림, 프로그래밍 난이도가 높다.

싱글 : 하나의 프로세스에서 하나의 스레드로만 실행

장 : 컨텍스트 스위칭 작업이 필요없음, 자원 접근에 대한 신경쓰지 않는다, 난이도가 쉽다, 메모리 적게사용

단 : 여러개의 CPU 활용하지 못한다. 에러를 처리 못하면 멈춘다.

노드는?

비동기 I/O, 단일 스레드 이벤트 루프 기반으로 동작 -> 요청 처리 성능이 좋다.

옛날 방식 

DB에 id/pw이 있으면 session에 로그인 기록을 저장 sessionid를 클라이언트에 보내줌 클라이언트와 sessionid를 통해서 인증,인가함
문제점 :  백엔드 서버 사용자가 늘어났을 때 scale out(서버 증설)시 stateful한 상태가 되게된다. -> session 정보를 DB에서 관리를 해준다.

문제점 : DB에 I/O가 늘어서 부담이 늘어남 -> DB를 늘리면 모든 DB에 같은 정보가 들어가야함 (더 문제) -> DB를 쪼갠다.

DB를 어떻게 나누나?

수직 파티셔닝

수평 파티셔닝 = DB 샤딩 ex) 1~10000을 DB1, 10001 ~ 20000을 DB2로 나누는

메모리 vs 디스크 : 영구성, 속도

메모리 전용 DB : Redis = DB를 긁는게 느려서 메모리에 저장하는 방식 

각각의 Redis에 토큰 정보를 저장하고 조회하는 방식

JWT Token : 최근 방식

Json Web Token 객체타입으로 {email : adlfal, isLogin: true}를 암호화와 복호화를 통해 로그인 확인하는

JWT의 복화와 관련은 백엔드서버가 가지고 JWT를 Br과 B에서 서로 주고받으며 B에서 복호화함으로 로그인을 인증함

-> DB를 거의 안가고도 로그인을 검증 할 수 있음

암호화

1. 양방향 - 복호화 가능

2. 단방향 - 복호화 불가능

비밀번호는 단방향으로 암호화 해야함 = Hash

해커들이 발전하며 Hash를 경우의 수를 돌리며 Ranibow Table을 만듦 -> salt라는 현재 해결책을 사용함

salt : Hash 중간 임의의 문자를 넣어줌

프로그래밍 설계를 할 때 문제점들을 해결 하기 위해 사용되는 패턴

1. 싱글톤 패턴 : 한 Class는 하나의 인스턴스만 가지는 패턴 - DB 모듈에 많이 씀
   장점 : 메모리 낭비를 막음(생성비용), 데이터 공유가 쉬움
   단점 : 의존성이 높아짐(DI로 해결), 테스트가 어려워짐(단위 테스트때 어려움)
   의존성 주입(DI) : 메인 모듈이 직접 의존성을 주는것이 아닌 의존성 주입자를 이용 메인 모듈이 '간접'적으로 의존성을 주입
   장점: 모듈을 쉽게 교체, 테스트 쉬워짐
   단점 : 더 많은 모듈이 만들어져서 복잡해짐
2. 팩토리 패턴

xss : Cross-Site Scripting Attack -> web application에 script를 주입해서 정보를 빼냄

리액트는 자체로 어느정도 막아는줌

로컬 저장소에 중요한 내용을 넣으면 안됨 -> 근본적인 문제 해결

1. In memory : 로그인을 계속 해야

2. Cookies httpOnly 설정 : 웹에서만 작동이 된다, CSRF에 취약함

https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Access-Control-Allow-Credentials

배포전 확인 할것

코드안에 중요한 정보들이 들어있는지 -> 환경변수

Log 및 결과 출력에 불필요한게 있는지 -> 비밀번호등

API limit Rate를 설정해야 한다. -> 주기적, 반복적 접근을 방지해야한다.

호스팅 고르는 법

요구사항에 맞는 호스팅을 골라야 한다.

1. 웹서버 or Static Hosting

2. 어떤 DB를 쓸지

3. CDN이 필요한지

4. 서버의 file 시스템에 접근해서 읽어와야 하는지

5. TLS가 필요한지

6. 어떤 위치에 있는 서버가 필요한지

어떻게 운영할지에 맞는 서버를 

DIY <--------------------> Fully managed

내가 전부 설정                          알아서 관리

DIY : google cloud, aws, azure등 클라우드 시스템

Fully managed : heroku, netlify, platform.sh

-> AWS EC2를 기본으로 알고 넘어가야겠다.

배포 너무 어렵다.......

mongoose는 schema를 이용해서 mongoDB의 데이터 안정성을 지켜주는 역활은 해준다. 사용이 쉬워진다.

mongoose는 Schema가 중요 -> 매핑해줌 mongoose는 _id가 없으면 에러가 난다.

virtual은 가상 변수를 설정할 수 있다. -> 포스트맨에서 "__v" : 0 다음 virtual 값이 나온다.

진짜 저장되는 값은 아님 오직 읽기용?

toObject를 통해 POJO로 변환해야 된다고함 -> Document와 POJO가 다른 형태라고 함...

toJSON은 toObject와 비슷

https://colinch4.github.io/2020-12-03/README.mongoose-01_Schemas/

https://velog.io/@modolee/mongodb-document-to-javascript-object

Flat-File Database 파일에 데이터를 저장하는 방식 : 단점이 많음 -> 해결을 위해 DBMS 사용

DBMS : Database Mangaement System 데이터베이스를 관리해 주는 엔진

DBMS 종류

1974년 SQL [Structured Query Language] (RDBMS)  : 구조적인 질의응답을 할 수 있는 언어 

1998년 NoSQL : BigData, json 형태 데이터를 관계형으로 정리하기 어려워짐

RDBMS(RelationDBMS) 관계형 

스키마(SCHEMA)를 이용해서 데이터 정리, 타입 정의 가능, 관계 맺을 수 있음 관계를 읽고 쓸때 SQL을 사용함

Data integrity를 보장함 -> 데이터가 틀리지 않는다.

PK : 고유 식별자, FK : 관계를 정의해 줌

SQL : select 무엇을 선택할지 from 어떤 테이블에서 가져올지 where 조건

종류 : MySQL(가장 기본), PostgresSQL(가장 최근, MySQL에 비해 조금 복잡 + 쿼리가 미묘하게 다름), SQLite(가장 심플)

NoSQL No schema

왜? : object를 그냥 저장 할 수 있지 않을까? 

schema-less, Non-relation, 용도에 따라 저장 형태가 다름

key-value(Redis), document(MongoDB), wide-Column(Cloud Bigtable), Graph(neo4j) 형태가 있음

몽고DB : document 형태, document를 묶는 collections가 존재, 유저 collections, 상품 collections로 관계없이 저장

관계가 없어서 데이터를 중복해서 저장. 정보의 일관성은 코드에서 해결 -> 개별적으로 데이터 저장

ORM / ODM

ORM (Object Relational Mapping)

코드 와 DB 사이의 연결의 번거로움을 해결해주는 프로그램 -> 코드에서 스키마를 정의하면 ORM이 자동으로 DB에 테이블을 만들고 DB에 저장해줌 (추상화해줌)

장 : 비즈니스로직에 집중가능, 반복되는 쿼리를 줄여줌, DB가 달라져도 적용됨, 마이그레이션 도움

단 : ORM만으로는 상세한 쿼리 불가-> 복잡한 내용은 직접 쿼리를 사용, 최적화에는 맞지 않음

종류 : TypeORM, Sequelize, Prisma

ODM (Object Document Mapper)

object를 document로 매핑해줌

그럼 SQL과 NoSQL 선택은?

1. 어떤 데이터 타입을 저장 할지

2. 사용자와 데이터 량

3. 서로 관계가 필요한지

하이브리드 approach - 같은 소프트웨어라도 부분적으로 SQL,NoSQL을 섞어서 사용

HTTP 통신은 브라우저에서 요청이 서버로 왔을 때만 서버에서 응답을 해줄 수 있다.

WebSocket은 클라이언트와 서버에 connection을 만들어 놓으면 양방향에서 서로 필요할때 주고 받을 수 있다.

Node에서는 Socket.io 라이브러리를 이용해서 쉽게 구현 할 수 있다. (브라우저간의 호환, 버전간의 호환에 유리)

서버 

1. npm i socket.Io 설치

http서버를 socket.io를 이용 socket.io 서버로 진화, new Server(server, {옵션}) 옵션에는 다양한 것을 넣을 수 있다 연결확인, 몇초 간격으로 확인 할지, cors 허용등 다양하게 있다.

socketIO.on으로 클라이언트가 서버에 접속을 했을 때 connection 이벤트를 발생 

emit으로 메세지를 전송하는데 받는 대상을 정할 수 있다. -> 인터넷에 많음

https://velog.io/@hyex/socket.io-%EC%82%AC%EC%9A%A9%ED%95%A0-Client-API

Auth

socket.handshake.auth.token으로 token을 이용가능

도커의 구조

운영체제 위에 도커 엔진이 동작하고 그 위에서 컨테이너가 동작한다. 모든 컨테이너에는 '리눅스 운영체제 비슷한 무언가'가 들어 있다.

운영체제? -> 소프트웨어나 프로그램의 명령을 하드웨어에 전달하는 역활

도커는 리눅스 컴퓨터에 독립된 격리 환경을 만드는 것이며, 리눅스에서만 동작하고, 컨테이너에서 동작할 프로그램도 리눅스용 프로그램

-> compose 할때 문제가 생기는 이유가 이것 때문이다.  : 어떤 형태로든 mac에서 리눅스를 이용해야한다.

도커 허브와 이미지, 그리고 컨테이너

이미지 : 컨테이너의 설계도, 이미지를 공유함으로 같은 내용의 컨테이너를 많이 여러명에게 만들 수 있다.

도커 허브 : 공개된 컨테이너 이미지가 모여 있는 곳

다양한 형태로 조합이 가능한 컨테이너 : 한 컨테이너에는 한 프로그램만이 원칙이다. 한 곳에 몰아 넣을 수 있긴 하지만 비추한다고한다.

도커 컨테이너의 생애주기와 데이터 저장

도커 컨테이너는 '쓰고 버리는' 일회용품 이다. -> 여러 개를 동시 가동하는 상황을 전재로 하기 때문'

그럼 데이터는? -> 마운트를 해서 해결한다. 볼륨 마운트, 바인드 마운트 이용

도커의 장점

한 대의 물리 서버에 여러대의 서버를 띄울 수 있다 : 컨테이너로 격리되어 안전한 상태로 실행됨

서버 관리가 용이하다 : 서로 격리되어 영향 없음

도커의 단점

호스트 서버에 문제가 생기면 모든 컨테이너에 영향이 미친다.

도커의 주 용도

1. 팀원 모두 동일한 개발환경 제공

2. 새로운 버전의 테스트 

3. 동일한 서버가 여러대 필요한 경우 : 동일한 서버가 여러 대 필요한 경우 컨테이너를 이용해 한 대의 물리 서버에 똑같은 서버를 여러개 만들 수 있다. -> 오케스트라 필요

Docker  : 데이터 또는 프로그램을 격리 시키는 기능을 제공하는 소프트웨어

다양한 프로그램과 데이터를 각각 독립된 환경에 격리하는 기능을 제공

격리해야 하는 이유

프로그램간의 실행 환경과 버전, 환경변수등이 오류를 만들어내기 때문에 

대부분의 프로그램은 단독으로 동작하는 것이 아니라 어떤 실행 환경이나 라이브러리, 다른 드로그램을 이용해 동작한다.

ex) PHP로 작성된 프로그램을 실행시키려면 PHP 실행 환경이 필요

프로그램을 하나 업데이트 -> 다른 프로그램에 영향을 미침 -> 서버에서는 여러 프로그램이 함께 동작하므로 서버를 처음 구축할 때부터 신중하게 따져봐야한다. -> 설계 할때 문저 없어도 실제로 오류가 생기면 대부분의 원인은 프로그램간의 공유가 원인

컨테이너 : 분리된 환경

컨테이너에 들어있는 프로그램은 다른 프로그램과 격리된 상태가 된다.

서버와 도커

서버 : 어떤 서비스(service)를 제공(serve)하는 것 -> 메일 서버, 웹 서버등으로 기능별로 서버 분리가 가능

서버의 기능은 소프트웨어가 제공한다. -> 메일 서버용 소프트웨어 설치 : 메일 서버, 웹 서버용 소프트웨어 설치 : 웹 서버

도커 : 컨테이너를 이용하여 서버 구성의 차이를 무시 할 수 있다.