빠른 포기도 중요하다... CRUD 하루 이틀이면 할 수 있던걸 괜히..!! 이상한 구석에 꽂혀서;ㅎ
근데 될 것 같아서 놓기가 어려웠다.....,,, 아쉽다
아무튼.. 오늘도 화이팅!
삽질 기록할 때 개념 / 구현 / 오류 삽질 기록 섹션으로 나눌 예정이고 의식의 흐름대로 적을거임!!
다시 보니까 내 글이 제일 재밌다 ㅎㅎ
아근데 자꾸 쓸데없는 궁금증으로 해야할 것은 안하고 뻘짓 구글링 개많이한다.
오늘 피드백 페이지에 개선점을 고민해서 적어봐야겠다...
개념
의존 역전 법칙
자신보다 변하기 쉬운 것에 의존하던 것을 추상화된 인터페이스나 상위 클래스를 두어 변하기 쉬운 것의 변화에 영향받지 않게 하는 것이
의존 역전 원칙이다.
왜 생쿼리를 안쓰지
구글링하다가 본 문서에서 orm 메서드보다 생쿼리가 더 빠르다는 내용을 봤다.
쌩쿼리가 더 빠른 이유: custom queries will always be faster option since find does many things (converts results into class instance object, calls listeners, etc. etc.).
라고하는데 왜 굳이 느린 걸 쓸까? 하는 의문이 들었다.
개발자분께 물어보니 보통 orm 쓰는 이유 의존성 낮추는 용도 + 객체단위로 로직수행 때문이라고 하는데
궁금해서 더 구글링해봄.
Comparing SQL, query builders, and ORMs
Raw SQL vs Query Builder vs ORM 으로 구글링해봄
https://www.prisma.io/dataguide/types/relational/comparing-sql-query-builders-and-orms // 여기
보고싶었던 문서였는데 회원가입도 해야하고....그랬던 문서를
https://dlfdyd96.tistory.com/entry/Raw-SQL-vs-Query-Builder-vs-ORM 에서 블로그에 번역해주심 개꿀!
대충..읽어보니까, 실수를 줄일 수 있고, 유지보수가 더 쉽다/ 변화에 유동적으로 대응이 가능하다는 점에서 속도 감안해서 대게 orm 쓴다는 듯 (위 표에 나와있다시피 ORMs = Programming-Oriented라는 의미가 이런 느낌인듯.)
좀 복잡해지면 쿼리 빌더 or 속도가 중요해서 빠르게 처리해야하는 건 생쿼리 쓴다고 이해함.
Custom Repository 삭제한 개발자의 의도가 궁금해
엄청난 삽질 끝에 ... 안쓴다고 선언은 했는데 이렇게까지 많은 유저들이 써왔던 @EntityRepository를 TypeORM 0.3에서 이렇게 매정하게 삭제한 이유가 이해가 안가서 좀 찾아봤다.
https://github.com/typeorm/typeorm/pull/8616
https://github.com/typeorm/typeorm/issues/9312 // 여기 문서로 파도타기 함
일단... Migrating 하려면 https://gist.github.com/anchan828/9e569f076e7bc18daf21c652f7c3d012
공식 typeORM 문서
이렇게 문서 보면 된다.
creating custom repos via inheritance was removed 라는데 (일단 사실 맘만 먹으면 custom repo 쓸 수 있는건 알겠고 방식을 변경한거구나 라고 이해함)
여기 글에서 나랑 똑같은 질문을 한 사람이 있어서 또 읽어봄
We use NestJS, so our custom repositories are becoming custom providers without too much trouble. There is a gist someone posted in another issue that another dev is using to aid in migrating our custom repos to Nest providers, in case it's helpful: here
라는 코멘트를 발견했다.
다시 말해 (결국 내가 이해한 것이 맞다면)
custom Repository가 상속 받은뒤, 확장된 메서드를 정의할 때
로직 분리가 안되어있어서 나중에 디버깅할 때 service를 봐야할지 custom repository를 봐야할지 많은 문제가 발생한다.
그래서 아예 새로운 custom provider로서 바로 controller에 갖다 쓸 수 있도록 한 것 같음. (확실한 것 아님, 나 하나도 모름)
아 근데... 일단 제끼자; 시간낭비 대박 많이함..
NestJs 라이프싸이클 (Express 미들웨어와 비교)
출처: https://velog.io/@kakasoo/Express만-하다가-Nest를-하고-느낀-점
Request부터 Response를 돌려주기까지의 라이프 사이클에 관여하는 게 middleware인 것은 맞지만, 그걸 다 middleware라고 부르는 건 지나치게 뭉뚱그리는 행위다.
Guards : passport.js와 같이 인증, 또는 Role을 부여하는 것
Interceptors : Request와 Response의 처음과 끝에 동작하는 종류, 예컨대 logger처럼 각 API가 동작하는 데 걸리는 ms를 측정하는 종류
Pipes : 값에 대한 transform, 또는 validator를 담당하는 역할
filters : 예외를 처리하는 역할
decotrators : ES2016 데코레이터, 함수를 반환하고 대상, 이름 속성 설명자를 인수로 사용하는 표현식이다. Guards, Interceptors, Pipes 등은 모두 decorator의 형태로 표현된다.
- 라이프사이클
Reqeust가 들어오면.- Guards ( 글로벌, 컨트롤러, 루트 순서 )
- Interceptors ( 글로벌, 컨트롤러, 라우트 순서 )
- Pipes ( 글로벌, 컨트롤러, 라우트, 라우트 매개 변수 파이프 순서 )
- Controller // Express에서 말하는 API
- Service // DB에 접근하는 Business logic을 담고 있다.
- Interceptors ( 라우트, 컨트롤러, 글로벌 순서 )
- filter ( 예외 처리 )
Response를 반환한다.
나머지 상세사항은 저 위 참고링크 읽고오면 됨.
DELETE 구현
깃허브 주소
CustomRepository 쓸거라고 안나댔으면.. 빠른 포기도 좋은 정답일수도 있다 ㅎ
Github pull request tutorial
Create는 메인브랜치에 이미 합쳐버렸고..
RUD는 브랜치 나눠서 pr했다.
이거 pr 확인받고 나서 머지할 때 분명 또 엄청나게 헤맬듯
Github 존내 공부..
https://backlog.com/git-tutorial/kr/stepup/stepup1_5.html
오 pr 들어온거 이렇게 달라진다 (첫번째 항목)
Pull request 해보기
- PR description (구글링해보면 템플릿도 있다!!)
리뷰 받아보기
prefix: p0, p1, p2
p0 오류나서 안됨 문제 발생 코드
p1 컨벤션하지 않다 / 돌아가긴하는데 비효율적인 것
p2 별 필요는 없는데 다른 방법도 가능할 것 같다 제안하기 (이번 pr에서는 없음)
수정 커밋하고 나서 간단하게 완료 라고 적었는데 싸가지없다고 욕먹었다 (ㅇㅋ)
간단하게 적으면 되는건줄
협업이 제일 중요하구나..! 이해완료했습니다 :)
이제 pr, 브랜치 관리 제대로 하자!
