대안, 영감과 비교

대안, 영감과 비교 (Alternatives, Inspiration and Comparisons)

FastAPI가 어디에서 왔는지, 무엇에 영감을 받았고, 기존 대안들과 어떻게 비교되는지 궁금하지 않나요? FastAPI는 빈손에서 튀어나온 게 아니에요. 수많은 이전 도구들의 최고 아이디어를 모아 만든 결과물이죠. 그 이야기를 차근차근 들려드릴게요.

출처: 공식문서

무엇이 FastAPI에 영감을 주었고, 대안들과 어떻게 비교되며, 그들에게서 무엇을 배웠는지 다룹니다.

서문

FastAPI는 다른 사람들의 이전 작업이 없었다면 존재하지 않았을 거예요.

그 전에 만들어진 많은 도구들이 그 탄생에 영감을 주었습니다.

저는 몇 년 동안 새 프레임워크를 만드는 걸 피해 왔어요. 처음에는 FastAPI가 다루는 모든 기능을 수많은 다른 프레임워크·플러그인·도구로 해결하려고 했죠.

하지만 어느 순간, 이 모든 기능을 제공하는 무언가를 만드는 것 말고는 다른 선택이 없었어요. 이전 도구들의 최고 아이디어를 가져와서, 이전에는 없었던 언어 기능(파이썬 3.6+ 타입 힌트)을 써서 최선의 방법으로 결합하는 거였죠.

이전 도구들 (Previous tools)

Django

가장 인기 있는 파이썬 프레임워크이고, 널리 신뢰받아요. Instagram 같은 시스템을 만드는 데 쓰이죠.

관계형 데이터베이스(MySQL이나 PostgreSQL 같은)와 비교적 밀접하게 결합되어 있어서, NoSQL 데이터베이스(Couchbase, MongoDB, Cassandra 등)를 메인 저장 엔진으로 쓰는 건 그리 쉽지 않아요.

백엔드에서 HTML을 생성하기 위해 만들어졌지, 현대 프론트엔드(React, Vue.js, Angular 같은)나 다른 시스템(예: IoT 장치)과 통신하는 API를 만들기 위한 건 아니에요.

Django REST Framework

Django REST Framework는 Django를 바탕으로 Web API를 구축하기 위한 유연한 툴킷으로 만들어졌고, Django의 API 능력을 향상시키기 위한 거였어요.

Mozilla, Red Hat, Eventbrite를 포함해 많은 회사가 사용하고 있어요.

자동 API 문서화의 첫 사례 중 하나였고, 이것이 특히 "FastAPI를 찾게 된" 첫 아이디어 중 하나였습니다.

참고

Django REST Framework는 Tom Christie가 만들었어요. FastAPI가 기반으로 하는 Starlette와 Uvicorn의 창시자이기도 하죠.

팁 | FastAPI에 준 영감

자동 API 문서화 웹 UI를 가지는 것.

Flask

Flask는 "마이크로프레임워크"예요. 데이터베이스 통합이나 Django에 기본으로 딸려 오는 많은 것들을 포함하지 않아요.

이 단순함과 유연함 덕분에 NoSQL 데이터베이스를 메인 데이터 저장소로 쓰는 같은 일을 할 수 있죠.

아주 단순해서 비교적 배우기 직관적이지만, 문서는 어떤 지점에서는 좀 기술적이 되기도 해요.

데이터베이스·사용자 관리·Django에 미리 내장된 많은 기능들이 꼭 필요하지 않은 다른 앱들에도 흔히 쓰여요. 물론 그 많은 기능들은 플러그인으로 추가할 수 있지만요.

이 **부분들의 분리(decoupling)**와, 필요한 것만 정확히 확장할 수 있는 "마이크로프레임워크"라는 점은 제가 꼭 유지하고 싶었던 핵심 기능이었어요.

Flask의 단순함을 생각해 보면 API를 만드는 데 아주 잘 맞는 것 같았죠. 다음으로 찾을 것은 Flask를 위한 "Django REST Framework"였어요.

팁 | FastAPI에 준 영감

마이크로프레임워크가 되는 것. 필요한 도구와 부품을 쉽게 섞고 매치하게 하는 것.

단순하고 쓰기 쉬운 라우팅 시스템을 가지는 것.

Requests

FastAPI는 실제로 Requests의 대안이 아니에요. 그 둘의 범위는 아주 다르죠.

오히려 FastAPI 어플리케이션 안에서 Requests를 쓰는 게 흔할 거예요.

