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 쓰레기니깐 커스텀으로 만들어쓰세요~~~ 이러겠냐??
니가 나름의 미학이 있다고 해서 그런가보다 했던 거지
실제로 니가 맞다고 생각한 게 아님
프갤 알바가 제정신이 아닌지 자꾸 내 글 날려서 걍 이미지로 캡쳐해서 올렸다
1. 목적이 잘못됐다니까. 애초에 노드 플로우로 하려고하는데 그냥 내가 테스트 작성해서 적어봄
그냥 하나하나 반박해봄
1. . lru_cache 방식의 '메모이제이션' 캐싱이 내 목적이 아님 내 의도는 '싱글톤 스코프'를 DI 컨테이너를 통해 구현하는 것
2. asyncio.gather는 단일 스레드에서 실행되는 비동기성임. 가변상태에 dict에 하는게 문제가 아니라, 스레드 세이프한 객체 참조만 하려고 하는거임
3.uvicorn--workers2 같은거 하면 별도의 OS 프로세스 2개 띄우는건데 이게 왜 2개 생성됐다고 난리냐? 뭔소리여. 대체 당연히 2개 생성되는걸.
4. 니가 말하는 API 컨테이너는 웹 컨테이너고, 내가 하는건 RAG라서 달라야하는데 뭔소리임 그냥 나도 글 하나 써준다
20분안에 새글써줌
LLM이 자꾸 딴소리해서 내가 직접 테스트까지 구현해서 올렸다
네가쓴 싱글톤 코드 자체가 문제임. 뭐가 문제인지 하나하나 조목조목 지적해줌
싱글톤 구현 + 공유된 가변 상태 (Shared Mutable State): ComponentFactory 클래스는 싱글톤 패턴(__new__ 사용)을 시도하는데 문제1: 클래스 변수인 _nodes: Dict[...] = {} 는 공유되고 변경 가능한(mutable) 상태고 get_node 메서드의 치명적인 결함 이 메서드는 self._nodes 딕셔너리에 대해 읽기(read)-검사(check)-쓰기(write) 작업을 원자적이지 않게 수행함 이러면 어떻게 값을 확신하냐고
@ㅆㅇㅆ(124.216) async def agent_node도 문제야. 이거 이렇게짜면 절대 안된다.
지적하는건 좋은데 내가 구현하고자하는 비동시성과 병렬에 대해서 좀 착각하고 있는거 아니냐
지금 코드 보니 ai가 쓴게 나오는데, 내 생각에 그냥 내 답변을 AI한테 물으면 어떤 대답 나오는지 물어봐라. 내 말이 맞음