ㄴㄴ내가 맞음. 왜냐면 걍 반박해줌. 에이도비야 - 프로그래밍 갤러리

성능 얘기는 '성능 조차 안좋다'는 의미지

뭔 성능에 집착한다는 소릴 하고있냐?

나라면 무겁고 비동기적인 처리가 요구되는 rag 작업은 워커가 맡도록 해서

celery & redis 조합으로 간단하게 개발할 거임

이렇게 개발하면 뭐 이 프로젝트에 필요한 모든 거 싹 다 간단히 다 끝낼 수 있음

실제로 나는 네가 구상한 rag의 4배 쯤 되는 볼륨의 보안 프로젝트를 그렇게 해서 2주 만에 끝낸 경력이있다.

그 시스템은 지금도 워커 3개가 가변적으로 실행되면서 10mb짜리 데이터를 하루에 1만 건 씩 처리하고 있고

유저가 중간에 1개소에 대한 설정을 바꿔도 바로바로 다음 처리부터 적용된다

그리고 메모리 누수보다 윈도우 보안 업데이트 주기가 더 빠르다

그에 비하면 네 프로젝트는 생산성 면에서도 미숙한 거임

난 네가 함수형 캡쳐 좋다고 하길래 직접 써보기까지 했는데

너는 자기 코드도 테스트 안하고 자기 말이 무조건 맞다고 하냐? 어이가 없네

애초에 넌 지금 fastapi가 자동관리한다는 것에 대해 완전히 오해하고 있음

지금 네가 해놓은 건 GC에게 알아서 내 똥 치워달라고 호소하는 급이야

python에서도 그렇고 fastapi 공식문서에서도 썼으면 치우라고 되어있는데

fastapi에게 치우는 걸 맡기겠다니 대체 뭔 소린지 이해가 안되네

컨텍스트 매니저를 통한 with사용을 하면 알아서 닫힌다는 걸 착각한거 아님?

그리고 fastapi로 di 하기 어렵다는 건 네 fastapi 실력 문제지. fastapi문제가 아니지.

이미 대부분이 다 지원되고 있고, 그게 맘에 안들면 니가 fastapi를 수정해서 쓰면 되잖음

커스텀 di를 만드는 건 취향이지만 그게 fastapi의 권장사항이라고 말하는건 아예 잘못된 거임

아니라고 생각하면 니가 얘기한 '권장'되는 부분이 담긴 문서를 인용해서 반박해봐라

글고 지금 네 방식은 스코프 관리가 전혀 없는데 이게 어떻게 현대적이냐?

애초에 니가 얘기하는 싱글톤의 위험이란 건 가변적인 걸 싱글톤에 박아넣었을 때,

그리고 스코프 관리가 제대로 안될 때 발생하는 건데

네 함수형 캡쳐는 이거랑 다름?

적어도 싱글톤이라고 명시해놨으면 그게 싱글톤인 줄 아니까 주의하면서 쓰는데

이렇게 전역으로 람다 써서 캡쳐로 박아버리면 이게 싱글톤인 줄 어떻게 아냐는 거임

애초에 아까 얘기한 것처럼 redis celery안써도

싱글톤에 가변되는 거 안 넣고 팩토리 & 레지스트리 패턴을 쓰면서 app나 요청 단위로 스코프를 한정지어서 쓰면

니가 원하는 거 다 되는 멀티톤 di가 됨

공식적으로 지원되는 것만 써도 그렇게 할수 있다는 거임

근데 왜 그거 안쓰면서 커스텀 di 만들어놓고 그게 권장이라고 하냐? 여러모로 말이 안된다는 거야

아니야? 아직도 네 방식이 맞다고 생각해?

그럼 니가 말이 맞다는 걸 커밋으로 증명해봐라

니 말이 맞다면 테스트했을 때 노드간 오염도 없고 리로드도 잘되고 멀티워커 써도 당연히 잘되겠지?

나도 마음만 먹으면 2시간 만에 테스트코드 만들 수 있을 것 같은데

레포 오너인 네가 이걸 안하겠다고 하진 않을 거 아님