[ 엘리스 SW 엔지니어 트랙 ] 33일차

 📍 33일 차 12.9. 목. 실시간 강의

오늘은 graphQL, 인증에 대해서 배웠다. 실습시간 마지막에는 HTTP / HTTPS(SSL)의 차이, cookie-session, JWT 방식의 차이에 대해서 알려주셨는데 너무 유익했다. restAPI와 graphQL의 차이는 내겐 스승과도 같으신 튜터님 미디움을 참고하면 도움이 많이 된다.

---

❏ REST API vs gql API

1. gql 은 하나의 Endpoint 만 존재
2. REST API 는 End point 마다 데이터베이스 SQL 쿼리가 달라짐
3. gql API 는 gql 스키마의 타입마다 데이터베이스 SQL 쿼리가 달라짐

❏ GraphQL

1. FACEBOOK에서 2015년에 발표한 새로운 api 규격
2. type system 을 기본적으로 갖추고 있어서 REST 보다 훨씬 안정적
3. Apollo, Prisma 등 방대하고 강력한 오픈 소스 툴들로 양질의 개발자 경험 개선을 기대한다.
4. SDL(Schema Definition Language) : 서버에 무엇을 질의하여 값을 돌려받기를 원할 때 SDL로 기술(명확한 타입을 정의하여 기술)
5. CLI 로 post 요청 시 쌍 따옴표를 빼도 보내진다.

❏ OAuth

1. 접근권한 위임을 위한 공개 표준
2. 유저 진입장벽이 매우 낮아짐(원클릭으로 로그인 가능)
3. 유저가 비밀번호를 기억할 필요가 없어짐
4. 유저 허용 여부에 따라 이메일, 프로필 사진, 닉네임 등의 기본 정보를 얻을 수 있다.

728x90

❏ 기타 내용들

1. 프로젝트를 할 때 F/E 를 나누기보다는 기능별로 담당하자(ex, login + front + back / pay + front + back)과 같이 수평적으로 제작)
2. 프런트와 백을 나눠서 개발하면 속도에서 차이가 난다. (처음은 백엔드가 느리다. DB, 보안, 인프라 등등... 나중엔 반응형 때문에 프론트 개발 속도가 늦어진다. 서로 의견 충돌이 난다. 즉, 전체적인 프로젝트가 늦어지기 때문에 친한친구나 숙련된 분들과 하면 기능별로 쪼개서 개발하는 것을 권장한다.)
3. 템플릿 엔진: html 코드인데, 그 안에서 반복, 조건절로 view 를 만들어줄 때 사용한다.(일일이 따로 만들면 중복되는 코드가 많기 때문에 로직을 붙여서 자동으로 html 코드를 만들어줄 때) EJS, JADE -> PUG , nunjunks 사용빈도: nunjunks → EJS

1. nunjunks: EJS의 상위호환(html을 닮음), junja2의 영향을 받음(flask에서 나온?)
2. EJS: html을 닮음
3. pug: 문법이 특이해서 따로 공부해야함