그래도 FastAPI는 Requests에서 꽤 많은 영감을 얻었어요.

Requests는 API와 상호작용하는(클라이언트로서) 라이브러리이고, FastAPI는 API를 만드는(서버로서) 라이브러리예요.

그 둘은 대략 반대쪽 끝에 있으면서 서로를 보완해요.

Requests는 아주 단순하고 직관적인 설계에, 쓰기 쉽고 합리적인 기본값을 가져요. 하지만 동시에 아주 강력하고 커스터마이즈 가능하죠.

그래서 공식 웹사이트에서 말하듯:

Requests는 역사상 가장 많이 다운로드된 파이썬 패키지 중 하나다

쓰는 방식이 아주 단순해요. 예를 들어 GET 요청을 하려면 이렇게 씁니다:

response = requests.get("http://example.com/some/url")

FastAPI 쪽의 대응하는 API path operation은 이렇게 생겼을 거예요:

@app.get("/some/url")
def read_url():
    return {"message": "Hello World"}

requests.get(...)와 @app.get(...)의 유사성을 볼 수 있죠.

팁 | FastAPI에 준 영감

  • 단순하고 직관적인 API를 가지는 것.
  • HTTP 메서드 이름(연산)을 직접, 직관적인 방식으로 쓰는 것.
  • 합리적인 기본값을 가지되 강력한 커스터마이제이션을 허용하는 것.

Swagger / OpenAPI

Django REST Framework에서 제가 원했던 주요 기능은 자동 API 문서화였어요.

그다음에 API를 문서화하는 표준이 있다는 걸 알게 됐죠. JSON(또는 JSON의 확장인 YAML)을 쓰는 것으로, Swagger라고 불러요.

그리고 Swagger API를 위한 웹 UI가 이미 만들어져 있었어요. 그래서 API에 대한 Swagger 문서를 생성할 수 있으면 그 웹 UI를 자동으로 쓸 수 있게 되는 거죠.

어느 시점에 Swagger가 Linux Foundation에 넘겨지면서 OpenAPI로 이름이 바뀌었어요.

그래서 버전 2.0을 말할 땐 "Swagger", 버전 3+에선 "OpenAPI"라고 하는 게 흔해요.

팁 | FastAPI에 준 영감

커스텀 스키마 대신 API 스펙을 위한 개방형 표준을 채택해 쓰는 것.

그리고 표준 기반 UI 도구를 통합하는 것:

이 둘은 꽤 인기 있고 안정적이어서 골랐지만, 조금만 검색해도 OpenAPI용 대안 UI를 수십 개 찾을 수 있어요(그리고 FastAPI와 쓸 수 있죠).

Flask REST 프레임워크들

여러 Flask REST 프레임워크가 있지만, 조사에 시간과 노력을 쏟은 결과 많은 것이 중단되거나 버려졌고, 사용하기 부적합하게 만드는 몇 가지 미해결 문제들이 있었어요.

Marshmallow

API 시스템이 필요로 하는 주요 기능 중 하나는 데이터 "직렬화(serialization)"인데, 이는 코드(파이썬)에서 데이터를 가져와 네트워크로 보낼 수 있는 무언가로 변환하는 거예요. 예를 들어 DB에서 온 데이터를 담은 객체를 JSON 객체로 변환하는 것, datetime 객체를 문자열로 변환하는 것 등이죠.

API가 필요로 하는 또 다른 큰 기능은 데이터 검증(validation)이에요. 특정 파라미터가 주어졌을 때 데이터가 유효한지 확인하는 것, 예를 들어 어떤 필드가 int여야 하고 무작위 문자열이 아니어야 하는 것처럼요. 특히 들어오는 데이터에 유용하죠.

데이터 검증 시스템이 없으면 모든 확인을 코드에서 손으로 해야 해요.

이것들이 Marshmallow가 제공하려고 만들어진 기능들이에요. 훌륭한 라이브러리이고, 저도 이전에 많이 썼어요.

하지만 파이썬 타입 힌트가 존재하기 전에 만들어졌죠. 그래서 모든 스키마(데이터가 어떻게 형성돼야 하는지에 대한 정의)를 정의하려면 Marshmallow가 제공하는 특정 유틸과 클래스를 써야 했어요.

팁 | FastAPI에 준 영감

데이터 타입과 검증을 자동으로 제공하는 "스키마"를 코드로 정의하는 것.

Webargs

