codeIt! DEMO day! 개발 마지막 기록 및 후기
codeIt! DEMO day! 개발 마지막 기록 및 후기
1. 데이터베이스 구성
2. 배포사이트
3. 왜 데이터베이스를 2개로 나누었는가
4. 겪은 오류
5. 일정 관리
1. 데이터베이스 구성
- Node.js와 Express 라이브러리를 사용하여 서버를 구현
- MongoDB Atlas를 통해 댓글과 게시글 같은 문자열 데이터를 저장
- AWS S3를 사용해 이미지 업로드 기능을 구현
node.js와 express 라이브러리를 사용하였고, mongoDB Atlas로 댓글, 게시글과 같은 문자열 형식의 데이터를 저장하였고, AWS S3를 사용해 이미지 업로드 기능을 구현하였습니다. IAM 자격 증명을 통해 안전하 AWS S3에 접근하고 EC2로 Express.js API 서버를 구현했습니다. 실제로 이미지는 AWS S3 버킷에 저장되고 EC2 서버는 이미지를 받아서 S3에 업로드하는 역할을 합니다.
결론적으로 2개의 데이터베이를 활용하여 전체 서버를 구성하였습니다.
2. 배포사이트
render로 백엔드를 배포하고, vercel로 프론트엔드를 배포하였습니다.
중간에 프론트엔드 코드가 react에서 Next js로 바뀌었는데 이때, vercel이 더 유리하다는 이야기를 듣고 vercel로 프론트엔드를 배포했습니다.
Cloud Application Hosting for Developers | Render
Render is a unified cloud to build and run all your apps and websites with free SSL, global CDN, private networks and automatic deploys from Git.
dashboard.render.com
Vercel: Build and deploy the best web experiences with the Frontend Cloud – Vercel
Vercel's Frontend Cloud gives developers the frameworks, workflows, and infrastructure to build a faster, more personalized web.
vercel.com
3. 왜 데이터베이스를 2개로 나누었는가
render를 사용해 데이터를 업로드하는 경우, 이미지가 서버의 임시 저장소에 저장되어서 서버가 초기화될때마다 저장된 이미지가 날아가는 오류가 있었습니다. 이를 해결하기 위해 AWS S3버킷을 사용하였 습니 다.
4. 겪은 오류
Next js로 된 프론트엔드 코드에서 id를 Number로 한정하여 받게 설정되어 있었는데 백엔드에서 MongoDB를 사용하여 id값이 무조건 MongoDB에서 제공하는 ObjectId값으로 정해지게 되어 있어 프론트와 백엔드 간에 데이터 교환이 제대로 이루어지지 않았습니다. 이 오류는 유효성 오류라고 떴기 때문에 찾기까지 매우 오래걸렸습니다.
백엔드에서는 MongoDB 말고 postGres나 Mysql을 사용하여 해결하거나, objectId를 숫자로 변환하여 강제로 사용하는 방식을 사용하는 방법을 생각해봤지만 발표까지 시간이 하루도 채 남지 않았었기 때문에 프론트 엔드 코드를 바꾸는 방법을 선택했습니다.
5. 일정 관리
프로젝트가 크지 않았기 때문에 저희는 노션, 카톡으로 일정 관리와 개발을 진행했습니다.
그리고 정해진 기한까지 다른 파트가 완료가 되면(예를 들어 프론트엔드) 다음 파트로 넘어가는 waterfall방식으로 일정 관리를 했는데 이전 개발이 끝나기 전까지 다음 작업을 할 수 없다는 단점이 있었습니다.
1등 팀과 일정 관리, 개발 관리 과정을 비교해보니 빈번히 회의를 하며 프론트엔드 파트와 소통하였고, 기능을 4가지로 나누어 하나의 기능이 완성되면 다음 기능을 완성하는 애자일 방식으로 개발을 하였다는 특징이 있었습니다.
다음에 개발을 하게 된다면 팀원 간에 더욱 더 소통하고, 기능 위주로 일정 관리를 해봐야겠습니다.
기능적으로는 postgres를 활용해보거나 AWS를 사용하는 것을 더 연습해보고 싶습니다.