tokio-rs에서 나온 Rust 풀스택 웹 프레임워크 Topcoat입니다.
마크업은 서버에서 렌더하고, 상호작용은 wasm 없이 $(...)로 JS에 번역하는 쪽을 택했습니다.
•
batteries-included, MIT
•
Early-stage / experimental — 브레이킹 체인지 예상
•
별도 API 계층 보일러플레이트 최소화 (컴포넌트가 async로 DB 직접 조회)
•
클라이언트 빌드 단계·wasm 번들 없음
•
Tailwind·UI 컴포넌트(복사형)·세션·쿠키·에셋 파이프라인 내장
원인 파악을 해봅시다 :)
요즘 풀스택의 흔한 고통:
서버 렌더 + REST/GraphQL + 프론트 번들러 + 상태 라이브러리
→ "같은 화면"을 위해 타입이 두 번, 엔드포인트가 한 겹
Plain Text
복사
Topcoat가 겨냥하는 답:
서버 HTML이 기본
필요한 순간만 브라우저에서 즉시 재실행 ($(...))
서버가 다시 그려야 하면 #[shard]로 HTML 교체
Plain Text
복사
즉 React/SPA를 Rust로 옮긴다기보다,
서버 컴포넌트 + 얇은 클라이언트 반응성에 가깝습니다.
여기서 우리가 꼭 알아가야할 핵심 개념!!: $(...) 이중 평가
$(...) 안의 식은:
1.
서버: 초기 렌더 때 타입 검사되는 일반 Rust로 평가
2.
브라우저: 같은 식이 JavaScript로 번역되어 왕복 없이 재실행
view! {
signal open = false;
<button @click=$(|_e| open.set(!open.get()))>"What is Topcoat?"</button>
<p :hidden=$(!open.get())>"A full-stack Rust framework."</p>
}
Rust
복사
서버가 꼭 필요한 갱신(검색 결과 등)은 #[shard]:
인자($(query) 등)가 바뀜
→ 서버가 해당 조각만 다시 렌더
→ HTML 스왑
Plain Text
복사
한 줄: 상호작용의 기본값은 "JS 앱"이 아니라 "Rust 식을 브라우저에서 다시 돌리는 것" 이다.
개발 DX에서 눈에 띄는 것들
1. view! — HTML + Rust 제어흐름
for / if, 조건부 속성을 템플릿 문법에 가깝게 씁니다.
topcoat fmt로 매크로 본문 포맷도 지원.
2. 모듈 기반 라우팅 (빌드 스텝 없이 추론)
app/posts/id.rs → /posts/{post_id}
Plain Text
복사
파일·모듈 구조가 곧 라우트 표가 됩니다.
3. UI는 shadcn 스타일 "복사해서 수정"
topcoat ui로 Tailwind 기반 컴포넌트를 프로젝트 안으로 복사.
라이브러리 버전 고정 싸움보다, 소유권 있는 수정이 목표입니다.
4. Node 없이 Tailwind
tailwind feature로 CSS를 에셋 파이프라인에 연결.
5. 요청 단위 편의 기능
기능 | 역할 |
Cx | 요청 컨텍스트 |
#[memoize] | 요청 단위 캐시·중복 제거 |
쿠키 | 서명/암호화 |
세션 | 로그인/로그아웃, 슬라이딩 만료, 토큰 회전 |
자주 하는 오해들입니다!
오해 1. "Rust니까 프론트엔드 빌드가 더 무거울 것"
이 스택의 세일즈 포인트는 오히려 클라이언트 번들/빌드 제거입니다.
(대신 서버 렌더·HTML 스왑 모델의 제약을 받아들입니다.)
오해 2. "Leptos/Dioxus/Yew랑 같은 wasm UI"
결이 다릅니다. Topcoat는 wasm UI 프레임워크라기보다
풀스택 서버 프레임워크 + 이중 언어 식에 가깝습니다.
오해 3. "지금 당장 프로덕션 표준이다"
README가 먼저 말합니다: experimental, expect breaking changes.
학습·프로토타입·tokio 생태계 실험으로 보는 게 맞습니다.
언제 후보로 두면 좋은가
✅ Rust 백엔드에 HTML UI를 붙이고 싶다
✅ API 계층 중복이 싫다
✅ wasm/프론트 툴체인 비용을 줄이고 싶다
❌ 복잡한 SPA 클라이언트 상태가 핵심인 제품
❌ 안정 API·장기 LTS가 당장 필요한 경우
Plain Text
복사
정리해봅시다!
1.
Topcoat는 Rust에서 서버 렌더 풀스택을 batteries-included로 묶으려는 시도다.
2.
핵심 트릭은 $(...)의 서버+브라우저 이중 평가와 #[shard] HTML 교체다.
3.
라우팅·Tailwind·세션·복사형 UI로 "프레임워크가 해주는 일"을 넓힌다.
4.
wasm/클라이언트 빌드를 안 쓰는 대신, 서버 중심 상호작용 모델을 전제한다.
5.
아직 실험 단계이니, 개념 학습과 작은 앱 spike에 쓰기 좋다.
