llm이 순식간에 테스트코드 만들어주는데 왜 테스트를 안하냐? 걍 내가 해준다

1) FastAPI의 캐싱에 대한 주장

여러번 얘기하는 거지만 너도 엔지니어라면 말을 정확히 해라.

너는 캐싱하는 게 아니라 걍 변수를 재사용하고 있는 거임.

캐싱은 lru_cache 같은 걸 써야 캐싱되는 거고,

니가 만든 건 함수가 매번 실행되는데 단지 값만 참조하는 거임.

2) 병렬처리에서 싱글톤을 쓰면 조립이 어렵고 안좋다?

싱글톤이 병렬 실행에 뭐가 어쨌단 거임?

gather로 그래프 병렬실행해도 오류 하나 안난다. 1만개를 실행해도 안남.

이렇기 때문에 네가 어설프게 mutable한 상태공유 시켜놓고

싱글톤 안좋다고 하는 것으로 밖에 안들림

아예 이렇게 만들어놓으면 _node가 dict라서 가변상태라는 걸 쉽게 알 수 있기 때문에

주의하면서 개발할 수 있고 아예 방지할 수도 있음.

그리고 나는 이미 병렬처리 존나게 하는 프로젝트를 여러개 성공시킨 사람인데

너는 뭘 성공시켜봤다고 나한테 '니 말대로 하면 뻗는다~' 이런 식의 소릴 자꾸 하는 거냐??

말할 때 잘 생각하고 발언해라.

3) 멀티워커 불가

이대로 돌리면

워커 2개 쓰면 인스턴스도 2개가 생성된다

여기서 "여러 인스턴스"란 네가 만든 람다 캡쳐 크로마 db 같은 게 여러개 생성된다는 거임

당연히 이럼 안되겠지?

4) Custom DI가 FastAPI 권장사항이다?

이게 진짜 권장 구현임

컨텍스트 매니저로 with 쓸 수 있게 하고

app.state쓰고

파이썬 권장 DI인 Depends를 쓴 코드임

딱 봐도 간결하고 심지어 더 빠르다

이해하기도 쉽고 모듈화하기도 편하지

근데 네 방식?

최악의 경우 코드가 10배 가까이 많아져야 할 수도 있음

아니 이런 걸 떠나서 상식적으로

FastAPI가 Native DI를 만들어놓고도

님들 저희 DI 쓰레기니깐 커스텀으로 만들어쓰세요~~~ 이러겠냐??

니가 나름의 미학이 있다고 해서 그런가보다 했던 거지

실제로 니가 맞다고 생각한 게 아님

프갤 알바가 제정신이 아닌지 자꾸 내 글 날려서 걍 이미지로 캡쳐해서 올렸다