[Week13] 0413

안나경·2024년 4월 13일

크프정 일상

목록 보기
92/109

어제의 이야기

어제 공부한 것

...
오전...
병원 다녀온뒤 Nest를
챕터 3, 그리고 4를 죄금만 앞두고
낮까지 다 읽었었는데

다루는게 꽤 있다보니
어떻게 금토일 읽는다고 해도
구현 기간이 월화....

그것도 그렇고
내가 Nest를 배운다고 해도
이걸 가르칠 정도로 할 수 있는게 아니면
(물론 도움이야 되겠지만)
지금 가장 필요한게 뭘 지 생각해봤음.

  • express CRUD는 가능해야...
  • 대부분 mongoDB를 써봤을테니 그거로...
  • react를 프레임으로 쓸건 확실하니, 좀 파악해놔야...

그리고 당장 내일 팀원이 생긴다는 가정으로
뭘 제일 합의해봐야할지도 생각해봤는데

생각해보면 초반은 기획이란 말이지
아마

  • 모여서 브레인 스토밍, 아이디어 추리기
  • 아이디어에 적합한 아키텍쳐와 기술 찾아보기
  • 조금 해보고 얼마나 실현가능성이 있는지 확인 후 다시 회의
  • 확정된 것을 발표할 수 있을 정도로 메인기능 시연 준비

정도 인데... 이 단계에서는 모두 함께 할테니 크게 상관이 없고
다들 백과 프런트를 면밀히 나눌수는 없다고는 해도
주력 분야는 있겠지...

그치만 아직 백과 프런트의 컨벤션을 정할 정도로 뭔갈 알질 못해서
그걸 어느 정도 세울 정도로 찾아보는게 목표고

git을 쓸테니 branch를

  • 최종인 main을 세운다
  • 기능에 따라 버전 1을 세운다,
    그리고 버전1관련은 모두 거기에 파생된 branch로 지으며
    이 버전1 branch는 자주 merge해본다.
    (PR올려서 누구든 두명이상 확인하면 merge 한다든가.)
  • 퇴근하기전에 자신 거 꼭 commit하고 퇴근.
    (그리고 commit 양식도 어느정도 정하는게 좋을듯함.)

정도로 생각했고

그러기 위해서 내가 준비해야하는건
당근 스웨거 같은거 써보기도 해보고
express, react , 분명 뭘 하든 쓰게될 이 2개를 먼저 파악해야하고

그걸 하고 나면 뭐 추가적으로
모듈화를 높이기 위해 Nest를 공부한다든가 할 것.

아 코딩 스타일은
구글 코딩 스타일 가이드 참고해서
몇개 추릴까

Docker를 쓰자고 해야겠다
Docker는 내가 쓸줄 아니까 그것도 준비해서

아무튼...

컨트롤러

  • @Controller로 클래스 컨트롤러화, @Get으로 루트 경로 정의.
  • 들어오는 객체의 형태도 데커레이터로 처리.
  • 응답은 자동으로 json 변환됨. 상태코드는 데커레이터 호출로.
  • 헤더, 리다이렉트, 매개변수도 데커레이터로.
  • 데이터 전송 객체를 DTO로 일종의 interface처럼 사용.
    (스키마와 유사.)

프로바이더

  • @Injectable로 다른 곳에서도 쓸수 있게 싱글턴 인스턴스로 생성.
  • 프로바이더는 Module에 등록해두면 쓸수 있음.
    객체 기준 생성이 아니라 속성만 가져오는 것도 가능함.

블로그에도 쓰긴 했지만
실습하면서 진행했음.

따라하는데도 틀리는 바보 이즈 히얼
물론 잘 해결됐습니다

이 때 자체는 별 일 없었고

있었던 문제

  • 예제에는 하드코딩으로 transporter를 생성하고 있기때문에 인수만 받지 그 서버에서 설정한 값을 쓰고 있었기때문에 메일이 보내지고 있지 않았던 오류.

였고

이후에 저녁에는 express로 CRUD 먼저 해야겠다.. 싶어서
빈 폴더 하나 파서 책에 몽고디비와 연결하는 예시 보면서 진행.
관건은 기존 코드를 안 쓰고 post, 라고 title과 content를
주고 받고 지우고 업데이트하는걸 하고 싶었는데.

다시보니까 주로 쓰는 모듈이 무슨 역할을 했는지 다 까먹은 거임.

그래서 일일이 찾아봤자... morgan, static, body-parser...
그리고 locals는 아직 덜찾아봤는데 process 객체의 env도.
(이제 보니 전역 객체라 env를 쓰려면 파일 자체를 추가해줘야하던데?)

프런트 부분을 챗 gpt에게 부탁했는데 잘 안 됐음.
어차피 react로 할건데 시간 다 가겠다 싶어서 postman을 써보기로.
근데 그것도 안 써봤어서 익히는데 좀 걸림.

