Hyperflask – 풀스택 Flask 및 Htmx 프레임워크

(hyperflask.dev)

10P by GN⁺ 2일전 | ★ favorite | 댓글 1개

Flask 기반의 백엔드 중심 웹 프레임워크로, 복잡한 프론트엔드 관리 없이 빠르고 단순한 상태 관리를 제공
HTMX와 결합된 컴포넌트 아키텍처를 도입해, 서버 기반의 인터랙티브 UI 구성이 가능
파일 기반 라우팅, esbuild + TailwindCSS 자산 파이프라인, 자동화된 배포 환경 등 현대적 웹 스택 통합
이메일 전송(MJML), 백그라운드 작업, SSE 기반 푸시, 번역, 인증 등 다양한 기본 기능 내장
컨테이너 기반의 개발·배포 환경 표준화와 VS Code 통합으로, 손쉬운 설정과 클라우드 배포 지원

개요: Flask 기반의 백엔드 중심 웹앱 프레임워크

Hyperflask는 Flask 위에서 동작하는 Python 웹 프레임워크로, 백엔드 주도형 설계를 지향함
프론트엔드 상태 관리 복잡성을 줄이고 서버 중심의 간결한 아키텍처를 제공함
HTMX, TailwindCSS, esbuild 등 현대 웹 기술을 기본 탑재
HTMX 통합을 통해 페이지 전체 리로드 없이 실시간 상호작용을 구현할 수 있음
컴포넌트 아키텍처로 백엔드 및 프론트엔드 컴포넌트를 재사용 가능
- Flask 환경에 컴포넌트 중심 구조를 도입해, 프론트엔드와 백엔드 컴포넌트를 Jinja 템플릿에서 직접 사용 가능
- HTMX와 결합된 서버 백엔드형 컴포넌트 제작이 가능하며, React나 웹 컴포넌트와도 자연스럽게 통합됨
- 코드 재사용성과 유지보수성을 높여 대규모 앱 개발에도 적합한 구조 제공
파일 기반 및 앱 기반 라우팅 지원
- Python 코드와 Jinja 템플릿을 결합한 신규 .jpy 파일 포맷 사용
- Astro의 페이지 시스템에서 영감을 받아, 라우트 정의와 UI 구성을 한 곳에서 관리 가능
- 이를 통해 라우팅 설정이 단순화되고, 새로운 페이지 추가가 직관적임
오픈 에코시스템
- Hyperflask는 자체 코드베이스가 작으며, 여러 Flask 확장 기능을 유기적으로 결합해 구성됨
- 각 확장 기능은 독립 프로젝트로 관리되어 자유로운 선택·조합이 가능
- 모든 프로젝트는 GitHub의 Hyperflask 조직에서 공개되어 있으며, 사용자 맞춤형 프레임워크 구성을 장려함
“Batteries Included”
- MJML 이메일 발송, dramatiq 백그라운드 작업, SSE 기반 실시간 푸시, gettext 기반 번역(i18n)
- 인증 및 세션 관리, 이미지 최적화 및 스트리밍, 정적 콘텐츠 생성 등
- 별도 설정 없이 즉시 사용 가능한 프로덕션 수준 기능 세트 제공
- SQL 중심 ORM(sqlorm), SQLite에 최적화
환경 설정 및 배포
- 컨테이너 기반 개발/운영 환경을 표준화해, 환경 설정 문제를 최소화함
- VS Code와의 긴밀한 통합으로 로컬 개발과 디버깅이 용이함
- VPS나 주요 클라우드 서비스로 손쉬운 배포 지원

요약

Hyperflask는 Flask 생태계를 확장해 현대적인 풀스택 Python 웹 개발 경험을 제공하는 차세대 프레임워크
HTMX와 컴포넌트 시스템, 파일 기반 라우팅, 컨테이너 표준화된 개발환경을 통해 최소 설정으로 최대 생산성을 구현

▲

GN⁺ 2일전 [-]

Hacker News 의견

hyperflask 제작자로서, 오랜 시간 준비한 프로젝트를 드디어 공개하게 되어 기쁜 마음임
자세한 발표 글은 여기에서 확인 가능함
다양한 피드백을 듣고 싶음
- 이런 방식이 백엔드에 종속되지 않는, 라이브러리 형태였다면 더 좋았을 것 같음
  이미 Django 프로젝트가 백만 라인 이상이라 쉽게 변경할 수 없는데, Django 앱에 손쉽게 적용할 방법이 있는지 궁금함
