농부처럼 코딩하기

실제로 가장 중요한 외부 인터넷에서 Private EC2 인스턴스에 있는 서버로 Request를 보내는 부분을 적용했다.ALB로 트래픽을 받고 각 EC2(유저서버, 채팅서버, 소켓서버)로 라우팅 처리했다. 유저서버와 채팅서버는 nest.js로 80번 포트를 사용소켓서버는 express.js로 3000번 포트를 사용했다. ALB는 HTTPS 443번 포트로 트래픽을 받아서 /chat과 /user로 각각 경로를 설정해 유저서버에 요청과 채팅서버의 요청을 받을 수 있게 했다.소켓서버와의 연결은  HTTPS 3000번 포트를 열고 3000번 포트로 라우팅을 했다. 유저서버와 채팅서버는 라우팅테이블로 연결된 RDS(mysql)을 사용하며,소켓서버는 DynamoDB(nosql)에 채팅메시지 ..

aws 초기 구성이 어느정도 마무리되어 가는 상황에서 프로젝트가 다 끝나고나면 aws 관련 서비스들을 종료할텐데 어떻게하지라는 생각 중 terraform을 도입하면 git을 통해 형상관리도 가능하고 나중에 어떤 구조로 만들었는지도 쉽게 파악가능할거 같았다. 그리고 현재도 팀원들이 관련 배경지식이 부족하다 보니 기존에 구현되어 있는 아키텍쳐 구조를 파악하기 어려워 했고, terraform을 도입하면 조금 쉽게 구조를 파악할 수 있지 않을까라는 생각이 들었다. terraform 다운받고 환경변수 설정 terraform에서 aws ec2 생성 Terraform download https://developer.hashicorp.com/terraform/install?product_intent=terraform ..

프론트단에서 api gateway -> NLB -> ALB -> EC2로의 라우팅 작업을 완료했다. 하지만 실제 연결을 확인해보기 위해서는 EC2에서 서버를 실행하고 요청을 보내는 작업을 해야했다. 그러기 위해서는 먼저 EC2에 연결하여 채팅서버를 실행시켜야 했다. 이를 위해 ec2에 연결하고 sudo apt update를 입력했는데 바로 문제가 발생했다. 101: network is unreached 해당 오류로 검색하면 여러가지 해결법이 나오는데 사실 Private Subnet에 ec2가 올라가 있기때문에 외부 인터넷으로 아웃바운드 트래픽을 연결해줘야 한다. 이를 위해서 위 그림과 같은 환경을 구축해야 했다. - Internet Gateway - NAT Gateway - Public Subnet 먼저..

지난주 백엔드, AWS, DB 관련 기술 선정 및 아키텍쳐 구상을 했다. nest로 local에 있는 mysql db에서 데이터를 처리하는 간단한 서버를 구현했고, 이를 EC2에 올려 보기로 했다. 이번 포스팅에서는 EC2에 올리기전에 api gateway에서 EC2가 있는 subnet의 target group까지 이를 연결하는 과정에 대한 이야기를 하겠다. 먼저 간단히 구조를 보면 다음과 같다. 로드밸런스는 리스너를 통해 트래픽을 받을 프로토콜과 포트번호를 정할 수 있고, 이를 라우팅할 대상그룹을 지정할 수 있다. Application Load Balancer는 path에 따라 이를 각각의 인스턴스로 라우팅할 수 있다. 대상 그룹 생성 먼저 EC2인스턴스를 대상으로 지정할 대상 그룹을 생성해야한다. 유..

코드잇 부트캠프의 마지막 프로젝트를 남겨두고, 마지막 파트 팀배정을 기다리며 미니 프로젝트에 회원관리 및 게시물관리 등의 간단한 백엔드 기능을 구현할 예정이였다. 그리고 팀배정이 완 먽료되었는데 과반수가 위워크에 자주 보이던 멤버였으며 다른 팀에 가도 그 팀을 리딩할 능력이 있는 구성원들이 모여있는 듯 했다. 조심스럽게 마지막 프로젝트를 백엔드 인원없이 진행해보는 게 어떻냐는 의견을 냈고 다들 긍정적으로 생각했다.(타 팀들은 백엔드 2명이 팀에 합류함) 백엔드 인원없이 진행하는 것은 확정이 됬고, 1주일동안 관련 기술에 대해서 학습해본 이후 개인적인 역할에 대한 이야기를 하기로 했다. 2명은 회원가입 및 로그인, 1명(나)은 채팅, 1명은 WebRTC기반의 음성/화상 채팅을 구현해보기로 했다. 1주일 간..

