Show HN: Pylon Sync, 에이전트 중심의 풀스택 실시간 프레임워크

TypeScript에서 데이터를 정의합니다.

각 엔티티와 필드를 한 번만 작성하세요. Pylon이 테이블을 만들고, 마이그레이션을 실행하며, 클라이언트 타입을 작성해 줍니다.

• TypeScript 엔티티
• 저장 시 마이그레이션
• 생성된 클라이언트 타입

하나의 스키마를 작성하면 됩니다. 동일한 서버가 데이터를 저장하고, 권한을 확인하며, 업데이트를 전송하고, 코드를 실행하며, 페이지를 렌더링합니다. 이 모든 것에 대해 두 번째 서비스를 추가할 필요가 없습니다.

각 엔티티와 필드를 한 번만 작성하세요. Pylon이 테이블을 만들고, 마이그레이션을 실행하며, 클라이언트 타입을 작성해 줍니다.

db.useQuery("Order")

모든 읽기 작업과 모든 쓰기 작업은 동일한 규칙을 거칩니다. 규칙이 없는 작업은 거부됩니다.

앱이 업로드를 서명합니다. 파일은 개발 환경에서는 로컬 디스크에, 프로덕션 환경에서는 S3와 호환되는 버킷에 저장됩니다.

커서, 타이핑 신호, 그리고 누가 온라인인지 여부는 별도의 채널을 통해 전송됩니다. 이 중 어느 것도 테이블에 기록되지 않습니다.

랭킹 결과 및 페싯 카운트가 있는 전체 텍스트 쿼리를 실행합니다. 인덱스는 쓰기 작업과 동일한 트랜잭션으로 업데이트됩니다.

단일 SQLite 파일로 시작할 수 있습니다. Postgres로 이동하려면 DATABASE_URL을 해당 주소로 지정하기만 하면 됩니다. 스키마, 규칙, 클라이언트 코드는 변경되지 않습니다.

쿼리, 뮤테이션 또는 액션을 작성합니다. Pylon이 입력을 확인하고 클라이언트에게 호출할 타입이 지정된 함수를 제공합니다.

서버는 조인이나 총합을 읽은 행을 기록합니다. 해당 행 중 하나가 변경될 때만 쿼리를 다시 실행합니다.

이메일, 파일 처리 및 총합 계산 작업을 대기열에 넣어 사용자가 답장한 후에 실행되도록 할 수 있습니다. 한 번 또는 반복적으로 작업을 예약할 수 있습니다.

각 단계는 완료됨에 따라 저장됩니다. 작업은 이벤트가 발생하기를 기다리며 며칠 동안 대기할 수 있고, 배포나 충돌 후에도 계속 진행될 수 있습니다. 완료된 단계는 두 번 실행되지 않습니다.

Studio Studio에서 테이블을 읽고, 실시간 쿼리를 관찰하고, 로그를 추적하며, 디버깅하는 환경에 대해 뮤테이션을 실행할 수 있습니다.

규칙, 명령, 타입, 데이터, 그리고 로그가 하나의 워크플로우에 머무릅니다. 에이전트는 도구를 변경하지 않고도 앱을 생성하고, 실행하고, 검사하고, 배포할 수 있습니다.

새로운 앱에는 AGENTS.md와 Pylon 스킬이 포함됩니다. 에이전트는 코드를 수정하기 전에 프로젝트 규칙을 읽습니다.

스킬 AGENTS.md를 읽어보세요.

.agents/skills/pylon/SKILL.md

app.ts

하나의 터미널에서 npm create, pylon dev, 그리고 pylon deploy를 실행하세요.

클라우드 배포 보기: npm create @pylonsync/pylon

pylon dev

pylon deploy

생성된 클라이언트는 스키마 드리프트(schema drift), 누락된 필드, 그리고 유효하지 않은 인수를 컴파일 오류로 변환합니다.

서버 함수 보기: db.useQuery("Order")

Property "owner" does not exist

Build stopped before deploy

에이전트는 로컬 서버가 실행되는 동안 /studio에서 테이블, 라이브 쿼리, 로그를 검사할 수 있습니다.

Studio 보기: /studio/tables

/studio/live-queries

/studio/logs

엔티티와 그 접근 정책을 선언하세요. Pylon은 테이블, REST 및 실시간 API, 행 수준 검사(row-level checks), 그리고 타입이 지정된 React 클라이언트를 생성합니다. 이를 통해 리졸버(resolvers), ORM 계층(ORM layer), 그리고 별도의 백엔드 서비스가 스택에서 제외됩니다.

// 하나의 엔티티 → 동기화된 테이블 + 타입이 지정된 클라이언트 const Order = entity("Order", { customer: field.string(), total: field.float(), paid: field.boolean().default(false),}); // 접근 규칙은 스키마 옆에. policy({ entity: "Order", allowRead: "auth.userId != null", allowInsert: "auth.userId == data.ownerId",}); // React 측면: 라이브, 타입 지정, fetch 불필요 const { data } = db.useQuery("Order");