- htmx 개발자로서, 이 프로젝트가 정말 멋져 보임
- 동료가 flask/htmx/sqlalchemy 조합으로 내부 앱을 만들어서 좋은 결과를 얻었으나, 오픈소스 승인을 받지 못했었음
  그래서 hyperflask의 새로운 시도를 기대하는 중임
- 왜 ORM으로 sqlorm을 선택한 것인지 궁금함
  오랫동안 Python 개발에서 떨어져 있었지만, SQLAlchemy를 모두 쓰는 줄 알았고 sqlorm에 대해서는 생소함
- 새로운 프레임워크가 HTMX를 받아들인 모습이 인상적임
  HTMX가 JS, React를 대체할 다양한 신경향을 자극하고 있음
  Python과 Flask 조합을 좋아하는 사람도 많을 것이고, 서버 사이드 HTMX에선 컴포넌트가 핵심임
  그리고 홈페이지가 FastHTML보다 눈이 편한 것도 장점임
  harcstack.org와 비교하자면
```
Language: Python vs. Raku  
Web framework: Flask vs. Cro  
ORM: ?? vs. Red  
Components: 둘 다  
HTML: 템플릿 vs. 함수형  
CSS: DaisyUI/Tailwind/Bootstrap vs. Pico  
```
  이런 선택지 덕분에 훨씬 넓은 유저층을 끌어들일 수 있을 것 같음
  비교 대상인 HARC stack은 엘름 언어의 서버사이드 버전처럼 HTML을 함수형으로 다루거나, Tailwind의 비정규화에 알레르기가 있는 소수에게 매력적으로 다가갈 듯함
htmx로 웹앱을 개발하다 '막다른 길'임을 느꼈음
주된 문제는 프론트엔드 애플리케이션 상태가 URL에 저장되어야 한다는 점임
다양한 영역, 위젯, 팝업 등 각자 로컬 상태와 내비게이션이 필요한 현대적 UI에서는, 모든 상태를 하나의 글로벌 url에 담기가 굉장히 어려움
필요에 따라 상태를 url에 넣지 않게 하는 것도 더 힘든 설계임
이런 문제는 React나 Vue처럼 자체 상태 저장소를 제공하는 프레임워크에서는 쉽게 해결됨
phpBB 포럼처럼 구성하면 괜찮겠지만, 요즘 사용자는 더 발전된 경험을 기대함
- 상태를 url에만 보관해야 할 필요는 없음
  서버 저장소, 세션, localstorage, 쿠키 등 다양한 방식이 있음
  예를 들어 사용자 앱 레이아웃 커스터마이징은 url이 필요 없지만, 검색 결과처럼 공유 기능이 필요할 때는 반드시 url에 검색 조건이 있어야 함
  무엇을 달성해야 하는지 고민이 필요함
  그리고 '현대적 UI'라는 이름으로 많은 위젯, 팝업을 한 화면/한 url에 모두 넣는 것은 오히려 지나친 복잡도가 될 수 있음
  종종 React/Vue가 제공하는 상태 저장은 이미 서버에서 다 관리할 수 있는 것의 중복임
- 하이퍼미디어 방식도 충분히 복잡한 UI를 다룰 수 있음
  모든 것을 url에 고집할 필요 없음
  세션과 쿠키, 탭 아이디 등을 써서 상태를 탭마다 공유/격리할 수 있고, 백엔드 DB에서 상태를 조회하면 됨
  하이퍼미디어는 실시간/멀티플레이어 환경에서도 뛰어남
  오히려 HTMX의 단점은 상태를 백엔드에 더 많이 두지 않는 것이고, 차라리 더 과감하게 갔으면 싶음
- 이건 단순히 내 사용 사례와 맞지 않는다고 생각함
  React/Vue가 '쉽다'고 생각하는 것도 재미있음
- React나 Vue로도 사용자가 기대하는 모든 문제를 해결하지 못한다고 생각함
- 복잡도가 아주 높은 경우가 아니면, 실제로 나는 htmx(unpoly, alpinejs, localstorage 조합)로 대부분의 케이스를 무난하게 처리하고 있음
hyperflask에서 흥미로운 콘셉트를 발견함
- 컴포넌트 구현: 링크
- 뷰와 컨트롤러를 하나 파일로 묶는 방식: 링크
  그런데 컴포넌트는 사실상 내부적으로 일반 매크로에 불과한데, 차라리 매크로를 직접 쓰는 게 낫지 않나 생각듦
  Flask 선택도 궁금함
  예전에 /dev/push라는 비슷한 접근을 시도하다 FastAPI + Jinja2 + Alpine.js + HTMX 조합으로 옮겼음
  FastAPI도 API 전용이 아님을 깨닫고, 비동기 지원이 필요해서 선택한 것임
  Flask도 좋아하지만, 한계가 있다고 느낀 적 있음
