여는 말
얼마 전 회사에서 모놀리식으로 되어 있던 프로젝트를 분할하여 MSA를 도입하자는 의견이 나왔다.
그 결과 특정 도메인을 시작으로 순차적으로 MSA를 도입하기로 결정됐다.
해당 도메인을 어떤 스택으로 구현할지 고민하던 중 내 머릿속에 FastAPI가 스쳐 지나갔다.
왜 FastAPI를 떠올렸는가?
Fast하게 가자.
FastAPI가 무엇인가?
공식 문서에서는 이 질문을 한 문장으로 설명한다.
FastAPI는 현대적이고, 빠르며(고성능), 파이썬 표준 타입 힌트에 기초한 Python3.6+의 API를 빌드하기 위한 웹 프레임워크입니다.
Python 기반의 빠르고, 빠르게 개발할 수 있고, 버그가 적으며 직관적인데다가 쉽게, 짧게, 견고한 표준 기반의 프레임워크가 바로 FastAPI다.
어떻게 그것이 가능한가?
적은 버그와 직관적인 코드에 대해 먼저 이야기해보자.
Type
파이썬은 인터프리터 언어이며 동적 언어이다.
변수의 타입은 선언이 아닌 실행 당시에 결정된다.
그렇기 때문에 아래와 같은 코드가 문법적으로는 문제가 되지 않는다.
tmp = 1
tmp = False
tmp = "tmp"
tmp = list()
tmp = dict()
print(tmp)
---
실행 결과 : {}나 역시도 이런 점이 파이썬의 큰 장점이라고 생각했다.
하지만 이 특징은 양날의 검과 같아서...
프로젝트의 규모가 커지고, 참여하는 인원이 늘어나고, 수정사항이 반복될 때 마다 TypeError를 마주하는 일이 잦아졌다.
이런 이슈로 인해 몇 년 전, 파이썬 3.5부터 타입 힌트와 타입 어노테이션이 추가됐다.
변수와 결과에 대해 타입을 명시하니 코드는 직관적이 되고, 에디터는 더 높은 수준의 보조가 가능해진다.
그리고 자연스럽게 적은 버그를 기대할 수 있다.
파이썬 타입은 갑자기 왜?
왜냐하면...
FastAPI의 Type
앞서 FastAPI는 파이썬 표준 타입 힌트에 기초했다는 말을 떠올려보라.
조금 이상하지 않은가?
타입 힌트는 FastAPI의 요소가 아닌 파이썬의 문법 중 하나인데, 왜 그런 말을 했을까?
Django나 Flask에서도 사용할 수 있는데.
공식 문서에 나와있는 Path Parameter를 통해서 간단하게 설명해보겠다.
from fastapi import FastAPI
app = FastAPI()
@app.get("/items/{item_id}")
async def read_item(item_id: int): # item_id를 int로 선언!
return {"item_id": item_id}위는 /items/{item_id}로 get 요청을 하면 item_id를 반환하는 아주 간단한 예시이다.
예제를 run하고 /items/3에 get 요청을 보내보자. {"item_id": 3}가 반환된다.
/items/hello로 요청을 하면TypeError가 발생한다!
기본적으로 Path Parameter는 string이다.
보통의 경우 item_id를 목적에 맞게 사용하기 위해선 int로 캐스팅이 필요하지만, FastAPI에선 선언된 타입으로 알아서 캐스팅을 진행한다.
item_id를 int로 선언을 했기 때문에 /items/3은 정상적으로 동작하고 /items/hello는 hello를 int로 캐스팅 할 수 없기 때문에 TypeError를 뱉은 것이다.
첫 번째 요청에서의 반환값을 보라.
{"item_id": 3}에서 3이 string이 아니다. (따로 캐스팅을 해주지 않았음에도 불구하고)
이것이 표준 타입 힌트에 기초한 FastAPI의 장점이다.
맺는 말
FastAPI의 타입 검증은 pydantic에 기초한다.
엄밀히 말하면 pydantic은 검증이 아닌 파싱을 위한 용도로 사용되는데, 이 과정에서 변수에 선언된 타입과 맞지 않는 값을 넣는 경우 캐스팅에 실패해 TypeError가 발생하는 원리다.
그럼, Fast! ⚡
