Hacker News 의견

• 지난 1년 동안 FastAPI로 대규모 백엔드 프로젝트를 개발해왔음. 공식 튜토리얼 스타일대로 시작했지만, 모든 CRUD를 하나 파일에 넣으라는 FastAPI 공식 템플릿과 의존성 관리 방식에서 불편함을 느꼈음. SQLModel을 사용하면서는 다형성 모델 미지원 등 여러 한계가 있었고, 커뮤니티에서 개선 PR을 내도 몇 달 동안 리뷰조차 안 되는 등 유지 관리 여부가 의심스러웠음. 문서도 실제 사용할 만한 레퍼런스가 부족해 결국 소스 코드까지 뒤져야만 했음. 빠르게 CRUD 만들 때는 괜찮지만, 복잡한 시스템을 만들기엔 프레임워크 위에 프레임워크를 하나 더 얹는 꼴이라 추천하지 않을 생각임. 내일부터는 Litestar로 마이그레이션할 계획임
  • FastAPI의 실전적인 대형 앱 사례에 대해 공부하려면 polarsource/polar 레포의 서버 코드를 참고하는 게 도움이 될 것 같음. 인증, 테스트 등 실제 스케일아웃 사례가 잘 모여 있으니 이 레포의 구현 방식을 따라가며 배워보려 함
  • API 중심 앱 설계에 입문하는 중인데, 이 글에서 생각지 못한 아키텍처와 도구 포인트를 많이 배웠음. 나도 Litestar를 써볼 생각임. 유용한 의견과 글에 감사함
  • FastAPI 공식 튜토리얼에 SQLModel이 과하게 강조되어 있다는 점은 동의하지 않음. 첫 화면에서는 SQLModel 언급도 없고, 관계형 데이터베이스 연결 설명 페이지에서만 다룰 뿐임. 튜토리얼에 특정 ORM을 쓰는 건 자연스러운 선택이고, SQLModel이 맞지 않으면 사용자가 다른 옵션을 골라야 한다고 생각함. 나 역시 튜토리얼 보고 plain SQLAlchemy로 결정했음
  • Litestar 문서를 읽어보니 이벤트 시스템도 내장되어 있음. FastAPI에서 몇 주를 들여 따로 만들어 썼던 기능인데, Litestar에는 처음부터 준비되어 있음
  • Litestar 역시 일부 한계가 있지 않을까라는 생각이 듦. 커뮤니티·문서·논의가 FastAPI보다 적은데도, 복잡한 애플리케이션에 더 적합하다고 생각하는지 의견이 궁금함
• Litestar는 API 백엔드 구축에 매우 뛰어남. 직접 사용하고 있고 강하게 추천할 정도임. Advanced Alchemy도 점점 좋아지고 있음. 구식의 서버 템플릿 렌더링 사이트도 Litestar로 충분히 만들 수 있고, HTMX용 플러그인도 내장되어 있음. 다만 API 엔드포인트 설계를 위한 패턴들이 폼 검증·리디렉션 등 전통적 서버 렌더 엔드포인트에서는 조금 어색한 부분이 있음. Litestar 자체적으로 진짜 의미의 폼 처리 기능이 없어 개별 폼 필드별 에러를 제대로 다루기 힘듦. @post("/route", exception_handlers={...})를 활용한 패턴이 어색하게 느껴짐. 앞으로 좀 더 좋은 내장 툴/개발 경험 개선이 기대됨
  • Litestar를 직접 써본 적은 없지만, 폼 관련 처리를 모두 해결하는 자체 데코레이터 @postform 같은 걸 만들면 되지 않을까 싶음
• Litestar는 파이썬 웹 프레임워크임. 궁금한 사람들을 위해 먼저 정보 공유함
  • 덕분에 시간을 아꼈다는 사람도 있었음
• 1년 넘게 Litestar로 JSON과 템플릿 기반 HTML을 함께 서비스 중임. 속도가 FastAPI보다 빠르고, 경량이면서도 인증·세션 등 필수 기능이 잘 갖춰진 Python async 프레임워크임. msgspec 및 Controller 기반 중첩 라우팅 지원 등이 특히 마음에 들었음. 강하게 추천함
  • 나도 새 프로젝트에서 FastAPI에서 Litestar로 전환했는데, 후회 없이 잘 사용 중임. Litestar의 기본 베이스만으로도 확실한 완성도와 신뢰감을 얻었음
  • FastAPI를 몇 년간 써왔지만 Litestar도 꼭 한번 써볼 만한 가치가 있어 보임