Next14.1.2 버전을 사용하였고 next팀에서 fetch 사용을 권고한다는 걸 보고 fetch를 사용하여 팀프로젝트를 시작했다. 프로젝트 초기 진행 중 rest api들의 authorization해더에 accessToken값을 필요로 하는 요청들이 많아 fetch함수에 axios의 interceptor와 비슷한 기능을 구현하기로 마음먹었다. 현재는 authorization 관련된 처리만 하면 되는 상황이였지만 fetch의 init속성(RequestInit)들에 대한 인스턴스를 미리 생성해놓고 사용할 수 있도록 확장성을 고려했다. class FunctionalFetch { private init?: RequestInit; public setOptions(newInit: RequestInit) { th..

version: next 14.1.0 React로 구현했던 페이지를 Next14로 migration하면서 뭔가 너무 느려졌다. 버튼을 클릭하면 버튼에 해당하는 카드 리스트들이 나오는 형식인데 버튼을 클릭하면 url의 query부분이 변경되면서 카드 리스트들이 업데이트 되는 방식이다. next의 동적라우팅을 사용하면서 버튼 클릭으로 url이 변경될때마다 페이지가 다시 로드되서 카드리스트를 업데이트 하는 동작이 이전에 React로만 페이지를 구현했을때보다 느려진거 같았다. 될지 안될지는 모르겠지만 하나씩 개선할 수 있는 부분을 찾아보자. 일단 코드상으로 버튼이 클릭됬을때 next/link의 Link를 사용해서 page를 이동시키고 있는데 혹시 이 부분이 페이지를 다시 로드하고 있을까 의문이 들었다. next..

next 14.1.0 cookies ( next/headers ) 서버에서 받아온 accessToken을 어딘가에 저장하고 특정페이지에서 백엔드로 어떤 요청을 accessToken을 header에 담아서 보내줘야 상황이였다. 이전 react 프로젝트의 경우 localStorage 등을 사용해서 처리했겠지만 next의 app router를 사용하는 현재 server component와 client component에서의 동작이 구분되어 server component에서 local storage를 사용하지 못하는 상황이라 다른 방법이 필요했다. next/headers의 cookies를 사용하기로 하고 cookies 사용 방법을 알아봤다. next 공식문서 내용 중 일부이다. 해당 내용을 토대로 이것저것 시도..

코인 종목들의 시세변화를 보여주는 확장 프로그램을 개발 중 이슈 업비트의 Open Api 호출 제한( 1초 10회 )으로 횟수를 초과하면 업비트 서버에서 에러로 처리const suspendFlag = requestQueue.length > 0; let requestCount = 0; while (requestQueue.length > 0 && requestCount { requestMarketInfo(marketList, marketInfo.market, marketInfo.korean_name, minute, marketIndex + index, true); }); // upbit rest api 1초당 10개 제한 marketIndex = marketIndex + 3 >..

input 태그의 focus() 실행 시 아무런 일도 일어나지 않음.. setTimeout 내부에서 focus를 실행시키니 제대로 동작한다. useEffect(() => { if (el.isSelect) { setTimeout(() => { if (inputRef.current === null) return; inputRef.current.focus(); }, 0); } }, [el.isSelect]) 이유를 찾아보니 DOM 요소가 연결되기 전에 DOM 요소에 접근하려하면 제대로 동작하지 않는다고 한다. 그런데 이미 mount되고 난 훨씬 뒤인데?? 의문이 들어 좀 더 자세히 찾아봤다. Github Copilot DOM에 연결하는 작업은 주로 컴포넌트가 처음 마운트(mount)될 때 발생합니다. 이는 R..