내가 보려고 만듬

프로젝트가 마무리단계에 접어들고 있다. 배포 중 nginx로 고통받았던 기억이 있어서 다시 고생하지 않기 위해 기록해두려 한다... 엘리스에서 첫번째 프로젝트는 사실상 배포를 코치님들이 거의 맡아서 해주신 수준이라 답지를 보고 이러한 흐름으로 진행되는구나.. 하고 넘어가고, 두번째 프로젝트를 하면서 생겼던 이슈를 통해 이 내용에 대해 확실히 알게 되었다. 이유를 모르고 진행하다 보면 결국 언젠가 큰 화를 불러오는 것 같다...ㅋㅋ 문제 처음 express에 대해 배우면서 라우터, 미들웨어 등 여러 구조에 대해 알게 되었을 때 모르고 넘어갔던 부분이 몇 가지 있는데, 그 중에서 첫 진입단에서 세팅하는 부분이 기억에 난다. 아래는 내가 지금 진행중인 프로젝트의 진입단이다. const routeLoader =..

AWS에서 EC2를 통해 로컬에서 해당 환경을 접속할 때 터미널에서 어떻게 입력하면 되는지 친절하게 복사해서 넣을 수 있도록 알려준다. 간단하다. 터미널 열고 key페어 파일의 권한을 읽을 수만 있도록 변경, 이후 가장 아래 경로로 입력하면 된다. root자리에는 각 AMI 환경에 맞는 값을 입력해야 하는데, aws linux의 경우 ec2-user를 입력하는 것 같은데 나의 경우에는 ubuntu를 입력해야 했다. (ubuntu는 root로도 가능하다고 나와있고, 그래서 저렇게 알려주는 듯 한데, root로 입력하면 ubuntu로 입력하라는 오류가 나왔고, ubuntu로 하니 잘 진행되었다. ) 문제 : Permission denied (publickey) 저 값대로 root를 ubuntu로 터미널에 입..

처음에 각 컴포넌트별로 페이지를 구성해서 대충 기능만 구현을 하고 배포에 중점을 두려 계획했다. 처음 계획할 당시 서비스 자체(백킹트랙 생성)는 프론트에 대부분의 로직이 있다보니 얼른 구현해서 목적달성 방향으로 달리다가.. 욕심이 생기기 시작했다. 이것저것 기능들을 추가하다보니 본질과 멀어지면서...ㅋㅋ 일이 커졌다. 서버를 열어 실질적으로 운영하는 경험을 목표로 하지만, 기존에 당연시하게 있는 기능들을 다 넣어야 경험이 경험다워질 것 같아서 제대로 갖추고, 목표를 잡고 작업을 해야겠다고 생각을 했다. 그래서 프론트쪽도 구조도를 갖춰보았다. 싱글페이지로 컴포넌트를 차례로 내려서 보여주고, 각 기능들은 좌우에 기획한 것들을 담았다. 지금까지 서버쪽은 기본적인 auth와 만들어진 백킹트랙 코드 데이터, 포스..