- 뷰와 컨트롤러를 하나 파일로 묶는 방식이 예전 PHP 개발을 떠올리게 함
  프로젝트 규모에 따라선 개발이 확실히 단순해져서 장점이었음
- FastAPI + HTMX 조합 역시 매우 효과적이라고 생각함
Django에서 경험상, admin scaffolding 기능 덕분에 진단 및 고객지원용 UI를 직접 만들 필요가 거의 없었음
다른 프레임워크 기반 프로젝트에선 이런 기능을 직접 구현하게 되고, 결과물이 Django만큼 만족스럽지 못한 경우가 많았음
Hyperflask처럼 매력적으로 보이는 프레임워크들이 많지만, Django의 admin 프레임워크를 포기하는 것은 그만큼 큰 대가임
실제로 Django admin의 대안이나 대체 패턴을 찾은 사람들이 있는지 궁금함
- 같은 얘기라고 느꼈음
  FastAPI로 넘어가면서 Django에서 가장 그리웠던 점은 프로젝트를 구성하는 다양한 앱이었음
  마이그레이션, 정적 파일, 템플릿 등 기능별로 묶여 있는 구조가 얼마나 편했는지 나중에 깨달았음
- 나는 대부분 Supabase를 사용함
  Supabase UI로 관리자를 교육해서 급한 관리는 맡기기도 함
  또는 가능하다면 Airtable을 백엔드로 사용하기도 함
  하지만 대부분 Django admin이 너무 그리워지고, Django+HTMX 조합이 항상 유혹적으로 느껴졌음
- Flask-Admin도 있지만 Django Admin보다는 훨씬 단순함
  이런 문제를 앞으로 해결하고 싶음
여러 프레임워크와 함께 HTMX를 써본 결과, Go + Templ + HTMX 조합이 다재다능함과 단순함을 잘 결합했다고 봄
- 내 경험상 Go가 너무 장황해서, 오히려 Go+Templ+HTMX 조합에서 Flask + Jinja + HTMX로 옮기려고 고민 중임
  Go의 템플릿 정의 방식이 번거로움을 느낌
- 다음에 꼭 시도해보고 싶은 조합이 FastAPI + Jinja2 + HTMX임
  지금은 이 스택을 쓰고 있음
hyperflask가 Flask와 htmx의 철학과 어긋난 느낌임
추상화 계층이 너무 많고, htmx와의 통합 포인트도 별로 안 보임
FastHTML처럼 htmx가 내장된 방식을 기대했음
- FastHTML 정말 재미있게 쓰고 있음
프로젝트마다 starfield 데모(별빛 효과)가 나오면, 항상 속도 조절 기능과 마우스 커서를 따라가는 효과를 기대하게 됨
다음 Hyperflask 버전에서 추가됐으면 하는 바람임
프로젝트 자체는 훌륭하고, Htmx를 좋아하지만, 최근엔 Datastar도 눈여겨보고 있음
- 콘솔에서 아래 코드 실행하면 속도 조절 등 다양한 효과를 줄 수 있음
```
new WarpSpeed("warpdrive", {
  "speed": 20,
  "speedAdjFactor": 0.03,
  "density": 2,
  "shape": "circle",
  "warpEffect": true,
  "warpEffectLength": 5,
  "depthFade": true,
  "starSize": 3,
  "backgroundColor": "hsl(224,15%,14%)", 
  "starColor": "#FFFFFF"
});
```
- 혹시 이런 기능을 말하는 것인지 궁금함
- nova.app이 지금까지 본 것 중 최고임
HTMX 기반으로 완전한 Fullstack Async 경험을 원하면 Litestar도 참고할 만함
처음 봤을 때, Python 컨트롤러 파일에 HTML 템플릿을 직접 덧붙이는 구조가 왜 필요한지 이해가 어려웠음
단순 렌더 함수 하나 생략하려고 복잡해진 느낌임
내가 놓친 포인트가 무엇인지 궁금함
- 이 방식은 htmx가 중요하게 여기는 Locality of Behavior 원칙과 일맥상통함
  JavaScript 진영의 Astro Pages에서 영감을 얻음
  실제로 개발자 경험도 좋았음
  - Locality of Behaviour에 대한 설명
  - Astro Pages 안내
많은 사람들이 Flask의 한계를 이야기하고 '왜 FastAPI가 아니냐'고 하지만, 개인적으로 Litestar가 최고의 대안이라고 생각함
Litestar는 htmx 지원을 기본 제공함
자세한 정보는 여기에서 볼 수 있음

답변달기