44일차 어디갔어요?
아 지금 본가를 내려왔는데 회사 노트북만 들고오고
개인 노트북에 44일차를 거의 다 쓰다가 퇴고를 못해가지고 글이 없다(임시글에도 없다..)
그래서 44일차는 일요일에나 올라갈듯 ㅎㅎ;
45일차였던 금요일에는 내가 반차를 써가지고 솔직히 적을만한 내용이 별로 없어서
요즘 내가 느끼는 것, 그리고 하고 있는 것을 적어보려고 한다.
흔히 가면증후군이라고, 자기가 잘 하고 있는지 판단을 못해서 혼란스러울 때를 지칭한다.
대충 비슷한 것을 느끼고 있어서 진지하게 고민을 해봤다.
현재 내가 하고 있는 업무량이 엄청 많고, 중요한 것을 담당하고 있는데 왜 이렇게 혼란스러울까?
결론은 기획서가 없어서.
였다
지금 작업을 완전 짧게 요약하면 이렇다.
이렇게 결론을 내렸더니 머리에 망치를 맞은 것처럼 약간 아찔해지는 것과 같은 느낌을 받았다..
기획서가 없다 = 이것을 알고 있는 사람이 나밖에 없다.
그래서 깔끔한 코드를 짜는 것에 있어서는 도움을 받을 수 있지만
프로세스 그 자체에 대해서는 조언을 받을 수 있는 사람이 없다.
내가 처음부터 담당하고 지금까지 작업을 했기 때문에, 내가 제일 잘 알고 있고, 알고 있어야만 한다.
그래서 노션을 통하여 내가 하고 있는 작업을 공유를 해서 PR에서 그것을 보면서 함께 리뷰를 받고 있다.
어떻게보면 신입이 너무 혼자 동떨어져서 작업을 하게된 것에서 오는 리스크라고 생각하는데
요즘 내 정신상태에 대해서 왜 이꼬라지인지 결론을 내려보니 조금 정신이 차려지더라
결론은 최대한 빨리 끝내가지고 다같이 작업을 할 수 있는 피쳐에 합류하고 싶다.
혼자 일하는 것은 상상이상으로 쓸쓸한 것 같다. (재택이라서 더 그럴지도 모르겠다.)
검색엔진 도입이 확정이 됐고, 이제 내가 해야하는 것은 엘라스틱서치를 도커파일로 만들어야한다.
그런데 프로덕션에 쓸 것이고, 가급적 최신버전을 쓰는게 좋다하여 8.4.2 버전을 사용하려고 하는데...
ES 8버전부터는 보안이 디폴트로 들어가있어서 설정하는 것이 상당히 까다롭다고 한다(ㅠㅠ)
심지어 아키텍쳐도 조금 독특해서, 인프라 네트워크라던가 AWS에 대한 공부도 잔득 해야할 것 같다.
아니지 리더님이 해주시지 않을까? 저는 믿습니다
참고하라고 글을 이것저것 전달해주셨는데 로그스태시를 붙일 때는 연락을 달라고...
감사합니다,,,제가 맛있는 것으로 대접해드리겠습니다..
https://younicode.tistory.com/entry/Elasticsearch-Docker-TLS
https://www.elastic.co/kr/blog/configuring-ssl-tls-and-https-to-secure-elasticsearch-kibana-beats-and-logstash
https://www.elastic.co/guide/en/elasticsearch/reference/7.17/configuring-tls-docker.html
이건 도커컴포즈 명령어 -> https://kimjingo.tistory.com/108
오버패칭의 문제가 심각해지기도 했고, 스키마 공유의 문제가 커서 그래프큐엘을 진지하게 생각하고 있었다.
그래프큐엘만 붙여도, 스키마 공유로 프론트분들의 부담이 확실히 줄어들 것이고
오버패칭으로 인한 슬로우쿼리도 조금은 줄일 수 있을 것이라 생각했기에 적용할 수 있으면 좋겠다! 라는 생각을 했고
그러다가 이거 프로덕션에 붙일 수 있다면 큰 경험이 될 것이라 판단이 들어 작업을 하기로 마음먹었다.
그런데 작업량이 좀 과한데?
그랬더니 바로 인증-인가부터 나를 괴롭히더라
완성이 되어있고, 실제로 서비스를 하고 있는 프로덕션 코드에 인증-인가에 대한 로직을 보는 일이 거의 없는 것이 사실이다.
그런데 이렇게 그래프큐엘을 붙이기 위해서 처음부터 작업을 다 하다보니까, 이런 것들을 다 둘러볼 수 있는 기회가 생긴 것이다 (오히려 좋아!)
그러면서 이것저것 치고박고 있는데, 몇개를 공유하면 좋겠다 싶어서 같이 올려본다.
만약 더 좋은 것이 있다면 알려주시라 ><
export const GqlResultFindAndCount = <T>(classRef: Type<T>): any => {
@ObjectType(`${classRef.name}`)
abstract class Type {
@Field(() => Int)
total: number;
@Field(() => [classRef])
list: T[];
}
return Type;
};
@ObjectType()
export class CountAndUser extends GqlResultFindAndCount(User) {}
종종 사용해야하는 엔티티인데, 그것을 매번 선언해서 사용하는 것은 매우 불편하다.
그래서 이와같이 제네릭으로 받을 수 있도록 만들어놓고 사용하면 재사용성이 좋아진다 :>
export const GqlResultUnionEntity = <T, K>(typeOne: ClassType<T>, typeTwo: ClassType<K>): any => {
return createUnionType({
name: 'Entity',
types: () => [typeOne, typeTwo] as const,
});
};
REST API를 사용 할 때, 내 목을 조르던 거지같았던 유니온은 그래프큐엘에서 이렇게 사용할 수 있다.
이게 세개 이상도 되는지에 대해서는 확인을 해봐야할 것 같은데... 되...되나?
덤으로 배열도 들어갔으면 좋겠는데 배열은 안들어갈까,,,,?
그러면서 느끼는 것은, 아 타입스크립트를 정말 잘 쓰면 좋겠다. 라는 생각이 마구마구 들었다.
왜냐하면 결국 타입스크립트를 잘 쓰면 인터페이스를 내 마음대로 다 만들어서 결국 gql 스키마에 꽂을 수 있기 때문인데..
타입에 대한 이해부터 좀 쌓아야 할 것 같다(...)
프리즈마는 아무리 만들더라도 제안을 할 순 없는 스택이긴 하다.
왜냐하면 ORM을 교체한다는 것은 무조건 큰 일이기 때문이고
TypeORM 0.2 -> 0.3 버전업이 그렇게 어렵지 않아서 굳이 넘어갈 이유는 없다.
물론 쿼리빌더로 SQL을 한 6줄 7줄씩 쓰다보면 이게 맞나 싶긴 한데(...)
그럼에도 불구하고 프리즈마와 TypeORM의 갭이 크기때문에,
러닝커브가 존재하다보니 비즈니스적인 관점에서 붙일 이유가 진짜 없다.
근데 그냥 써보고 싶어서(?) 이건 내년에.. 올해하면 내 생명력이 모자를 것 같고(...)
찬찬히 작업을 해보면 좋을 것 같다
현재 여러개의 작업이 한번에 이루어지고 있다보니, 깃을 조금 더 잘 다룰 수 있게 된 것 같다ㅋㅋ
덤으로 회사에 도입하면 좋고, 나도 공부를 할 수 있어서 Win to Win으로 스택도 넣고...
(이런건 다 업무시간이 아닌 업무 외의 시간에 한다는 점, 그냥 내 취미생활로 하는 것이다)
업무시간에는 지금 검색엔진 구현에 초점이 맞춰져 있었는데 코드는 다 짰고, 이제는 아키텍팅만 하면 된다!
끗
아니 왜 리턴타입이 전부 any에요 🤣🤣🤣