코멘트 요청 - 내용 상세

[Tacocat3]

1. 코드를 좀 더 깔끔하게 다듬고 싶은 마음이 가득한데 생각처럼 잘 되지 않아서 아쉬웠습니다. 이에 대해서 조그마한 팁이라도 얻고 싶습니다. 😢
2. 암호화를 위해서 pbkdf2방식으로 좀 더 편하게 구현할 수 있는 모듈인 pbkdf2-password를 사용했습니다. 혹시 좀 더 추천하시는 방식의 암호화가 있는지 궁금합니다.
3. 서버를 pm2방식으로 구동해놓으면 서버가 꺼져도 자동으로 다시 돌아가서 프론트 분들과 작업하기는 편한데 에러가 발생했을 때 어디서 발생했는지 알 수 없어서 에러를 체크해야 할 때는 수동으로 서버를 다시 켜는 방식을 사용했었는데, 혹시 이에 대해서 좀 더 좋은 방법이 있는지 궁금합니다.
4. _id(Object ID)를 사용할 때 오류가 발생하여 대신 mongoose-sequence package를 사용하여 id 값을 부여하는 방법을 사용하였습니다. 이렇게 사용하는 것에 대해 어떻게 생각하시는지 궁금합니다!
5. 4. 백엔드 ec2 업로드 + 프론트 local 로 했을 때는 cors()로 했을 경우에는 cors 인증 문제가 떠서 option으로 origin, credentials을 주어서 해결했습니다. 그런데 백, 프론트 둘다 배포하고 난 후부터는 갑자기 에러가 떠서 cors()로 변경했더니 해결이 되었습니다. 왜 이런 차이가 발생하는 건지 궁금합니다.

[golddong98]

1. Tacocat3님께서 코드를 쓰면서 깔끔하지 못하다는 느낌을 받으셔서 클린코드에 관한 질문을 하신 것 같습니다. 클린 코드에 대해서는 프로젝트마다 다르고 사람마다 생각이 다르기 때문에 제가 어떤 확실한 정답은 못 드릴 거 같습니다. (일단 저의 답변을 읽기전에 코드의 깔끔함을 못 느끼셨던 이유에 대해서는 여러가지가 있을 수 있으므로 Tacocat3님께서 스스로 이 프로젝트에 대한 클린코드를 찾지 못하더라도 어떤 코드가 그렇게 느끼게 했는지를 생각하시는게 우선이라고 생각합니다.) 그래도 제가 이 프로젝트 코드를 보고 클린코드에 관해 고민을 해본다면, 기능별로 분리하여 코드를 작성했다면 더 깔끔한 코드가 되지 않았을까 생각합니다. 지금은 routes디렉토리 안에 댓글관련 로직들은 전부 comment.js에 들어가서 라우팅, DB관련 로직, 변수할당,에러처리 등 많은 기능들이 한 파일안에 들어가서 Tacocat3님께서 코드가 깔끔하지 못하다는 느낌을 받게 한 것이 아닌가 추측해봅니다. 지금은 미니프로젝트이기 때문에 기능이 적어서 이 아키텍처로 작성하셔도 큰 문제없겠지만 프로젝트가 커짐에 따라 기능들이 많아지면서 지금과 같은 아키텍처로 코드를 짜면 너무 코드가 길어지고 복잡해져서 유지보수가 힘들어 질 것입니다.(제 경험입니다ㅎㅎ) https://softwareontheroad.com/ideal-nodejs-project-structure/ node 프로젝트 아키텍처를 정리한 사이트로 참고하셔서 이 프로젝트에 맞게 적용해보시면 큰 도움이 되실 거 같습니다. https://github.com/JooYoung2274/voice 그리고 제가 이전에 작성한 프로젝트로 위 사이트 아키텍처를 그대로 적용한 것은 아니고 저희 프로젝트에 맞게 적용한 프로젝트로 아키텍처 설계하실 때 실제 코드로써 참고하시면 좋을 거 같습니다.

2. 제가 로컬로그인으로 깊게 고민해보지 않아서 답변해드릴 수 없을 거 같습니다.

3. 일단 수동으로 서버를 켜서 에러를 체크한다는 것을 ssh로 서버에 접근하여 pm2 log를 쳐서 에러를 확인한다로 이해하겠습니다. 그리고 질문의 의도는 이 방식보다 더 좋은 방법을 찾고 싶다 로 이해하겠습니다. 사실 저도 이렇게 서버에 접근하기 때문에 이 방식에 대해 어떤 점이 문제라는 것인지 정확히 파악하지 못하겠어서 Tacocat3님께서 질문하신 의도를 추측해보자면 (1)서버에 들어가지 않고도 서버 에러를 확인하고 싶다. 가장 좋은 방식이지만 구현이 좀 힘들 것 같습니다. 에러가 났을 때만 pm2 log에 뜨는 node의 에러만 뽑아내서 email로 보내는 인프라를 만든다? 뭔가 있을 거 같기도 한데 저는 모르겠습니다.

(2)서버를 들어가는 작업이 귀찮아서 간소화하고 싶다. 제가 서버에 접근하는 여러가지 방식을 알아봤지만(물론 더 간소화된 방식이 있을 수 있습니다.) ssh -i ubuntu@인스턴스ip 로 서버에 접근하는 것이 가장 간소화된 방법이였습니다. https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/ec2-instance-connect-methods.html 다른 하나를 소개하자면 aws cli를 이용해서 서버에 60초간 지속되는 임시 keypair를 주고 들어가는 방식도 있습니다.

(3)서버를 아예 이용하지 않고 에러를 확인하고 싶다. 로컬테스트 환경을 구축하는 것입니다. 로컬환경에서 port만 다르게해서 프론트와 백엔드 서버를 열어서 에러를 미리 찾는 방식입니다. 실제 aws 환경에서만 테스트하는 방식이 아닌 로컬에서 테스트하는 방식도 한 번 구현해보면 큰 도움이 되실 것 입니다.

어쨋든 저도 프로젝트를 하면서 항상 서버 에러를 체크할 때는 ssh로 직접 들어가서 확인해왔습니다.

4. 저는 mongodb를 사용하면서 Object ID를 쓰지 못할 오류가 나온 적은 없어서 자세히는 모르겠지만 만약 Tacocat3께서 id값을 부여하는 방식으로 바꿔야 하는 정확한 이유를 아신다면 훌륭하다고 생각합니다ㅎㅎ

5. https://developer.mozilla.org/ko/docs/Web/HTTP/CORS#%EC%9D%B8%EC%A6%9D%EC%A0%95%EB%B3%B4%EB%A5%BC%ED%8F%AC%ED%95%A8%ED%95%9C%EC%9A%94%EC%B2%AD Tacocat3님께서 접근제어 시나리오 중 '인증정보를 포함한 요청'에 해당하는 시나리오를 겪으셨습니다. 자세한 설명은 위 mdn을 읽어보시고 해결방법은 간단합니다. credentials주면 와일드카드('*')대신 출처("siteexampleurl.com")를 명확히 써주시면 되겠습니다. const corsOptions = { origin: "https://github.com", credentials: true, }; app.use(cors(corsOptions));