API가 요구하는 또 다른 큰 기능은 들어오는 요청에서 데이터를 파싱(읽어서 파이썬 데이터로 변환)하는 거예요.

Webargs는 Flask를 포함한 여러 프레임워크 위에서 이를 제공하기 위해 만들어진 도구예요.

데이터 검증을 위해 바탕에서 Marshmallow를 쓰고, 같은 개발자들이 만들었죠.

훌륭한 도구이고, FastAPI가 있기 전에도 많이 썼어요.

참고

Webargs는 Marshmallow와 같은 개발자들이 만들었어요.

팁 | FastAPI에 준 영감

들어오는 요청 데이터의 자동 검증을 가지는 것.

APISpec

Marshmallow와 Webargs는 플러그인으로 검증·파싱·직렬화를 제공해요.

하지만 문서화는 여전히 빠져 있었죠. 그래서 APISpec이 만들어졌어요.

많은 프레임워크를 위한 플러그인이고(Starlette용 플러그인도 있어요), route를 처리하는 각 함수의 docstring 안에 YAML 형식으로 스키마 정의를 쓰는 방식으로 동작해요.

그리고 OpenAPI 스키마를 생성해 줍니다.

Flask, Starlette, Responder 등에서 그렇게 동작해요.

하지만 그렇게 하면 다시 파이썬 문자열 안에 마이크로 문법(큰 YAML)을 넣는 문제가 생기죠.

에디터가 그걸 많이 도와주지 못해요. 또 파라미터나 Marshmallow 스키마를 수정하면서 그 YAML docstring을 고치는 걸 잊으면, 생성된 스키마가 낡아버려요.

참고

APISpec은 같은 Marshmallow 개발자들이 만들었어요.

팁 | FastAPI에 준 영감

API를 위한 개방형 표준, OpenAPI를 지원하는 것.

Flask-apispec

Flask 플러그인으로, Webargs·Marshmallow·APISpec을 엮어 줘요.

Webargs와 Marshmallow의 정보를 사용해, APISpec으로 OpenAPI 스키마를 자동 생성해요.

훌륭한데도 꽤 저평가된 도구예요. 많은 Flask 플러그인보다 훨씬 유명해져야 마땅한데 말이죠. 문서가 너무 간결하고 추상적이어서일 수도 있어요.

이건 파이썬 docstring 안에 YAML(또 다른 문법)을 써야 하는 문제를 해결해 줬어요.

Flask, Flask-apispec을 Marshmallow와 Webargs와 함께 쓰는 조합이 FastAPI를 만들기 전까지 제가 가장 좋아하는 백엔드 스택이었어요.

그것을 쓰면서 여러 Flask 풀스택 생성기(full-stack generators)를 만들게 됐죠. 지금까지 저(그리고 몇몇 외부 팀)가 쓰고 있는 주요 스택들은 이렇습니다:

그리고 이 같은 풀스택 생성기들이 FastAPI 프로젝트 생성기의 바탕이 됐어요.

참고

Flask-apispec은 같은 Marshmallow 개발자들이 만들었어요.

팁 | FastAPI에 준 영감

직렬화와 검증을 정의하는 바로 그 코드에서 OpenAPI 스키마를 자동 생성하는 것.

NestJS (그리고 Angular)

이건 파이썬도 아니에요. NestJS는 Angular에서 영감을 받은 JavaScript(TypeScript) NodeJS 프레임워크예요.

Flask-apispec으로 가능한 것과 꽤 비슷한 걸 이룹니다.

Angular 2에서 영감을 받은 통합 의존성 주입(dependency injection) 시스템을 가지고 있어요. "인젝터블(injectables)"을 미리 등록하는 걸 요구해서(제가 아는 다른 의존성 주입 시스템들처럼), 장황함과 코드 반복이 늘어났죠.

파라미터를 TypeScript 타입으로 기술하기 때문에(파이썬 타입 힌트와 비슷하게), 에디터 지원이 꽤 좋아요.

하지만 TypeScript 데이터는 JS로 컴파일된 뒤 보존되지 않으므로, 타입에 의존해 검증·직렬화·문서화를 동시에 할 수는 없어요. 이 점과 몇 가지 설계 결정 때문에, 검증·직렬화·자동 스키마 생성을 얻으려면 많은 곳에 데코레이터를 추가해야 해요. 그래서 꽤 장황해지죠.

중첩 모델도 잘 처리하지 못해요. 그래서 요청의 JSON 본문이, 내부 필드가 다시 중첩 JSON 객체인 객체라면, 제대로 문서화·검증되지 못해요.