발단 사이드바로 메뉴를 클릭하면 특정 위치로 옮기는 기능을 구현하던 중, 정확하게 컴포넌트의 클래스나 id를 맞추어도 구상한대로 이벤트가 작동하지 않는 이슈가 있었다. 해결 과정 1. 로직 확인 scrollToComponent() { const componentName = this.$route.name; if (componentName) { const componentId = this.getComponentName(componentName); const componentData = document.querySelector(`#${componentId}`); if (componentData) { const yOffset = componentData.getBoundingClientRect().top; win..

지금 구현하는 서비스에서 채팅 기능을 구현하고 있는데, 내 부족한 머리로 느끼기에는 꽤 프로세스가 장황해서 기록해두려 한다. 이번에 채팅을 구현하는 이유는 문의사항을 유저와 어드민이 주고받기 위해서이다. 필요한 기능을 정리하면 다음과 같다. - 1대1로 유저는 항상 어드민에게만 가능하도록 수신자 지정이 되어 있어야 함. - 서로를 제외한 나머지 다른 유저는 대화내용을 볼 수 없어야 함. - 대화 내용 저장 및 불러오기 다음 스크린샷은 어드민으로 로그인했을 때의 ui다. 앞서 필요한 기능에 대해 정리했듯 유저는 항상 어드민에게 가능하기 때문에 위처럼 수신자를 선택할 수는 없고, 조건을 어드민으로 로그인했을 때만 저렇게 보이도록 설정했다. 그리고 저 목록은 유저가 먼저 메세지를 보내게 되면 목록이 업데이트된..

생각해보니 시퀀스다이어그램을 만들어놓고 블로그에 포스팅을 안했다는걸 뒤늦게 알아서 기록겸 하나만 올려보려 한다. 솔직하게는 처음에는 이정도로 계획하지 않았는데, 레디스를 추가하게 되면서 조금 변경된 내용은 있지만, 그래도 큰 틀 안에서는 구상한 계획과 크게 벗어나지는 않은 것 같다. 사실 프론트쪽은 구상한 것과 달라진 부분이 꽤 많은데, 서버쪽은 그럴 일이 거의 없는 것 같다. 아무래도 내가 혼자 작업하는 것이다보니 프론트로 넘겨주는 데이터를 수정하는 내용들은 조금 있긴 하지만 대부분은 그대로 가게 되어 뿌듯하고, 왜 필요한지 피부로 와닿는 것 같다. 로그인 1. 웹에 접근, 프론트로 로그인요청, 백으로 로그인api 요청, 유효성 및 존재여부 검증 2. mysql db에서 선택된 값 반환, 검증, 실패시..

채팅기능의 목적은 사용자와 운영자간의 소통인데, 두 가지 방식이 떠올랐다. 메신저처럼 실시간으로 통신하여 바로바로 메세지를 주고받을 수 있는 방식이 있겠고, 메일을 주고받듯 페이지가 리로드되면 받을 수 있는 방식이 있을 것 같다. 이 두 차이는 페이지를 새로고침을 해야만 새 메세지를 확인할 수 있을 것인지, 혹은 새로고침을 하지 않아도 새 메세지를 확인할 수 있도록 할 것인지에 대한 차이라고 보인다. 아직 사용해보지는 않았으나 socket.io를 이용하여 대화방을 만든다던지, 특정 사용자에게 귓속말을 한다던지 하는 여러 기능들이 있다고 하는데, 당장 내가 적용할 프로젝트에서는 '실시간'이라는 키워드가 메리트로 다가오지는 않았다. 소켓io에 대해 조금 공부해보니, 별도의 서버를 추가로 운영하는 것이 서비스..

제대로 서비스를 구현하고, 배포하여 실 사용자를 받아보는 것까지 목표로 삼고, 서버쪽에 집중해서 공부하다보니 프론트쪽을 어떻게 구현하고 관리할지 고민하던 중, 당장 공부하면서 접근하기에 비교적 수월한 vue를 선택했다. 아무것도 모르는 상태에서 일주일동안 공부하며 기본 구조, 상태관리 등에 대해 익혔고, 나름 처음 구성하고자 한 바와 거의 다르지 않은 상태로 진행되었다. 그래도 처음 포스팅했을 때 코드 만드는 것에 비하면 꽤 많이 진행된 것 같다. 처음 기획한 api명세 대로 왼쪽에서 key, extends, tensions를 조합하여 chordPattern을 만들어 등록하면 오른쪽 Preview에 값이 3차원 배열로 담기고, 4개가 채워지면 자동으로 넘어가는 부분까지는 구현되었다. 헤더, 사이드바를 별..

발단 현재 팝업창을 어드민에서 게시글과 이미지를 서버로 전송하는 형식으로 구현하고 있는데, 테스트 도중 jwt 미들웨어에서 유효하지 않는 토큰으로 인식하는 문제가 생겼다. 건드린게 없는데..갑자기? 오류가 난 곳을 확인해보면 헤더의 토큰을 확인하여 accessToken을 파싱하는 로직에서 req 자체를 못받아오는건 아닌데, req.headers를 확인해보니 쿠키부분만 빠져있었다. 그래서 쿠키 자체를 읽어오지 못해 undefined로 확인되며 오류를 반환하고 있었다. 서버로직을 건드린 것도 아니고,, 아직 게시글 구현하면서 전송과정을 테스트하고 있는 것이라 통신하는데 있어서 문제될게 없기도 하고 문제가 될 것이였으면 진작 로그인하는 과정이나 별도의 권한을 부여받는 로직을 건드리고 있는 것이라면 모르겠는데 ..

계기 이번에 포스팅을 하게 된 계기는 현재 구현하고 있는 프로젝트의 auth 부분에서 다시금 깨닫게 된 것이 있어서인데, 리마인드하는 겸 설명을 붙여보고자 한다. jwt로 인증을 받게 되면 req.user 로 user에 대한 정보를 받을 수 있다. 그런데 앞서 말했듯 jwt로 인증을 받아야만 req.user를 얻게 되기 때문에 req.user는 확정적으로 값이 있는 변수가 아니다. 인증을 받았을 때만 req.user에 값이 들어오게 된다. 그래서 타입을 세팅하고 선언할 때 req.user에 대해서는 ?를 붙여서 있을 수도 있고~ 없을 수도 있다고 표현했다. ? 의 의미 위 스샷과 같이 req.user에 username을 얻고 싶을 때 req.user.username으로 받게 되면 자연스럽게 타입스크립트는..