JIN_CODER

토요일인 오늘은 시니어 개발자 매니저님께 1주 차에 대한 멘토링을 받았다. 아마 매주 토요일 오전에는 해당 주차의 진행상황과 멘토링, 질문사항들을 물어보면서 해결에 대한 키워드나 조언들, 숙제들을 받아서 다음 진행상황들을 해결하기 위해 많은 도움이 될 것 같다. 오늘은 첫날이라 간단하게 프로젝트를 설명드리고, 현재 진행상황은 기본적인 api 구현과 소셜 로그인(카카오)까지 구현되었고, 아마 다음 주는 실시간 채팅에 몰두할 것이라고 말씀드렸다. 진행속도는 매우 괜찮은 것 같고, 스코프도 너무 크지도, 작지도 않은 모습인 것 같다는 피드백을 받았다. 그리고 가장 중요한 이번 주를 진행하면서 생긴 질문사항들을 여쭤보았다. 일단 s3에 파일 업로드를 프론트에서 할지, 백앤드에서 할지 한번 더 물어보았다. 주로 ..

네트워크의 계층들 중 전송 계층에서 사용 하는 프로토콜 TCP, UDP에 대해 알아보자 전송 계층은 송신자와 수신자를 연결하는 통신 서비스를 제공하며, IP에 의해 전달되는 패킷의 오류를 검사하고, 재전송 요구 등의 제어를 담당한다. 즉, 데이터 전달 담당 그 데이터를 보내기 위해 사용 하는 프로토콜 : TCP, UDP *패킷이란, 인터넷 내에서 데이터를 보내기 위한 경로배정(라우팅)을 효율적으로 하기 위해서 데이터를 여러개의 조각들로 나누어 전송하는데 이때 데이터의 조각을 패킷이라고 함. TCP(Transmission Control Protocol) 전송을 제어하는 프로토콜(규약) 인터넷상에서 데이터를 메세지의 형태로 보내기 위해 IP와 함께 사용하는 프로토콜 일반적으로 TCP와 IP는 함께 사용, I..

오늘은 로깅 작업을 나에게 맞도록 좀 수정하고, 마무리해서 프로젝트에 적용시켰다. 어제 만질 때는 생각나지 않던 부분들이 아침에 보니까 새롭게 보여서 적용하니 문제도 좀 해결되는 게 있었고, 참고한 자료가 커스텀을 많이 한 코드여서 오류 나는 게 많았다. 좀 더 베이식 한 코드를 찾아서 정말 필요한 부분만 조금 변경해서 내가 알 수 있도록 만들었더니 잘 동작했다. 배포 환경에서는 필요한 에러만 로깅하고, 개발 땐 콘솔 창에 나오게 한다던지 사용에 적응이 돼서 다행이었다. 나 혼자 배포한 서버에서도 잘 동작했고, 아마 팀 프로젝트에 배포에서 적용을 시켜서 보지는 않았지만, 내일 한번 확인해볼 생각이다. 추후에 winston과 morgan도 정리해서 올려야지 그리고 저녁부터는 실시간 통신에 대해서 공부를 좀..

지금까지 프로젝트를 진행하면서 에러 처리를 항상 try catch 문으로 정의하여 사용했었다. try문안에서 에러가 발생하면 서버의 오류이기 때문에 500 status와 함께 메시지를 보냈고, if문을 통해서 클라이언트에게 유요한 값을 받지 못하거나, 사용자가 찾는 값이 db에 없는 경우에는 잘못된 요청이기 때문에 400 status와 오류 메시지를 보냈다. 하지만 이렇게 진행할 경우 예외처리가 많아질수록 잘못된 응답이라고 전달해주어야 하는 게 많아져 코드가 지저분해지고, 길어졌다. 예전에 에러 미들웨어를 만들어서 try문에서 에러가 발생하거나 예외처리에 걸러지는 경우 catch문으로 에러를 보내서 가장 마지막에 에러 핸들러를 통해서 잘못된 응답을 보내주면 좋다고 들어서 이번 기회에 에러 핸들러를 만들어..

오늘은 채팅방의 CRUD 코드를 받아서 수정하는 일을 주로 하였다. 계속 게시물 CRUD를 만지는 것 같은데... 똑같은 작업만 하니까 좀 그럴 수도 있지만, 팀원이 코드 수정이 어렵다고 해서 도와주는 거다. 이것만 하고 싶어서 하는 건 아니다 ㅠ 나도 새로운 것들을 해보고 싶다 ㅠ 일단 실시간 채팅을 하기 전 채팅방 게시물들을 만들어야 그 안에 들어가서 채팅을 할 수 있기 때문에 중요한 작업 중 하나다. 채팅 기능과 채팅방을 맡은 팀원이 다른 곳의 코드를 기반으로 CRUD를 만들려고 했는데 우리와 사용하는 방식이나 코드들이 달라서 우리껄로 바꾸기 힘들어해서 내가 대신 코드를 우리 스타일로 바꿔서 동작하게 만들었다. 다행히 중간중간 주석이 있고, 게시판 CRUD는 많이 해봐서 그런지 너무 어렵진 않았다...

