Week1 BackEnd

ERD 고민사항

데이터(차)에 대한 정보 부족…
옵션이 너~~~무 많아 근데 우린 몰라

트림과 모델, 옵션 사이의 관계에 대한 정의가 명확하게 되어 있지 않아 설계하기 힘듦 ㅇㅈ

트림&모델에 옵션들이 관련돼 있는 것으로 생각해서 어려웠삼, 하지만 구동방식과 엔진 등은 모델에 종속적임을 깨달음

옵션 마다 필요한 필드들이 달라서 추상화하기 어려워 모델-트림과 관계 짓기가 어려움

결론 → 실제 현대 내차만들기 플로우를 따라가면서 데이터베이스를 설계하려니까 고려할 게 너무 많았다 프로젝트 기간이 짧으므로 적당히 확장성과 시간?을 트레이드 오프하기로 함

2023.08.02 마스터 피드백

피드백 내용

Jira에서 프로젝트 짠 내용도 볼 수 있게 공유 해둘 것
Jira 선택 이유?? + github issue
이번주: ERD 설계 + CI/CD 환경 설정 + 가능하다면 API(주말 잔업 예정ㅜㅜ)
프론트/IOS 와 협업: 어제까지는 서로 Task 정리한다고 큰 소통을 안했지만 어제 오늘 이슈였던 것이 백카사전 서비스의 경우 어떻게 요청할 것인지의 이슈에 대한 얘기 중
→ 호버링 시에 요청하면 늦는다? → 실험해봐야 한다, 사용자가 느끼기에 느리지 않을 것이다. → 확인해보고 결정해보세요. 캐시 같은 거 써서 빠르게 처리하는 방법도 있음
사이킷 런 사용 가능…..
할 수 있는 만큼만 → 모델이 엄청 복잡해지면 되긴 하는데 그렇게까지 해야하나…? 정규화를 하지 않고 만드는 방법도 있다. Json 필드를 만들어서 넣기……? 적당히 타협
협업 포인트: 어떻게 협업하고 있는지?
프론트 배포 → NginX & Docker → 한 컨테이너에 NginX에 리액트 빌드한 것을 쌓아서 / Volume을 쓰는 것도 괜찮다 → 볼륨 공유를 해서 링크만 가져와서 실행 가능하다. 리액트 빌드된 것을 EC2 서버 안에 넣어서 도커가 셰어해서 하는 방법도 고려해볼 것
CodeDeploy 써도 된다. → Github action & Jenkins

알고리즘

K-Nearest Neighbor

사이킷 런 라이브러리

배포(Docker관련)

$ ssh -i {YOUR_KEY_PAIR_FILE.pem} {USER_NAME}@{AWS_PUBLIC_DNS_}

ssh -i "umochar-ec2-private.pem" ubuntu@ec2-43-200-4-124.ap-northeast-2.compute.amazonaws.com

2023.08.02

docker-compose 의 ports

base-60 value로 인식하기 때문에 “”를 넣어서 string으로 넣어줘야 함

80:3000 → host의 80번 포트를 컨테이너의 3000번 포트로 포워딩 해준다는 뜻
nginx.conf

listen 필드의 포트를 들어서 컨테이너 의 포트로 포워딩 해줌

현재 80으로 설정 → 80으로 들어오는 요청을 3000으로 포워딩 해준다?
Dockerfile의 EXPOSE

컨테이너의 포트를 노출하겠다 → 외부에 노출하는 것이 아니라 host OS 안에서 노출하겠다는 것 같음. docker-compose 파일에서처럼 포워딩을 해줘야 의미가 있는 것?