FastAPI - 의존성 주입

1. Dependency

먼저 의존적이다 라는 개념에 대해서 알 필요가 있다.

이런 함수들이 있다고 생각해보자.

 

여기서 함수들은 query, skip, limit라는 매개변수를 입력을 받음에 따라 어떻게 결과값이 달라지고 그 매개변수가 존재하지 않는다면 해당 함수들은 동작하지 않게 된다.

그렇기에 메서드 item과 user의 경우는 매개변수인 query, skip, limit에 의존적인 상태라고 할 수 있다.

 

이렇게 간단한 함수에서 받는 매개변수들은 크게 의존적이다 라는 느낌을 받기가 힘드니까 클래스로 다시 만들어서 확인해보자.

이렇게 Car에서 engine을 받기 위해서 Engine()이라는 클래스의 인스턴스를 클래스의 내부에서 생성하게 된다.

이러면 Car 클래스는 Engine클래스를 직접 생성하기 때문에 해당 객체를 변경하기 위해서는 Car 클래스 내부의 소스를 변경해야만 하는 등의 강한 의존성과 결합성을 보인다.

만약에 Engine클래스의 생성자에서 매개변수를 받는다고 생각한다고 해보자.

그렇다면 이상태로 코드를 실행할 수 는 없다

또한 만약 다른 클래스를 사용하려고 하더라도 

해당 부분의 코드를 바꾸지 않는다면 다른 클래스를 생성해서 사용하는것도 불가능하다.

 

그렇기에 이를 해결하기 위해서 DI라는 개념이 사용된다.

2. FastAPI의 DI : Depends + function

FastAPI에서는 이를 해결하기 위해서 DI를 Depends라는 것을 사용한다

이 Depends에게 객체를 생성하는 함수를 전달하면 Fast API가 라우팅된 메서드에 파라미터를 들고 가져오기 전에 해당 함수로 이동해 객체를 생성해서 가져오게 된다.(전달되는 함수는 사용자가 직접 선언하는 것임)

위와 같이 메서드가 선언되어 있다고 생각해보자.

각각 제품의 정보와 사용자의 정보를 요청하면 n번째 부터 m번째까지의 데이터를 가져온다고 생각해보자

그렇다면 먼저 쿼리스트링으로 제품과 사용자의 정보를 전달할 것이고 몇번째 부터의 데이터를 몆개를 가져올지에 대해서 각각 추가해줘야만 한다.

 

이때 함수 하나를 선언해보자

이 함수는 공통이 되는 쿼리스트링, 시작지점, 가져올 갯수를 매개변수로 받아 dict형태로 return해준다.

그리고 각각의 메서드의 매개변수로 commons라는 변수명(임의 지정한 것)를 하나 생성해주자.

그러면 이제 각각의 메서드로 들어오기 전에 파라미터를 dict형태로 변경해서 해당 메서드의 매개변수로 전달해서 저장한다.

이러면 다수의 메서드에서 공통적으로 사용되는 매개변수들이 각각의 메서드에 의존적이지 않고 common_parameter에 의해 외부에서 주입되기 때문에 common_parameter를 변경하면 다수의 메서드들이 같이 변경되게 되고 이렇게 외부에서 주입하는 형태인 DI를 Fast API는 이런식으로 구현해뒀다.

 

확인해보면

이렇게 잘 반환하는 것을 볼 수 있다.

 

3. FastAPI의 DI : Depends + class

맨 위에서 우리가 클래스로 의존성에 대해서 확인했던것 처럼 함수를 전달하는게 아니라 클래스를 전달하면서도 의존성을 주입할 수 도 있다.

방법은 함수 대신 클래스를 전달하면 된다.

먼저 클래스를 우선 선언한다면

와 같이 선언할 수 있다.

그리고 이렇게 선언한 클래스의 타입으로 Depends에 

이렇게 넣어주면 된다 

이렇게 클래스로 선언하는 것의 장점은 자동완성이 된다는 것이다 

보면 dict형태로 주입하는 경우에는 자동완성이 불가능했으나

이렇게 자동완성 리스트에서 확인할 수 있는 것을 볼 수 있다.

 

근데 저렇게 하면 

이렇게 클래스의 타입을 두번씩 작성해야하는 불편함이 있다

이는 사실 자동완성을 쓰지 않을거라고 한다면 타입을 궂이 작성해줄 필요가 없다

그러면 또 자동완성을 못쓰지 않는가?

그래서 FastAPI는 

이렇게 해주는것도 이해해준다 

이렇게 사용하면 코드의 반복도 자동완성도 만들어준다.

 

4. 하위 의존성(Sub-Dependencies)

하위 의존성은 쉽게 말하면 DI를 여러번 사용한 구문을 의미한다.

하위 의존성은 하나의 큰 작업을 여러개의 작은 단계로 나눠 처리하기 위해서 사용하고 이를 통해서 가독성을 높이고 유지보수에 유리한 구조이다.

 

단순하게 구성해보자면 먼저 함수를 하나 생성해주고 

최종적으로는 이 라우팅된 함수에 의존성을 주입하게 될것이다.

 

첫번째로 우리가 사용자가 Header로 갖고 있는 API의 key를 통해서 해당 key를 가진 user가 누군지를 찾는 로직을 구현한다고 해보자

 

이를 위해서 헤더에서 key을 뽑아내는것 / key를 통해 user를 찾는것 / 그리고 이걸 해당 라우팅 함수와 매칭시키는것 이렇게 세가지의 기능이 필요하다.

 

이에 대한 함수를 각각 만들어보자면 먼저 헤더에서 key를 뽑아내는 key_collector함수를 선언해주자

그리고 키를 통해서 해당 사용자가 누구인지를 파악하는 함수를 또 하나 추가해주자.

이때 api_key는 Depends()에 의해 key_collector를 주입해여 얻어낸다

이제 본 라우팅하는 메서드에서 이걸 가져다 사용하면 된다.

 

이제 포스트맨을 사용해서 Header에 x-api-key에 1111을 넣어주고 get요청으로 users에 보내보자

 

이렇게 중첩되게 DI를 사용하면 소스가 깔끔하고 유지보수가 편하다.