실전 프로젝트를 진행함에 앞서 이제 6주 동안 다른 사람들과 코드를 작성해서 공유를 많이 할 텐데 각자의 코드 작성 스타일이 다르면 나중에 깃 허브에서 충돌이 많이 날 것이다. 이를 대비해서 최대한 남의 코드는 건들지 않겠지만 불가피하게 남의 코드나 파일을 수정할 경우 최대한 같은 스타일을 사용한다면 충돌이 날 확률도 낮아질 것이다. 또한 나중에 보았을 때도 모든 코드가 같은 설정으로 통일되어있다면 보다 좋은 가독성을 주고 안정감을 주기 때문에 협업을 하기 전엔 코드 컨벤션을 통해 팀끼리 코드 스타일 설정을 맞추는 것이 좋은 협업의 지름길이라고 생각한다. 사실 이 글을 쓰기 전 컨벤션이 정확히 무엇인지 잘 모르고 필자도 prettier만 사용해서 스타일만 정해서 협업에 들어갔다. 이 글을 쓰면서 생각보다..

실전 프로젝트가 시작하고 이제 약 1주일이 되어간다. 우리 조는 생각보다 수월하게 진행되는 듯했지만, 바로 큰 벽을 만나버렸다.. 바로 소셜 로그인 내가 소셜 로그인을 담당하지도, 직접 구현해보지 않아서 모르는 것이 많아서 어디 부분에서 문제가 생겨서 정상 작동을 안 하는지는 모르겠지만, 혼자 여러 자료를 보고 코드를 보면서 조금씩 이해하곤 있다. 문제는 정상적으로 사용자가 로그인해서 카카오에 토큰도 잘 받아와서 우리 db에 회원가입도 되고, 로그인도 해서 우리가 만든 토큰까지 전달해주고 있다. 문제는 프론트에서 이 응답에 접근을 할 수가 없다. 항상 똑같은 방법으로 응답을 주고 있는데 접근을 할 수 없다라... 정말 이해가 되지 않지만 분명 누군가 잘못하고 있는 거겠지.. 하면서 하루 종일 코드를 보았..

api통신을 하다 보면 http의 상태 코드를 어떻게 해서 응답해야 할지 고민이 많이 든다. 이번 기회에 http상태 코드를 공부해보고 자주 사용하는 코드를 정리해서 잘 사용하려고 정리해본다. status code 사용자가 웹 서버에 요청을 보냈을 때, 응답으로 보내주는 숫자 코드 각 숫자는 미리 약속된 특정한 의미를 가지고 있다. 클라이언트는 응답으로 온 코드의 숫자를 통해 요청이 성공했는지, 실패했다면 무슨 이유인지 대략적으로 알 수 있다. 기본적인 status code 1xx(정보) : 요청을 받았으며 프로세스를 계속 진행 2xx(성공) : 요청을 성공적으로 받았으며 인식했고 수용 3xx(리다이렉션) : 요청 완료를 위해 추가 작업 조치가 필요 4xx(클라이언트 오류) : 요청의 문법이 잘못되었거나..

실전 프로젝트는 나름 순조롭게..? 진행되고 있는 것 같다. 일단은 기획도 나쁘지 않다는 피드백도 받았고, 하나하나 기본적인 기능들은 완성되가고 있다. 문제는 소셜과 실시간 채팅, PWA가 문제일 테니까 기본 기능을 빨리 만들어야 여유시간이 많을 테니까 나쁘지 않은 것 같다. 오늘은 사실 나한텐 엄청 중요한 날이다. 엄마 기일이라 납골당을 갈 수 있을까 걱정했는데 앞서 말한 것처럼 나름 순조롭게 진행되고 있어서 양해를 구하고 낮에 갔다 왔다. 오랜만에 가서 속 시원하게 이야기도 하고, 마음도 잡고 힘든 마음을 좀 내려놓을 수 있어 너무 다행이었다. 다음엔 항해가 끝나고 내가 만든 사이트 보여주기로 다짐했다. 더 좋으면 취업소식까지 전할 수 있으면 좋겠다 오후엔 다시 와서 s3를 이용한 파일 업로드를 좀 ..

ERR_HTTP_HEADERS_SENT 오류는 서버가 클라이언트에게 둘 이상의 응답을 보내려고 할 때 발생하는 오류 [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client 처음에 이런 에러를 보았을 땐 매우 당황했다. 처음 보는 에러였고, 정확히 어디서 문제가 있는지 알 수가 없어 에러를 천천히 보고 구글링을 했다. 클라의 요청에 내(서버)가 둘 이상의 응답을 보내면 나타나는 오류라고 한다. 음... 난 분명히 응답을 하나만 했을 텐데.. 왜냐하면 res.status().json({})으로 응답을 보내줄 때 항상 return문을 붙여주니까 2개 이상이 가지 않을 것이라 생각했다. 문제는 내 미들웨어에 있었다. 로그인 유무..