레포지토리 푸시와 CLI 릴리스는 동일한 빌드, 프리뷰(preview), 그리고 프로덕션 경로를 사용합니다.

GitHub App을 한 번 설치하거나 CI에서 CLI를 사용하세요.

각 풀 리퀘스트마다 격리된 프리뷰 환경이 제공됩니다.

Pylon은 커트오버(cutover) 전에 앱을 검증하고 스키마를 적용합니다.

릴리스는 동일한 런타임으로 프로덕션에 이동합니다.

하나의 릴리스 경로

프리뷰 환경은 병합 후 사라집니다. 프로덕션은 릴리스 기록과 로그를 유지합니다.

모든 앱은 글로벌 엣지 네트워크(edge network) 뒤에 위치합니다. 사전 프로비저닝이나 좌석당 가격 책정 없이, 동일한 대시보드에서 머신 크기 조정, 복제본 및 리전 추가, 또는 스토리지 확장이 가능합니다.

Cloudflare의 엣지는 추가 구성 없이 전 세계적으로 CDN 캐싱, TLS, 그리고 DDoS 보호를 제공합니다.

RAM을 최대 64GB까지 추가하고, 성능 CPU를 선택하며, 재배포(redeploying) 없이 볼륨을 확장할 수 있습니다.

리전별 최대 32개의 로드 밸런싱 복제본을 실행할 수 있습니다.

미국, 유럽, 아시아 태평양, 남미 리전에 배포할 수 있습니다.

앱이 공간이 필요할 때 스토리지도 실시간으로 늘어납니다.

기본적으로 SQLite가 번들되어 있으며, 함께 위치한 관리형 Postgres는 비공개 베타입니다.

유휴 상태일 때는 0까지 축소하거나 프로젝트를 항상 따뜻하게 유지할 수 있습니다.

자체 도메인을 연결하고 Pylon이 TLS 처리를 담당합니다.

대시보드에서 조직(org) 수준의 SSO를 구성할 수 있습니다.

활동 로그, 원클릭 볼륨 복원 기능을 제공합니다.

SQLite가 기본입니다. 파일 하나만 사용하며 설정이 필요 없습니다. DATABASE_URL을 Postgres 연결 문자열로 설정하면 동일한 스키마와 애플리케이션 코드를 Postgres에서 사용할 수 있습니다. Cloud 환경에서는 번들된 SQLite가 기본값이며, 함께 위치한 관리형 Postgres는 비공개 베타입니다.

아닙니다. 런타임은 단일 오픈 소스 바이너리입니다. 이를 자체 컴퓨터나 컨테이너 플랫폼에 SQLite용 볼륨과 함께 실행하거나, 자체 Postgres 데이터베이스를 사용할 수 있습니다. Cloud는 필수 요구 사항이 아닌 관리형 옵션이며, 동일한 바이너리를 실행합니다.

스키마는 TypeScript로 작성됩니다. 개발 중에는 Pylon이 이를 감지(diff)하고 저장 시 변경 사항을 적용하여 테이블이 파일 구조를 따르도록 합니다. 배포 시에는 트래픽 전환 전에 릴리스의 일부로 스키마가 적용됩니다.

동일한 런타임 내에서 두 가지 방식으로 접근할 수 있습니다. GitHub App을 설치하고 기본 브랜치에 푸시하면 배포되고, 풀 리퀘스트(pull request)를 통해 미리보기 환경을 얻을 수 있습니다. 또는 수동 릴리스가 필요할 때 자신의 컴퓨터나 CI에서 pylon deploy를 실행할 수 있습니다.

서버 측 렌더링이 가능한 타입스크립트 React 클라이언트와 모바일을 위한 Swift SDK를 제공합니다. 모든 엔티티는 REST 및 실시간 API도 갖추고 있어, HTTP 또는 WebSocket 통신이 가능한 모든 것이 동일한 정책을 준수하며 읽기/쓰기가 가능합니다.

매직 링크 이메일, 25개 이상의 OAuth 공급자, 범용 OIDC 디스커버리, 게스트 세션 및 API 키를 지원합니다. 호출자가 어떤 방식으로 로그인했든, 정책은 동일한 auth.userId를 읽기 때문에 접근 규칙이 공급자별로 변경되지 않습니다.

예. ctx.scheduler.runAfter, runAt, 그리고 취소(cancel) 스케줄은 후속 작업을 추적합니다. 지연 및 재시도는 앱의 나머지 부분과 동일한 프로세스에서 실행됩니다. 별도의 큐나 워커를 배포할 필요가 없습니다.

이는 SQLite 파일이거나 일반적인 Postgres 데이터베이스이며, 그 사이에 독점적인 저장 계층은 없습니다. 덤프를 받아 어떤 클라이언트에서도 열 수 있습니다. 이 과정에서 재작성하는 것은 데이터가 아니라 SDK 호출 부분입니다.