• FastAPI로 몇 년 동안 애플리케이션을 개발하며 비슷한 불만을 느꼈음. 실전 개발과 진짜 API 품질 측정에서 튜토리얼·샘플 위주 FastAPI 문서는 현실과 동떨어져 있다는 평이 많음. 이 점이 의외로 자주 지적되는 게 놀라움
  • 최근 Python 프레임워크 문서들이 모두 자바스크립트 라이브러리처럼 '튜토리얼+수다스런 블로그' 같은 느낌으로, API의 상세와 파라미터 설명 등 레퍼런스가 부족한 게 큰 실망임. 진짜 API 레퍼런스 문서가 필요함. 메서드 별 상세 옵션, 파라미터 정리, 그리고 주석 문장 대신 옵션을 제대로 표기해줬으면 함. 소스 코드까지 뒤져야만 속 시원한 정보를 찾을 수 있는 현재 방식이 매우 불편함
• FastAPI도 쓸 만하지만, 복잡한 앱을 만들기에는 한계가 적지 않음. 프레임워크 설계가 15년 전 JavaEE가 이미 다 겪었던 이슈들을 Python 마이크로프레임워크 생태계가 뒤늦게 재발견하는 것 같아 놀라울 때가 있음. Litestar는 꽤 괜찮아 보임. 스트리밍 오류 케이스 처리 노하우도 궁금함
• FastAPI가 인기이긴 하지만, 작은 프로젝트엔 starlette만으로도 아주 만족스러웠음. 모든 기능이 있는 건 아니지만 단순한 서비스엔 부족함이 없음. Litestar는 FastAPI나 Django에 가까운 범위로 보임
  • 최근 API들은 starlette 단독으로만 만들고 있는데, 클린하고 간결하고 공식 문서도 잘 되어 있어서 프로젝트 크기와 무관하게 확장성이 좋음
• Litestar에 늘 관심은 있었으나 아직 직접 써보진 않았음. FastAPI를 꽤 오래 사용했고, FastAPI로 대규모 코드베이스 관리가 어렵다는 평은 다소 과장된 것 같음. 라우팅을 여러 파일로 나눠 import해서 빅 트리 구조로 만들면 충분히 확장 가능했음. 다만 대규모 구조화에 대한 공식 문서 가이드가 부족한 건 동의함. best practice와 개인 취향대로 파일을 모듈별 분할하면 충분히 확장성이 확보됐음. FastAPI에서 SQLAlchemy를 직접 쓰진 않았는데, 그 부분에서 느끼는 고통은 공감하지는 못할 듯함
• 실전 앱 개발에서 중요한 포인트를 잘 짚은 글임. Litestar 설계가 정말 매력적임. 리포지터리 패턴에 대한 견해 역시 기대 중임. 독립 포스트로 풀어주면 좋겠음
• 글이 꽤 멋졌음. SQLAlchemy는 다루기 까다롭고 상태가 복잡해 놀라운 부분이 많지만, 어떤 사람들은 아예 사용하지 않고 개발하는지 궁금함
  • 최근 개인 프로젝트에서 peewee로 개발해봤는데, 많은 부가 기능은 없지만 맡은 일은 잘 해냄
  • 전통적인 SQLAlchemy와 Litestar의 Advanced Alchemy(역시 SQLAlchemy가 기반이지만)는 차이가 큼. 이전에는 pure SQL 혹은 SQLAlchemy를 썼는데, django ninja에서 Litestar로 옮기면서 SQLAlchemy 사용을 아예 줄여가는 중임
  • 이 프로젝트에서 가장 흥미로운 점은 SqlAlchemy의 단점을 어느 정도 보완해주는 것 같음. DB가 필요한 프로젝트를 시작할 때마다 결국 Django로 돌아가게 됨. SqlAlchemy와 Alembic은 굳이 감내하고 싶지 않은 고통임
  • SQLAlchemy 사용하는 가장 현실적인 방법은 모델과 Alembic으로 스키마 정의, 마이그레이션만 하고, 실제 쿼리나 트랜잭션 관리는 직접 SQL로 하는 쪽이라는 생각임. ORM으로 쿼리를 재구성하는 시간 소모가 너무 큼
  • 주로 asyncpg를 많이 사용함