몽구스를 이용해서 체크리스트 부분만 뜯어내서
JSON.stringify 해서
몽고디비에 넣고 , 빼고를 할수있다.
그래서
칸반보드의 데이터를 get요청하고나 post요청하면
불러오고,삭제하고를 할수있다.
우리는 데이터를 한번에 그리고, 한번에 저장하므로
업데이트라고 불리울만한 메서드는 딱히없어서
특정 칼럼을 변경하는 db동작은 없다.
그저 요청이오면 기존에있던것 날리고, 새것을 등록할뿐.
데이터 전달하기
어떻게하는지 처음에 res.app ?
res.locals?
이런게 있기는한데
같이 백엔드 하시는 송이님깨서
타입스크립트의 커스텀 타입을 추가해서
req.user_email 타입과
req.user_id 타입을 따로만들어서
res.locals 처럼 사용할수있게 되었다.
res.locals보다 , req객체에 넣어주는게 좋다고하더라. (보안상?)
근데 타입스크립트라 그냥 넣는게 안돼서
req객체의 타입을 커스터마이징 해준거같다.
도메인 구매사이트에서는 4가지이상 주소를 등록할수있다.
도메인을 사니까 네임서버들을 등록할수있는데
이게뭐냐면,
aws의 라우트53과 연결하면 이해하기조금 쉽다.
라우트53에서 내가 가지고있는 S3 혹은 , cloudfront 를
라우트53을 통해서 객체(??명칭까먹음) 화 하면
라우트53에서 주는 값이있다.
거기의 네임서버들을 긁어서 (마지막에 붙은 . 은 빼줘야함)
도메인 구매 사이트에 등록해준다.
그리고
클라우드 프론트같은경우도 등록자체가 어렵진않다. 오히려 이렇게쉬울수가? 수준이였고,
acm / AWS Certification Manager? Management? 여튼
인증관리센터 같은건데
여기서 DNS로 소유한 클라우드 프론트에대한 검증요청을 할수있는데 받게되면 인증서를 연결할수있게해준다.
지금 이부분에서 막혔는데 추후 진행되면 다시 정리해보겠다.
일단 서버에 ec2는 하나의 컴퓨터 찍어내는 틀이다.
그 틀을 디자인하는게 AMIs 인거고
찍어낸 작품이 인스턴스가되는거다.
자 지금까지는
하나의 인스턴스를 마치 빌려서 쓰듯이 사용했다.
하지만
트래픽이많아지면 그 서버는 굉장히 부하가걸리면서 견디다가 못해 터진다. (서버가 터진다는 표현)
수직 확장 ( 컴퓨터의 성능향상 ) 이 가능하긴하지만
한계점이 존재한다.
참고로 AWS에서 수직확장기능 스케일업? 기능을 제공한다.
다만 돈이 많이나가겠지.
여튼..
수평확장 즉 같은것을 갯수를 늘려서 처리한다.
트래픽이많아지면 더많은 인스턴스로 받아칠수있다.
그게 로드밸런서이다.
로드밸런서는
많아지는 트래픽에 따라서
인스턴스가 여러개라면 , 트래픽에따라서 분리해준다.
트래픽이몰리지 않도록.
하지만
이건 탄력적이지못한것이다.
사람이많이올줄알아서 인스턴스를 100개를 해놧는데
안몰려서 돈만 깨지거나
잠자는사이에 트래픽이몰려서 서버가 터지거나
누군가가 알려줘야지만 트래픽이몰려서 서버가 터진것을 깨닫거나등등.
엘라스틱 로드 밸런서가 존재한다
탄력적인 로드밸런서
이친구는 특정 조건등을 명시적으로 작성하여서
오류를 감지하고, 인스턴스의 상태들 그리고 건강상태 주기적으로 검사해서 다시 살아난것으로 인지할지 , 등등 조건을 걸어서
늘리고, 줄이고를 정해놓을수있다.
로드벨런서 관리자같은느낌이다.
아직 여기까지는 진행하지못했지만.
elb를 한다고해서 https가 될까? 라는생각도 들긴하지만. 일단 해보자
오늘 내일중으로 완성해보아야겠다.