프런트 관련.

  • 프런트에서 form으로 입력을 받으면 기본으로 GET 형태로 가기때문에 html 내에서 태그 안에 method="POST"를 보내야함.

Mongoose 관련.

  • schema 안에서 mongoose 연결하기.
    (아직도 connection 메서드는 정확히 모름.)
  • schema 에서 mongoose의 schema를 꺼내와 Post라는 이름으로 mongoose model에 저장하면 그냥 Post라는 객체를 수정하는 것만으로 DB 수정이 됨.

route, 응답과 요청 관련.

  • .route('/')는 하나의 경로에서 여러 요청을 처리하고자 할때 붙여줌.
  • .render('post')등은 html을 확장자 없이 붙이면서 render 할때.
  • DB 관련 작업은 꼭 async - await로 받아와야한다. 흔한 500에러.
  • status와 json, 아무튼 response를 제대로 보내지 않으면
    응답이 다 안 온줄 알고 무한 로딩 걸림.
  • render 자체에서 템플릿엔진이 매개변수를 받을수 있도록
    .render('post_detail', { postId:postId}) 등으로 건네주기 가능.
    (그쪽에서 그냥 그 변수 쓰면 내가 보낸걸 받게 됨.)

CRUD 관련.

  • .find({}, {})하고 두개를 입력할수 있는데 앞은 내가 찾으려는 조건이고, 뒤는 내가 갖고 싶은 filed를 지정할수 있음. _id는 디폴트가 1, 즉 표시이므로 0으로 바꿔주자.(안쓴다면.)
  • 리다이렉션은 그냥 태그 자체를 생성할때 href="/posts/:id" 등으로 해서 라우트가 해당 주소를 받게 설정하는듯. (근데 분명 다른 방법도 있긴 할텐데.)
  • updateOne과 Many의 기준은 내가 업데이트하려는 필드의 갯수가 아니라 객체의 수. 역시 앞에는 내가 찾으려는 조건, 뒤에는 업데이트하려는 내용.
    나는 put으로 param에 값을 넣었고, 받을때는 req.query.id 형태로 받음.
    req.param.id로 받을때는 어떨 때지?

postman 관련.

  • postman에서 POST 요청 보낼땐 헤더에 Content-Type : application/json을 보내야했던 오류.
  • Param으로 보낼 경우 ObjectID는 문자열 안 값만 보내면 됨.
  • body로 json 예시 보낼때 키, 값 모두 ""로 싸줘야하고 콤마, 세미콜론으로 끝나면 안됨.

소감

참 즉석에서 요청 짜면서 느낀게
모듈화로 시작해야 깔끔한건 알지만
처음부터 고려하기 쉽지 않긴 하다.

그래도 Nest 정말 유용하지만 잘 하고 있는지 모르겠다 싶었는데
express 하면서 Nest의 필요성도 나름 느끼고

Postman으로 백 부분만 빠르게 확인할 수 있게 되면서
자신감도 좀 얻긴 한듯함.. 에러도 많이 보고...

근데 스키마의 정확한 정의가 뭐려나
알고리즘은 언제 푸나

오늘의 계획

변경 사항 및 일정

없음

오전

좀 일찍 나와서 지금 딱 1시간 됨.
10시 20분...

알고리즘 하나 풀 시간이긴 하군

알고리즘 풀기
이후 API 생각해서 delete 까지 진행해보기.
지금 한거

  • 게시글 작성(create)
  • 게시글 목록 띄우기(find)
  • 게시글 수정하기(update)
  • 게시글 상세 페이지로 넘어가기
    (나는 posttable, inpost 두개를 했지만
    그냥 posttable에서 title을 find 한뒤
    그걸 게시글 목록 페이지에 html의 href를 수정하도록 동적 render한뒤
    posttabe 딴에서 이제 클릭되어 post method든 get method든 요청되면
    그걸로 post의 objectID 기준으로 find해서
    content와 title을 받아와 게시글 상세페이지를
    동적 render하는 route를 따로 분리해서 한 파일에 하면 될거같긴함.)

그럼 게시글 상세 페이지 기준으로
delete method가 들어오면 삭제 되면서
게시글 목록 페이지로 돌아오게 하는 것...

그리고 사실 이정도면 유저 로그인 확인은 문제 없고 그보다
(JWT든 passport든 모듈을 알아두긴 해야겠지만)
흠 댓글 작성자를 확인하는것도 JWT나 session 파트이긴 하겠네

그 파트는 일단 읽어만 두고
리액트를 해야겠다

delete 하기
session, JWT 읽어보기.

react 공부하기.

저녁

react 공부하기..

오늘의 다짐

감기 왕 많이 나았다
이젠 목이 부었다는 느낌도 안 듦

날씨도 많이 따뜻해졌다
오히려 좀 더울정도...
그래도 긴팔에 겉옷 하나는 걸치고 다님...

profile
개발자 희망...

0개의 댓글