app.state 패턴은 의존성 실패를 값으로 반환이 안되기때문에 전통적으로 예외처리를 함

하지만 이 경우에 반드시 UI를 동반한 앱은 치명적 오류를 던지게 되있음

하지만 I/O를 명확하게 분리한다면

이 오류에 대해서 '값(Value)' 처리를 함. 그렇다면 당연히 이 값 처리만 해준다면 유저는 치명적인 오류가 내부에서 발생해도 아무런 것도 모른 채 쓸 수 있고, 오작동이 아니라 생각하며

라우트 핸들러의 제어 흐름 자체가 완벽해짐. 이게 바로 Fast API고

이게 훨씬 논리적 일관성이 맞음.

중요한건 내 철학 하에 유저의 UX가 어떻게 흘러가느냐지.

속도가 어떻고는 다른 레벨

속도보다는 무조건 값이 일관되게 나와야하는 파이프 경계의 일관성때문에 선택한것.

그게 프로그래밍의 즐거움이고.

app.state로 썼다면 확장성이 너무 뒤떨어짐.

반드시 써야하는건 없지만 하나의 노드로 에이전트를 생각한다 할때, 여러 노드를 잇기위한 작업에선 무조건 DI 주입이 맞음

이견은 없음. 내가 맞기때문.