#3 DB 세션에 대한 문제

#3 DB 세션에 대한 문제

 

뭔가 다들 화려하게 세션을 관리하는 것 같다.

자프링에선 그냥 @Transactional로 해결하는 것을 보면 아주 부럽다.

 

그래서 하나하나 왜 이렇게 하는지 뭐가 문제인지 찾아보면서 내 프로젝트에서는 

어떻게 세션관리를 코딩할지 고민했다.

 

[첫번째 - fastapi에서 보여준 그대로]

https://github.com/tiangolo/full-stack-fastapi-postgresql

라우터에서 세션객체를 받는방식이다. 저 타입은 아래와 같이 생겼다. 

공식문서에서는  자꾸 자꾸만 Annotated를 쓰라고 하던데 이유를 바로 알 수 있었다.

추상화된 타입에 의존할 수 있기 때문이였다! 아래와 같이 선언되었다.

(이렇게 추상화하면, 구현 모듈을 바꿀 때 dependency 레이어만 변경하면 그만이다.)

세션은 엄청 간단하게 구현했다.

 

[두번째 - 코리안 개발자의 클린 아키텍쳐🇰🇷]

https://github.com/jujumilk3/fastapi-clean-architecture

이분은 Database라는 클래스로 관리 했다. 의존성 주입은 fastapi가 아닌 다른 모듈을 사용해서 진행했다.

 

세션 팩토리에서 세션을 만들어서 던져주는데, 세션 팩토리는 아래와 같이 생겼다.

서비스 레이어에서 레포지토리를 분리해서 따로 레포지토리 클래스내 메서드에서 session()을 계속 호출해서 관리했다..

중복이 좀 많다고 느껴졌다.

 

그리고, scoped_session에 대해서 항상 궁금해서 찾아봤는데, 스레드당 세션을 만들어 주는 함수라고 한다.

같은 스레드에서 하나의 세션만 사용하게 한다는 것 같다.

하지만 이는 fastapi에서 문제가 된다. fastapi의 비동기 인터페이스 asgi는 node와 같은 싱글 스레드로 굴러가기 때문이다.

 

때문에 async_scopeㅌd_session을 써야 하는데 이는 sqlalchemy에서도 권장하지 않는 방식이라고 한다. (이유는 모름)

 

sessionmaker는 세션을 만들어주는 기능인데 scoped_session을 사용하지 않으면 그냥 Session객체를 생성해도 무방한 것 같다. (기능이 같은 것 같다)

 

따라서! 첫번째가 낫다.

 

[세번째 - 대규모 프로젝트에서 더 유용하댜고 하는 템플릿]

https://github.com/zhanymkanov/fastapi_production_template

여기는 아예 세션이 코어 영역에서만 관리되고 있다. (각 도메인 레이어에는 세션에 대한 정보가 없다)

그냥 아래의 3함수가 전부고 데이터베이스에 뭔가 하고 싶다면 아래 함수들을 이용해야 한다.

관리가 쉽고 참 좋겠지만, 복잡한 작업을 하는 세션에서는 좀 곤란하다. 한 세션에 하나의 쿼리밖에 못하니까.. 별로인것 같다.

 

————— 결론! —————

 

결국에는 첫번째 방식을 고수하고 (요청당 세션이 한개고 요청을 받으면 세션을 여는 방식)

서비스 레이어의 서비스 클래스에 세션을 주입하는 방식으로 결정했다.

 

scoped_session이나 sessionmaker와 같이 헷갈리는 친구들도 있었지만 결론은 메뉴얼이 최고라는 생각을 했다.