7월까지 400개의 서류 지원 총 5개의 서류 합격 / 면접 3회 탈락을 겪고 2번째 부트캠프를 겪은 나는 이번에도 300개가 넘는 이력서를 지원했지만, 그리고 계속해서 프로젝트를 디벨롭하였지만, 비전공자로서 취업의 벽은 너무 높았다.
그래도 이번면접까지 겪으며 깨달은 느낌은,
좀 알아주는 기업들은 프론트엔드만 시키기엔 내 실력이 부족하다 느껴서 붙여주질 않고, 소규모 스타트업은 백쪽 경험이 아예없는 나를 배제하는 느낌이 드니,
스펙, 경력을 쌓으려면 일단 백 개발자와의 협업 그리고 실제 백경험까지 익혀야 한다 생각해서 LUST를 배우는 친구와 협업으로 기존 진행하던 ShareLife를 이어서 진행하기로 하였다.
1차 가볍게 진행한 회의는
-프론트 할일-
1. 요구사항 명세서 만들기
(기능 세부 분리)
2. 어떤 데이터 필요한지
3. ui 설계
-추가 필요한 회의-
1. 개발환경 - 레포지토리 운영 - 모노레포 or front back - 추후 node적용한다면 머가 좋을지 공부
(devops 직군)
2. 개발/테스트 환경 배포
ex- 127.0.0.1:3000/post/
저 아이피 어떻게 할거냐
aws로 컴퓨터 대여 공인 ip 받기(무료)
공인 ip / 사설 ip
aws 컴퓨터 하나 대여하기
이후 CI/CD해야함
컨테이너 배포(docker image)
이후 컴퓨터는 독커가 이미지 실행
3. 스웨거
restapi 문서 확인 및 테스트
-실제 흐름-
☆1. rest api 목록 초안 민규 만들어서 쥐한테 공유
2. 목록 보고 실 restapi 응답 백에서 구현
(swagger볼수잇게 백에서 제공)
3. 스웨거페이지보면서 요청한대로 잘 되는지 확인
☆4. DB 설계
(vs code erd editor 다운)
db.erd.json 파일 생성
이후 사용한 수파베이스 참고해서 설계
기본키, 타입 등등
relation ship 세부내용
primary key
깃헙 올가니재이션 - 초대
new래포만들기이 정도였고 오늘까지 api명세서 / github organization에 초대하기 / db 설계를 진행해서 친구에게 넘겨주고자 한다.
github organization 만들기
일단 이번에 처음 알게된 용어인데
여러 명이 함께 협업할 수 있는 팀 중심의 깃헙 관리 단위라고 한다.
개인 계정이 아닌, 프로젝트나 회사 같은 그룹 단위로 리포지토리를 관리하고 권한을 설정하는데 유용하다고 한다
근데 그동안 협업했었을 땐 하나의 레포지토리에 여러 팀원을 초대해서 pr해서 프로젝트를 진행했었는데 무슨 차이일까?
- 권한 관리 유연성
- 개인 레포지토리:초대한 멤버는 초대한 레포지토리에서만 작업 가능
- organization: 여러 레포지토리 권한을 그룹별로 설정 가능(와 이게 찐또배기구나)
- 소유권
- 개인 레포지토리 : 소유자가 개인 계정으로 관리, 개인 계정 삭제되면 레포지토리 관리 어려움
- organization: 조직에 귀속되며 여러 소유자가 관리 가능
- 프로젝트 규모
- 개인 레포지토리:소규모 프로젝트나 단기 협업에 적합
- organization: 대규모 팀 협업, 회사 프로젝트 관리에 적합
- 추가 기능
- organization은 팀별 대시보드, 자동화된 권한 관리, 깃헙 액션 통합 같은 고급 기능 제공
그럼 이제 만들어보자!
일단 설정에서 new organization!
free 클릭
그래서 이름 설정하고 친구 초대해서 organization을 만들어주었다.
그러다보니 프론트 개발자와만 작업하던 내입장에선 개인레포에 친구 권한넣어서 팀레포로 만드는거랑 올가니제이션에 레포를 추가해서 하는거랑 무슨차이인가 싶었는데,
내가 하던 방식은 모노레포의 소규모 프로젝트에 어울리고, 팀 단위 레포는 저렇게 올가니제이션에 여러 레포를 하나의 프로젝트로 합칠 수도 있다고 하니 이번 기회에 멀티 레포 개념을 알게된것 같다 굿굿
그래서 어쨋든 기존에 pr을 100개를 넘게했었는데 아쉬우니 개인레포를 organization으로 이동시키려했는데,
개인레포 세팅에서 transfer ownership에서 옮겨주면 된다고 한다
멀티레포도 그냥 어렵게 생각안하고 친구 레포도 클론해와서 거기에 원하는걸 주면된다.
이제 그 원하는2가지 중 하나를 먼저 해보자!
DB 설계
수파베이스에서 테이블 컬럼을 직접 세팅한 경험을 바탕으로 직접 erd editor를 깔아서 친구 레포에 넣어줘야한다.
일단 erd 코드 짜는 확장 프로그램을 vs code에 설치해주고~
db.erd.json를 루트 파일에 설치해서 수파베이스에 넣은 내용을 직접 다시 한번 db를 짜보자!
기존 스키마를 바탕으로 db를 짰더니
테이블 컬럼 내용은 다 채웠지만 외래 키 연동하는 테이블간 연결이 내가 원하는대로 되지 않아 이 부분은 공부가 필요하였다.
우측 마우스버튼 - relationship을 이용해 연결했는데 원하는 컬럼과 연결이 되지 않았고, 무조건 primary key로 설정한 컬럼과만 연결이 되었다.
모든 테이블에서 primary key 세팅한 컬럼은 id였기 때문에, 이걸 건드리는 건 아닌것같고 일단 relationship에 있는 Zero One / Zero Only / one only / one N을 알아보자
Zero One
한 항목이 다른 항목과 관계를 가질 수도 있고, 가지지 않을 수도 있다..?
ex) users / posts 테이블관계에서 사용자가 프로필을 가지지 않을 수도 있으면, 이 관계는 Zero One
즉 시용자는 프로필을 가질 수도 있고, 프로필을 가지지 않을 수도 있음
Zero Only
한 테이블의 항목은 다른 테이블의 항목과 관계를 가질 수 없거나, 관계가 없을 수도 있다
ex) users 테이블의 deleted_at 컬럼을 설정했다면 NULL일 수도 있지만, 삭제된 사용자는 없을 수 있다는 경우
즉 삭제된 항목은 존재하지 않을 수도 있다는 것
One Only
한 테이블의 항목은 반드시 다른 테이블의 항목과 관계를 하나만 가져야함
ex) users의 user_id와 posts의 user_id관계는 One Only
즉, 하나의 사용자는 반드시 하나의 프로필만 가질 수 있다는 관계
One N
한 테이블의 항목은 다른 테이블의 항목과 여러 개의 관계를 가질 수 있다
ex) user테이블 posts 테이블간의 관계는 One N
즉, 하나의 사용자는 여러 개의 게시물을 작성할 수 있다는 관계
일단 foreign key 설정법이나 원하는 컬럼끼리 연결하는건 친구에게 자문을 물어보고 다시 할 예정
API 명세서 만들기
프론트엔드 백엔드가 협업하기 위한 중요한 작업
필요한 데이터와 동작을 정리하고 명확히 전달하는게 핵심
이런 저런 툴을 찾아보다 첫 추천이 swagger였는데
그냥 토악질나오게 먼소린지 모르겠어서 백 개발자 친구 추천인
postman을 써보기로 하였다.
api개발 및 테스트가 가능한 장점이 있고 문서화할수도 있다고 하는데 아주 설레구만 ㅎㅎ
실제로 GET의 url은 뭘 입력해야하나 서버부터 생성해야하나 했는데, dev든 배포환경이든 vscode에서 pnpm run dev 같이 명령어로 서버 베포하면 저기서도 인식이 된다고 한다 참 신기하네 ㅎㅎ
일단 pnpm run dev해서 GET url에
http://localhost:3000/api/users?userId=<user_Id>이런식으로 입력했더니
local api요청 테스트할 시 desktop agent가 필요하다고하여서 다운로드를 먼저 진행하였다.
그래서
하나씩 다 넣어줬다 ㅎㅎ
대신에 POST 같은 경우 입력값이 존재하므로 Headers에 Content-Type / application/json을 추가해줘서 json형식의 바디에 예시를 넣어놨다.
초안으로는 결국 DB설계 / api명세서는 다 완성!!
