GN⁺: FastUI: 파이썬으로 더 빠르고 좋은 웹 UI 만들기
(github.com/pydantic)- FastUI는 선언적인 파이썬 코드로 웹 애플리케이션 사용자 인터페이스를 구축하는 새로운 방법
- 사용자 인터페이스를 정의하는 Pydantic 모델과 TypeScript 인터페이스의 집합
- 파이썬 개발자라면 JavaScript나 npm을 사용하지 않고도 React로 반응형 웹앱을 구축 가능
- 프론트엔드 개발자는 매번 복사-붙여넣기를 하지 않고도 재사용 가능한 컴포넌트를 집중적으로 구축할 수 있음
- 모든 사용자에게는 백엔드가 전체 애플리케이션을 정의하고 프론트엔드는 사용자 인터페이스만 구현하는 진정한 관심사의 분리가 가능
- 다양한 컴포넌트 기본 제공 : 토큰 기반 인증, GitHub OAuth, Markdown, Text, Paragraph, Heading, Code, Button, Link, Navbar, Modal, ServerLoad, Image, Iframe, Video, Table, Pagination, ModelForm
실제 사용법
- FastUI는 네 가지로 구성됨:
-
fastui
PyPI 패키지: UI 컴포넌트를 위한 Pydantic 모델과 유틸리티 제공. FastAPI와 잘 작동하지만 FastAPI에 의존하지 않으며, 다른 파이썬 웹 프레임워크와도 사용 가능함. -
@pydantic/fastui
npm 패키지: 자체 컴포넌트를 구현하면서 FastUI의 기계장치와 타입을 재사용할 수 있게 해주는 React TypeScript 패키지임. -
@pydantic/fastui-bootstrap
npm 패키지: Bootstrap을 사용하여 모든 FastUI 컴포넌트를 구현/사용자 정의함. -
@pydantic/fastui-prebuilt
npm 패키지: npm 패키지를 설치하거나 무엇인가를 직접 빌드할 필요 없이 FastUI React 앱의 사전 빌드된 버전을 제공함. 파이썬 패키지는 이 앱을 제공하는 간단한 HTML 페이지를 제공함.
-
원칙 (긴 버전)
- FastUI는 RESTful 원칙의 구현체이지만, 일반적으로 이해되는 방식이 아닌 Roy Fielding의 박사 논문에서 정의된 원칙에 따름.
- RESTful 원칙에 따르면 프론트엔드는 구축하는 애플리케이션에 대해 알 필요가 없으며, 단지 인터페이스를 구성하는 데 필요한 모든 컴포넌트를 제공해야 함.
- 이 방식으로 애플리케이션을 구축하는 것은 여러 가저의 중요한 이점을 가짐:
- 새 기능을 구축하기 위해 한 곳에서만 코드를 작성해야 함.
- 프론트엔드와 백엔드의 배포를 완전히 분리할 수 있음.
- 오픈소스 컴포넌트 세트를 재사용할 수 있으며, 이는 컴포넌트가 사용될 맥락에 대해 알 필요가 없기 때문에 가능함.
- Pydantic, TypeScript, JSON 스키마를 사용하여 양쪽이 합의된 스키마로 통신하고 있음을 보장할 수 있음.
Python과 React를 넘어서
- 이 원칙은 Python과 React 애플리케이션에만 국한되지 않으며, 동일한 합의된 스키마와 인코딩을 사용하여 통신한다면, 스키마를 구현하는 모든 프론트엔드와 백엔드에서 사용할 수 있음.
GN⁺의 의견
- FastUI는 백엔드 개발자가 프론트엔드 개발 없이 애플리케이션을 확장할 수 있는 효율적인 방법을 제공함으로써 개발 프로세스를 간소화할 수 있는 잠재력을 가지고 있음.
- 이 기술은 프론트엔드와 백엔드 간의 역할 분담을 명확히 하여, 각각의 전문성을 최대한 활용할 수 있는 환경을 조성함.
- 현재 FastUI는 아직 진행 중인 프로젝트이므로, 실제 프로덕션 환경에서 사용하기 전에 안정성과 기능성을 면밀히 검토해야 함.
- FastUI를 도입할 때는 기존의 프론트엔드 개발 흐름과의 호환성, 컴포넌트의 재사용성 및 확장성, 그리고 프로젝트의 장기적인 유지보수 측면을 고려해야 함.
- 이 기술을 선택함으로써 얻을 수 있는 이점은 개발 시간의 단축과 백엔드 중심의 개발 흐름이지만, 반면에 프론트엔드의 유연성이 제한될 수 있으며, 커뮤니티의 지원과 자료가 상대적으로 부족할 수 있음.
Hacker News 의견
-
프레젠테이션 계층과 코드의 결합에 대한 의견
- 프레젠테이션 계층과 코드의 결합: 프레젠테이션 계층은 코드와 너무 밀접하게 연결되어서는 안 됨. 파이썬이 아닌 템플릿 언어가 적합하며, 다양한 언어로 템플릿을 렌더링할 수 있는 것이 더 좋음.
-
FastUI와 Streamlit을 사용한 앱 개발 경험
- FastUI와 Streamlit 사용: Streamlit으로 프로토타이핑을 진행했으나 때때로 불편함을 느낌. FastUI는 아직 미흡한 부분이 있지만, 경량 앱을 위해 사용하여 Streamlit보다 빠른 반응 속도를 경험함.
-
Django와 HTMX에 대한 의견
- Django와 HTMX: Django와 HTMX의 조합이 아름답고 빠르게 작동함. 프론트엔드로 렌더링된 코드만 보내고, 규모가 커질 때 DB 관리를 할 수 있음.
-
서버 측 이벤트 처리에 대한 내부 앱의 실용성
- 서버 측 이벤트 처리: 이 개념은 새롭지 않으며, React 기반의 Solara나 Vue 기반의 NiceGUI와 같은 다른 예시들이 있음. 내부 앱에 매우 실용적이지만, 모든 컨트롤에 서버 측에서 이벤트를 처리하는 데 약간의 지연이 있음을 받아들여야 함.
-
백엔드 서버를 필요로 하는 프론트엔드 프레임워크의 증가
- 프론트엔드 프레임워크의 복잡성: 많은 프론트엔드 프레임워크가 기본 HTML을 렌더링하기 위해 백엔드 서버를 실행해야 함. 이러한 프레임워크가 제공하는 기능이 그 복잡성을 정당화하는지 의문.
-
FastUI와 NiceGUI 경험 비교
- FastUI와 NiceGUI: NiceGUI는 박스에서 꺼내자마자 사용하기 좋은 경험을 제공함. FastUI는 주로 Pydantic 모델에 대한 폼 어댑터로 보임.
-
AI의 발전이 프로젝트 유스케이스에 미치는 영향
- AI와 프론트엔드 개발: 백엔드 개발자가 자신의 언어로 빠르게 UI를 생성할 수 있는 아이디어는 유효하지만, AI를 몇 시간 사용하여 기본 UI를 생성할 수 있어 이러한 프로젝트의 필요성이 약화될 수 있음.
-
Dart/Flutter를 사용한 사이드 프로젝트 개발 경험
- Dart/Flutter 사용: Dart/Flutter로 사이드 프로젝트를 작성함으로써 마찰을 최소화하고 덜 번거로움. 웹 앱을 작성해야 하고 Flutter가 적합하지 않다면 HTMX를 사용할 것임.
-
Java Server Faces와의 비교 및 서버 측 추상화의 한계
- Java Server Faces 경험: Java Server Faces와 유사함을 느낌. 프론트엔드 개발의 미묘함을 서버 측 추상화로 옮기려는 시도는 관리 UI와 같은 제한된 애플리케이션 세트에서만 작동할 것임.
-
서버와의 라운드트립이 사용자 인터페이스 구축에 적합한지에 대한 질문
- 서버와의 라운드트립: 클라이언트 상호작용마다 서버로의 왕복이 사용자 인터페이스를 구축하는 데 있어 언제나 좋은 아이디어인지에 대한 의문 제기.