팁 | FastAPI에 준 영감

훌륭한 에디터 지원을 위해 파이썬 타입을 쓰는 것.

강력한 의존성 주입 시스템을 가지는 것. 코드 반복을 최소화하는 방법을 찾는 것.

Sanic

asyncio 기반의 최초의 극도로 빠른 파이썬 프레임워크 중 하나였어요. Flask와 아주 비슷하게 만들어졌죠.

참고 | 기술적 세부 사항

기본 파이썬 asyncio 루프 대신 uvloop를 사용했어요. 그게 그렇게 빠른 이유였죠.

오픈 벤치마크에서 현재 Sanic보다 빠른 Uvicorn과 Starlette를 분명히 영감을 줬어요.

팁 | FastAPI에 준 영감

미친 듯한 성능을 얻는 방법을 찾는 것.

그래서 FastAPI가 Starlette에 기반하는데, 그것이(제3자 벤치마크로 검증된) 가장 빠른 프레임워크이기 때문이에요.

Falcon

Falcon은 또 다른 고성능 파이썬 프레임워크로, 최소주의로 설계되었고 Hug 같은 다른 프레임워크의 기반으로 동작해요.

파라미터 두 개(하나는 "request", 하나는 "response")를 받는 함수를 갖도록 설계됐어요. 그리고 request에서 부품을 "읽고", response에 부품을 "쓴다". 이 설계 때문에 표준 파이썬 타입 힌트를 함수 파라미터로 요청 파라미터와 본문을 선언할 수 없어요.

그래서 데이터 검증·직렬화·문서화를 자동이 아닌 코드로 해야 해요. 아니면 Hug처럼 Falcon 위에 프레임워크로 구현해야 하죠. request 객체 하나와 response 객체 하나를 파라미터로 갖는 Falcon의 설계에서 영감을 받은 다른 프레임워크에도 같은 구분이 있어요.

팁 | FastAPI에 준 영감

훌륭한 성능을 얻는 방법을 찾는 것.

Hug와 함께(Falcon에 기반하므로) FastAPI가 함수에 response 파라미터를 선언하도록 영감을 줬어요.

FastAPI에서는 선택사항이고, 주로 헤더·쿠키·대체 상태 코드를 설정하는 데 쓰이지만요.

Molten

FastAPI를 만드는 첫 단계에서 Molten을 발견했어요. 이것도 꽤 비슷한 아이디어를 갖고 있죠:

  • 파이썬 타입 힌트 기반.
  • 이 타입들로부터 검증과 문서화.
  • 의존성 주입 시스템.

Pydantic 같은 제3자 데이터 검증·직렬화·문서화 라이브러리를 쓰지 않고, 자기만의 것을 써요. 그래서 그 데이터 타입 정의는 그렇게 쉽게 재사용되지 않아요.

설정이 조금 더 장황하길 요구해요. 또 WSGI 기반(ASGI 대신)이라 Uvicorn·Starlette·Sanic 같은 도구가 제공하는 고성능을 활용하도록 설계되지 않았어요.

의존성 주입 시스템은 의존성을 미리 등록해야 하고, 선언된 타입에 기반해 의존성이 해석돼요. 그래서 특정 타입을 제공하는 "컴포넌트"를 둘 이상 선언할 수 없어요.

Route는 한 곳에서 선언하는데, 다른 곳에서 선언된 함수를 사용해요(엔드포인트를 처리하는 함수 위에 바로 놓을 수 있는 데코레이터를 쓰는 대신). 이건 Flask(와 Starlette) 방식보다 Django 방식에 더 가까워요. 상대적으로 밀접하게 결합된 것들을 코드에서 분리해요.

팁 | FastAPI에 준 영감

모델 속성의 "기본값"을 사용해 데이터 타입에 추가 검증을 정의하는 것. 이는 에디터 지원을 향상시키고, 그전에는 Pydantic에 없던 것이었어요.

이건 실제로 Pydantic의 일부를 업데이트해 같은 검증 선언 스타일을 지원하게 하는 데 영감을 줬어요(이 모든 기능은 이제 이미 Pydantic에 있어요).

Hug

Hug는 파이썬 타입 힌트로 API 파라미터 타입을 선언하는 것을 구현한 최초의 프레임워크 중 하나였어요. 다른 도구들이 똑같이 하도록 영감을 준 멋진 아이디어였죠.

