관련 검색을 해보니 2024년에도 꽤 많은 사람들이 여전히 Flask를 Python 웹 프레임워크로 추천하고 있는 것으로 나타났습니다. 그러나 내 생각에는 "Flask는 사라지고 있으며 FastAPI는 미래를 대표합니다." 이것이 제가 이 글을 쓰는 이유입니다. 토론에 참여하고 반론을 제시하는 모든 분을 환영합니다.
Flask는 Python 개발자의 마음 속에 중요한 위치를 차지하고 있습니다. 웹 개발자라면 아마도 Flask를 사용해 본 적이 있을 것입니다. 하지만 아마도 FastAPI는 사용해 본 적이 없을 것입니다.
다음 두 가지 증거가 있습니다.
이제 공식 Python 개발자 설문조사에서 웹 프레임워크 비율의 변화를 살펴보겠습니다.
2019년에는 FastAPI가 옵션으로 나열되지도 않았지만 2023년에는 그 점유율이 25%에 도달한 것이 분명합니다. (현재는 2023년까지의 데이터만 있습니다.)
이 비율 데이터는 기존 시스템을 포함하므로 Django와 Flask의 비율이 급격히 떨어지지는 않는다는 점에 유의해야 합니다. 그럼에도 불구하고 추세는 분명합니다.
우리 모두는 웹 프레임워크 분야가 거의 매년 새로운 프레임워크가 등장할 정도로 매우 다양하다는 것을 알고 있습니다. 이러한 프레임워크의 대부분은 수명이 짧지만 일부는 지속됩니다. FastAPI는 2018년 말에 탄생해 2019년 말부터 이름을 알리기 시작했습니다. 그렇다면 어떻게 2010년 말에 탄생한 Flask를 불과 5년 만에 인기 면에서 추월할 수 있었을까요? 다음으로, 더 나은 이해를 위해 Python 웹 프레임워크 및 관련 솔루션의 개발 역사를 타임라인에 따라 추적해 보겠습니다.
FastAPI의 저자는 Python 생태계 발전에 각별한 관심을 기울이는 개발자입니다. 확장 읽기 링크 2는 저자가 작성한 "대안, 영감 및 비교"(https://fastapi.tiangolo.com/alternatives/)로, FastAPI가 다양한 라이브러리에서 가져온 참고 자료나 영감을 자세히 설명합니다. 이 글의 개발 역사 부분에서도 이 글을 언급하고 있습니다. FastAPI의 등장 배경과 저자의 일부 디자인 컨셉이 담겨 있으니 원문을 읽어보시길 권합니다.
Flask는 Django와는 별개의 "마이크로" 프레임워크입니다. 소수의 핵심 기능만 유지하며, 분리하기 위해 다른 기능을 여러 라이브러리(예: Jinja2, Werkzeug 등)로 분할합니다. 이를 통해 개발자는 충분한 자유를 누리고 관련 기능을 위한 타사 플러그인을 쉽게 작성할 수 있습니다. 청사진, 컨텍스트, 경로, 신호 등을 나타내는 데코레이터와 같은 내부 디자인은 당시 상당히 발전했습니다. 포괄적인 문서와 결합되어 매우 초보자에게 친숙합니다.
Flask는 단순성 덕분에 API 구축에 매우 적합합니다. 그러나 Flask 자체에는 내장된 기능이 없기 때문에 전문적인 REST 프레임워크가 필요합니다. 이에 따라 Flask-restful, Flask-RESTPlus, Flask-api 등의 프레임워크가 속속 등장했습니다. 또한 REST 서비스에는 데이터 검증, 구문 분석 및 사양에 대한 요구 사항이 있어 Flask-apispec이 등장할 때까지 Marshmallow, Webargs 및 APISpec이 등장했습니다. 하지만 이 개발 과정 전반에 걸쳐 DRF에 필적하는 Flask REST Framework는 구현된 적이 없습니다.
이 단계에서는 Flask의 단점이 점차 부각되었습니다.
Flask의 본래 강점은 유연성과 미니멀리즘에 있지만 이는 내부적으로 많은 구성요소를 개발해야 한다는 의미이기도 합니다. 이를 위해서는 개발 및 유지를 위한 전담 개발자가 있는 대기업이나 매우 유능한 개인 개발자가 필요합니다. 그렇지 않으면 플러그인이 프로덕션 품질에 도달하기 어렵기 때문에 Flask용 타사 플러그인이 혼합되어 장기 유지 관리가 보장되지 않습니다. 앞서 언급했듯이 이러한 라이브러리 중 상당수는 이미 유지 관리가 중단되었습니다.
따라서 오늘날에도 Flask로 API 서비스를 구축하려면 다양한 구성 요소를 함께 결합해야 합니다. 즉시 업데이트되지 않은 일부 구성 요소의 경우 직접 문제를 해결해야 합니다. 퇴역 군인이라면 감당할 수 있겠지만, 초보자에게는 특히나 최신 사례와 개념을 적용하려는 경우 다소 어려운 작업입니다.
Python 3.5부터 asyncio가 미래 트렌드가 되었습니다. 그 결과, aiohttp, Starlette, sanic 등 asyncio를 기본적으로 지원하는 일부 웹 프레임워크가 등장했습니다.
이때 플라스크는 적응을 꺼려했습니다. 커뮤니티는 asyncio에 대한 지원을 추가하는 데 시간이 오래 걸렸고 Flask의 원래 작성자는 Rust 작성으로 전환하여 프로젝트를 두 명의 관리자의 손에 맡겼습니다(이제 한 명만 남았습니다).
apistar, molten과 같은 API 서비스 구축 프로젝트는 모두 FastAPI 탄생의 디자인 영감을 제공했습니다.
그래서 FastAPI가 탄생했습니다. 저자는 원래 좋은 해결책을 찾고 있었지만, 위의 상황들은 각각 나름대로의 문제나 한계를 갖고 있었습니다. 그래서 저자는 이 새로운 프레임워크를 만들었습니다.
기사의 핵심 부분입니다. FastAPI가 Flask를 대체할 수 있는 이유는 바로 다음과 같습니다.
API 개발 과정에서 데이터 형식 유효성 검사, 구문 분석, 직렬화는 일상적인 작업입니다. 수년에 걸쳐 다양한 솔루션이 등장했으며 현재는 Pydantic이 최고의 선택입니다:
from fastapi import FastAPI
from pydantic import BaseModel
class Item(BaseModel):
name: str
description: str | None = None
price: float
tax: float | None = None
app = FastAPI()
@app.post("/items/")
async def create_item(item: Item):
return item
얼핏 보면 이 코드는 ORM이나 데이터 클래스를 작성하는 방식처럼 보일 수 있지만 실제로는 Python의 기본 Type Hints 구문을 사용하여 필드 유형에 주석을 답니다. 예를 들어 위의 예에서는 /items/ 요청의 항목 스키마가 명확하게 정의되었으며 각 필드의 값 유형이 명시적입니다. 스키마 설명이나 하드 코딩을 사용하는 이전 방법과 비교할 때 이 접근 방식은 더 간결하고 Python 스타일에 더 부합하며 더 나은 IDE 지원을 제공합니다.
현재 Pydantic은 사용자 데이터 검증 분야를 장악하고 있습니다. FastAPI가 내장되어 있으므로 검증 프로세스가 크게 단순화되고 오류가 줄어듭니다. 그렇기 때문에 FastAPI 공식 웹사이트에서는 이 솔루션이 개발자의 오류를 최대 40%까지 줄일 수 있다고 언급하고 있습니다. Python과 같은 동적 언어의 경우 유형 검사에 mypy를 사용하지 않는다면 Pydantic을 적용하는 것이 필수적입니다.
또한 Pydantic 통합 덕분에 프로젝트에 ORM(예: SQLAlchemy)을 추가하는 것이 매우 쉬워졌습니다. 데이터 유효성 검사가 이미 완료되었으므로 요청을 통해 얻은 개체를 데이터베이스에 직접 전달할 수 있습니다. 반대로, 데이터베이스에서 검색된 객체를 직접 반환할 수도 있습니다.
반면 Flask는 이런 부분이 부족합니다.
Flask 시대에는 코드 실행이 단일 스레드 및 동기식이었습니다. 즉, 요청은 하나씩 처리해야 했고, 다른 요청은 이전 요청이 완료되기 전에 I/O 작업을 기다리는 데 시간을 낭비하게 되었습니다. 반면 Asyncio는 최적의 솔루션입니다. I/O 작업을 비동기식으로 만들 수 있으므로 작업이 완료될 때까지 기다리지 않고 작업 결과를 얻은 다음 다른 작업 요청을 처리할 수 있습니다.
FastAPI는 기본적으로 동시 및 비동기 코드를 지원합니다. 코드가 올바르게 작성된다면 최고의 효율성을 달성할 수 있습니다. 따라서 NodeJS 또는 Go와 유사한 효율성을 갖춘 현재 가장 빠른 Python 프레임워크로 간주됩니다. 속도와 성능이 핵심이라면 FastAPI는 의심할 여지 없이 최선의 선택입니다.
먼저 WSGI에 대해 언급하겠습니다. 전체 이름은 "Python 웹 서버 게이트웨이 인터페이스"이며 "PEP 3333"(https://peps.python.org/pep-3333/)에서 참조할 수 있습니다. 웹 애플리케이션과 서버 간의 상호 작용을 위해 특별히 작성된 Python 표준입니다. PHP나 Ruby를 사용해 본 적이 있다면 이해하기 더 쉬울 것입니다. Flask는 WSGI 제품군인 Werkzeug에 의존하므로 Flask는 ASGI가 아닌 이 오래된 WSGI 표준을 지원합니다.
WSGI의 문제점은 비동기성을 활용하여 성능과 효율성을 높일 수 없다는 것입니다. 그래서 Django 채널은 ASGI를 개척했습니다. 전체 이름은 "비동기 서버 게이트웨이 인터페이스"로, 반복적이고 거의 완전히 재설계된 표준입니다. 비동기식 서버/애플리케이션 인터페이스를 제공하고 HTTP, HTTP/2 및 WebSocket을 지원합니다. WSGI와 달리 ASGI에서는 각 애플리케이션이 여러 비동기 이벤트를 가질 수 있습니다. 또한 ASGI는 동기 및 비동기 애플리케이션을 모두 지원합니다. 기존 동기식 WSGI 웹 애플리케이션을 ASGI로 마이그레이션하거나 ASGI를 사용하여 새로운 비동기식 웹 애플리케이션을 구축할 수 있습니다.
결론을 내리기 전에 5가지 용어 설명을 추가해 보겠습니다.
과거에는 WSGI용 프로덕션 환경 솔루션이 주로 Nginx Gunicorn Flask(Django)였지만, 현재 ASGI용 프로덕션 환경 솔루션은 Nginx Uvicorn FastAPI입니다.
한 가지 더. FastAPI의 이름과 소개를 보면 API 서비스 구축을 위해 설계된 것이 분명합니다. 실제로 핵심 코드는 바로 그것과 같습니다. 완전히 자체 구현되는 전통적인 프레임워크라기보다는 다양한 프레임워크의 장점을 결합한 프레임워크에 가깝다고 할 수 있습니다. 빈 껍질에서 시작하여 필요하고 적합한 구성 요소를 조립합니다. 예를 들어 템플릿 엔진이 없습니다. 템플릿 렌더링이 필요한 웹 애플리케이션을 구축하기 위해 이를 사용해야 하는 경우 필요한 템플릿 엔진을 선택하고 결합할 수 있습니다. 물론 Starlette에 내장된 Jinja2를 사용할 수도 있습니다(예, Flask에도 내장되어 있습니다).
위에 언급된 FastAPI의 장점만으로는 Flask가 죽었다고 결론을 내리기에는 부족합니다. 그렇다면 나는 왜 이런 견해를 갖고 있는가? 이는 주로 개발자와 사용자 사이의 인기로 귀결됩니다.
여기서 '인기'는 다소 주관적입니다. 제가 생각할 수 있는 지표는 다음과 같습니다.
제 생각에는 이 모든 상황은 Flask의 전성기가 지나고 FastAPI가 떠오르는 스타임을 시사합니다.
마지막으로 Flask/FastAPI 배포에 이상적인 플랫폼인 Leapcell을 소개하겠습니다.
Leapcell은 최신 분산 애플리케이션을 위해 특별히 설계된 클라우드 컴퓨팅 플랫폼입니다. 종량제 가격 모델을 통해 유휴 비용이 발생하지 않으므로 사용자는 실제로 사용한 리소스에 대해서만 비용을 지불하면 됩니다.
WSGI/ASGI 애플리케이션을 위한 Leapcell의 고유한 장점:
문서에서 자세히 알아보세요!
Leapcell 트위터: https://x.com/LeapcellHQ
위 내용은 플라스크는 죽었는가? FastAPI는 미래인가?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