4. passport : 로그인 구현 시 편리하게 도와주는 친구, 이게 없으면 header, session 관리를 직접 해줘야 한다. 써드파티 로그인도 지원한다.
5. 로그인 혹은 마이페이지를 보여주는 기능 등의 서버로부터 인증을 받아야 하는 상황일 때 선택지는 크게 3가지 cookie, cookie - session , JWT 방식이 있다. 서버는 절대 한 개로 운영하지 않고, 2개 이상으로 운영되는데 요청은 한 곳에서 들어온다. 이때 요청을 여러 개의 서버 중 한 곳으로 분배해주는 장치가 필요한데, 이것이 LB(load balancer 다. AWS 에서는 ELB(elastic load balancer) 라고 부른다.( elastic: 탄력적인, 고무의), cookie-session 는 DB 가 필요하고, JWT 는 DB 가 필요하지 않다.
6. cookie 방식은 클라이언트에 저장되는 key - value 로 이루어진 데이터다. 인증 유효시간을 설정할 수 있고, 유효시간이 정해진다면 클라이언트가 종료되어도 쿠키가 유지된다. 그러나, 중요정보를 쿠키에 담고 있으므로 해커에게 탈취당하면 사용자의 정보를 모두 빼앗길 수 있다. 그래서 쿠키 자체로는 보안과는 상관없는 개인 장바구니, 자동 로그인 설정 등에 사용한다.
7. cookie-session 방식은 client 에서 요청을 보내면 server 에서 cookie 의 값을 가지고 있다가 cookie 와 일치하는 session 을 해당 서버에서 찾고 cookie 를 사용자에게 보내준다. 그런데, 여러개의 서버가 연결되어있다고 가정해보자. server 1에 현재 cookie를 가지고 있다가 연결이 끊겨 다시 LB 를 거쳐가서 2번째 server 로 연결이 되면, cookie 가 없기 때문에 지금 요청한 사용자가 인가된 사용자인지 모른다. 이럴 때는 서버에 session 데이터를 저장하지않고, DB(redis) 를 이용해 해당 session 데이터를 DB 에 저장한다. DB 에서 쿠키에 맞는 세션 데이터를 찾고 해당하는 데이터가 있으면 리퀘스트를 돌려준다. DB 단이 붙었기 때문에 요청량이 많아지면 시간이 오래 걸릴 수 있다.
8. JWT 방식은 cookie-session 방식과 다르게 DB 단이 필요 없다. JWT 는 일종의 신분증이라고 생각하면 편하다. JWT 는 JSON web Token 를 뜻하는데, 토큰의 특성상 위조가 상당히 어렵다. 그러나 한번 탈취되면 보안에 굉장히 취약해진다. 이를 방지하고자 만료시간이 생겼다. 이때 만료시간은 보통 5-30분 길면 1주일 정도로 세팅한다. 요청이 오면 JWT 를 발급해준다. mypage 로 요청이 날아오면 요청과 함께 온 JWT 가 위조되었는지 확인한다. 서버에 저장되어있는 JWT 와 일치하면 mypage 요청을 같이 보내준다. cookie-session 방식처럼 DB 단에서 세션 데이터를 확인할 일이 사라진다.
9. http (80), https (443): 보안 유무, get 은 URL 에 post 는 http.body 에 요청이 넘어간다. 그래서 http.body 도 postman 같은 프로그램으로 열어볼 수 있다. 따라서 http 에서 get, post 의 보안은 안전하지 않다.(id, pw, cookie 가 평문으로 날아간다.) 특히, cookie 를 도청하게 되면 다른 사이트에서 재사용할 수 있따. (cookie 는 로그인을 성공한 사람에게 넘겨주기 때문에 노출되면 위험하다.) https 는 이런 id, pw, cookie 가 암호화가 되어 서버로 날아간다. 그래서 중간에 해커가 탈취하기 힘들다. curl 명령어
10. http -> https: DNS 가 담당한다. http 로 요청이 날라오면 DNS 에서 다시 클라이언트로 반송처리시키고 클라이언트에서 DNS 한테 https 로 요청하게 된다. server 에서 client 로 갈 때 https 로 변환한다.(항상 그런 것은 아니고 대부분 캐싱이 되어있어서 중간에 다시 옴)
11. SSL 인증서: 이 사이트가 안전한지 확인하는 인증서(대표적으로 AWS certificate manager에서 발급해준다. 인증기관에 비용을 지불하면 DNS 에 붙여준다. 만약, SSL 인증서가 없으면 다시 브라우저로 리턴하거나 에러를 발생시킨다.)
12. node template engine 은 서버에서 파일을 보내줘서 브라우 저단에서 띄우기만 한다. 이런 방식은 SSR, 반대로 CSR 은 리액트에서 파일을 만들고 데이터만 서버에 요청해서 둘 다 합치면 CSR 이 된다.
13. SSR 은 검색엔진이 데이터를 모두 읽을 수 있다. CSR 은 파일을 한번 거쳐서 탐색해야 하기 때문에 바로 노출이 되진 않는다(feat. CORS)
14. 리액트는 노드 서버에 직접 요청해서 받아오는 것은 아니다. 그냥 브라우저로 데이터를 보내주고 데이터는 브라우저에서 서버로 요청하여 브라우저에서 취합한다.
15. 로그인처럼 DB 사용하는 건 node.js 사용하고, 보여주기만 할 거면 CSR
16. 실 서비스할 때는 내부 웹서버보다 nginx를 직접 붙이는 편이 더 좋다. node.js 는 내부 웹서버도 배포하기 충분하다.
17. AWS - route 53 에서 DNS 에 SSL 을 직접 붙인다. ELB 에도 SSL 을 붙여야 한다. 이후 뒷단에 있는 EC2 서버로 넘어간다.
18. ELB를 쓰는 이유는 autoScaling 을 쓰기 위함이다.
19. 인스턴스를 늘릴 때는 사용률이 51%를 넘어섰을 때 이때 서버가 터져버리면 다음 서버는 @ + 51% 가 되는데 다음 서버가 50이면 서버가 터져버린다.