선언에 표준 파이썬 타입 대신 커스텀 타입을 사용했지만, 여전히 거대한 진전이었어요.

전체 API를 JSON으로 선언하는 커스텀 스키마를 생성하는 최초의 프레임워크 중 하나이기도 했어요.

OpenAPI나 JSON Schema 같은 표준에 기반하지 않았죠. 그래서 Swagger UI 같은 다른 도구와 통합하는 게 간단치 않았어요. 하지만 역시 아주 혁신적인 아이디어였어요.

흥미롭고 드문 기능이 있어요: 같은 프레임워크로 API와 CLI를 모두 만들 수 있다는 점이요.

동기식 파이썬 웹 프레임워크의 이전 표준(WSGI)에 기반해서 Websocket 같은 건 처리할 수 없지만, 여전히 높은 성능을 가지기도 해요.

참고

Hug는 Timothy Crosley가 만들었어요. 파이썬 파일에서 import를 자동 정렬해 주는 훌륭한 도구 isort의 창시자이기도 하죠.

팁 | FastAPI에 영감을 준 아이디어들

Hug는 APIStar의 일부에 영감을 줬고, APIStar와 함께 제가 가장 유망하다고 본 도구 중 하나였어요.

Hug는 FastAPI가 파라미터를 선언하고 API를 정의하는 스키마를 자동 생성하는 데 파이썬 타입 힌트를 쓰도록 영감을 줬어요.

Hug는 FastAPI가 함수에서 헤더와 쿠키를 설정하기 위해 response 파라미터를 선언하도록 영감을 줬어요.

APIStar (<= 0.5)

FastAPI를 만들기로 결정하기 직전에 APIStar 서버를 발견했어요. 내가 찾던 거의 모든 것을 가지고 있었고 훌륭한 설계였죠.

파라미터와 요청을 선언하는 데 파이썬 타입 힌트를 쓰는 프레임워크의 최초 구현 중 하나였어요(NestJS와 Molten보다 먼저). 대략 Hug와 같은 시기에 발견했는데, APIStar는 OpenAPI 표준을 사용했죠.

여러 곳에서 같은 타입 힌트에 기반한 자동 데이터 검증, 데이터 직렬화, OpenAPI 스키마 생성을 가졌어요.

본문 스키마 정의는 Pydantic과 같은 파이썬 타입 힌트를 쓰지 않아 Marshmallow에 좀 더 가까워서 에디터 지원은 그만 못했지만, 그래도 APIStar가 당시 최고의 선택이었어요.

그 당시 최고의 성능 벤치마크를 가졌죠(Starlette에만 뒤처짐).

처음엔 자동 API 문서화 웹 UI가 없었지만, Swagger UI를 추가할 수 있다는 걸 알고 있었어요.

의존성 주입 시스템을 가졌어요. 위에서 논의한 다른 도구들처럼 컴포넌트를 미리 등록해야 했죠. 그래도 멋진 기능이었어요.

보안 통합이 없어서 실제 프로젝트에서 쓰지는 못했어요. 그래서 Flask-apispec 기반 풀스택 생성기로 얻고 있던 모든 기능을 대체할 수 없었죠. 그 기능을 추가하는 pull request를 만들 프로젝트가 백로그에 있었어요.

그런데 그뒤로 프로젝트의 초점이 바뀌었죠.

더 이상 API 웹 프레임워크가 아니었어요. 창시자가 Starlette에 집중할 필요가 있었기 때문이에요.

이제 APIStar는 OpenAPI 스펙을 검증하는 도구 모음이지, 웹 프레임워크가 아니에요.

참고

APIStar는 Tom Christie가 만들었어요. 다음을 만든 그 사람이죠:

  • Django REST Framework
  • Starlette(FastAPI가 기반)
  • Uvicorn(Starlette와 FastAPI가 사용)

팁 | FastAPI에 준 영감

존재하게 하는 것.

같은 파이썬 타입으로 여러 가지(데이터 검증, 직렬화, 문서화)를 선언하고, 동시에 훌륭한 에디터 지원을 제공한다는 아이디어는 제가 훌륭하다고 여긴 것이었어요.

그리고 오랫동안 비슷한 프레임워크를 찾고 많은 대안을 테스트한 끝에, APIStar가 가능한 최선의 선택이었죠.

그런 다음 APIStar가 서버로서 존재를 멈추고 Starlette이 만들어졌으며, 그런 시스템을 위한 새롭고 더 나은 기반이 됐어요. 그게 FastAPI를 만들게 한 마지막 영감이었습니다.

저는 FastAPI가 이 모든 이전 도구들로부터의 배움에 기반해, 기능·타입 시스템·다른 부분들을 개선하고 늘려가는 APIStar의 "정신적 후계자"라고 생각해요.

FastAPI가 사용하는 것 (Used by)

Pydantic

Pydantic은 파이썬 타입 힌트에 기반해 데이터 검증·직렬화·문서화(JSON Schema 사용)를 정의하는 라이브러리예요.

그래서 극도로 직관적이죠.

Marshmallow와 비교할 만해요. 벤치마크에서는 Marshmallow보다 빠르고, 같은 파이썬 타입 힌트에 기반하므로 에디터 지원도 좋아요.

팁 | FastAPI가 쓰는 용도

모든 데이터 검증, 데이터 직렬화, 자동 모델 문서화(JSON Schema 기반)를 처리하는 것.

FastAPI는 그 JSON Schema 데이터를 OpenAPI에 넣고, 그것 외에 하는 다른 모든 일도 합니다.

Starlette

Starlette은 가벼운 ASGI(비동기 파이썬 웹 애플리케이션을 만드는 새 표준) 프레임워크/툴킷으로, 고성능 asyncio 서비스를 만드는 데 이상적이에요.

아주 단순하고 직관적이죠. 쉽게 확장되고 모듈식 컴포넌트를 갖도록 설계됐어요.

이것을 가져요:

  • 정말 인상적인 성능.
  • WebSocket 지원.
  • 프로세스 내 백그라운드 태스크.
  • 시작·종료 이벤트.
  • HTTPX 기반 테스트 클라이언트.
  • CORS, GZip, Static Files, Streaming responses.
  • Session과 Cookie 지원.
  • 100% 테스트 커버리지.
  • 100% 타입 어노테이션 코드베이스.
  • 하드 의존성이 적음.

Starlette은 현재 테스트된 가장 빠른 파이썬 프레임워크예요. 프레임워크가 아니라 서버인 Uvicorn에만 뒤처집니다.

Starlette은 모든 기본 웹 마이크로프레임워크 기능을 제공해요.

하지만 자동 데이터 검증, 직렬화, 문서화는 제공하지 않아요.

그것이 FastAPI가 (Pydantic을 사용해) 전부 파이썬 타입 힌트 기반으로 더하는 주요한 것 중 하나예요. 그것에 더해 의존성 주입 시스템, 보안 유틸, OpenAPI 스키마 생성 등이 있죠.

참고 | 기술적 세부 사항

ASGI는 Django 핵심 팀 멤버들이 개발 중인 새 "표준"이에요. 아직 "파이썬 표준"(PEP)은 아니지만, 그 방향으로 진행 중이에요.

그럼에도 이미 여러 도구에서 "표준"처럼 쓰이고 있어요. 이는 상호운용성을 크게 향상시킵니다. Uvicorn을 다른 ASGI 서버(Daphne, Hypercorn 같은)로 바꾸거나, python-socketio 같은 ASGI 호환 도구를 추가할 수 있으니까요.

팁 | FastAPI가 쓰는 용도

모든 핵심 웹 부분을 처리하고 그 위에 기능을 더하는 것.

FastAPI 클래스 자체가 Starlette 클래스에서 직접 상속받아요.

그래서 Starlette으로 할 수 있는 건 무엇이든 FastAPI로 직접 할 수 있어요. 기본적으로 Starlette에 스테로이드를 올린 것이니까요.

Uvicorn

Uvicorn은 uvloop과 httptools 위에 만들어진 번개처럼 빠른 ASGI 서버예요.

웹 프레임워크가 아니라 서버예요. 예를 들어 경로로 라우팅하는 도구를 제공하지 않죠. 그건 Starlette(이나 FastAPI) 같은 프레임워크가 위에 제공할 일이에요.

Starlette와 FastAPI에서 권장하는 서버예요.

팁 | FastAPI가 추천하는 용도

FastAPI 어플리케이션을 실행하는 메인 웹 서버.

--workers 명령줄 옵션을 쓰면 비동기 멀티프로세스 서버를 가질 수도 있어요.

더 자세한 내용은 Deployment(배포) 섹션을 확인하세요.

벤치마크와 속도

Uvicorn, Starlette, FastAPI의 차이를 이해·비교·확인하려면 Benchmarks(벤치마크) 섹션을 확인하세요.

더 알아보기 (Learn more)