앱으로 탄생한 실제 백엔드
데이터베이스, 로그인, 파일, 기능, 비밀, 이메일 — 모든 Kliv 앱은 이 모든 것에서 시작되며, 빌드할 때 AI에 의해 생성되고 관리됩니다. 프로비저닝할 것도, 연결할 것도, 동기화할 것도 없습니다.
클라우드 백엔드
연결하는 백엔드 서비스가 아님
대부분의 AI 빌더는 프런트엔드를 생성하고 체크리스트를 제공합니다. 여기에서 데이터베이스에 가입하고, 저기에서 인증 제공업체에 가입하고, 키를 붙여넣고, 접착제를 작성합니다. 해당 스택의 모든 솔기는 사용자가 관리해야 합니다. Kliv의 백엔드는 앱, 즉 하나의 시스템으로 탄생하므로 페이지를 구축하는 동일한 대화가 마이그레이션 및 액세스 규칙도 작성하며 규칙은 모든 곳에 적용됩니다.
모든 앱의 탄생
이것은 하나씩 활성화하는 기능 목록이 아닙니다. 이는 모든 Kliv 앱의 표준 장비입니다. 첫 번째 페이지 설명을 마치기 전에 실행되는 것은 다음과 같습니다.
자체 규칙이 있는 데이터베이스
사용자의 데이터는 자체 데이터베이스에 있으며 개인 정보 보호는 행에서 시행됩니다. “클라이언트는 자신의 프로젝트만 읽습니다.”와 같은 규칙은 데이터의 속성이며 모든 쿼리에서 확인됩니다. 누군가가 모든 페이지에 작성해야 하는 if 문이 아닙니다.
로그인 및 신원
계정, 세션, 역할 및 조직은 첫 번째 페이지가 존재하기 전에 존재합니다. 사용자는 개인일 수도 있고 회사 전체일 수도 있으며 로그인은 비밀번호를 훨씬 넘어서는 수준까지 도달하며 아래에 자체 섹션이 있습니다.
액세스 규칙이 있는 파일 저장소
업로드, 이미지 및 문서에는 비공개, 조직별 공유, 구매 제한 등 자체적인 규칙이 있습니다. 전달된 링크는 규칙에서 허용하지 않는 어떤 것도 열지 않습니다. 공유는 결정이지 URL 사고가 아닙니다.
서버 측 함수, 유형
계산, 다른 도구에 대한 콜백, 야간 작업 등 로직을 서버에서 실행해야 하는 경우 AI는 컴파일러가 검사하는 유형이 지정된 SDK에 대해 실제 TypeScript를 작성합니다. 기능은 요청 시, 이벤트 또는 일정에 따라 실행됩니다.
볼트 안의 비밀
API 키와 자격 증명은 저장소에 있으며 브라우저가 볼 수 있는 코드에는 없습니다. 함수는 런타임에 이를 읽으며 소스에 민감한 내용은 전혀 없습니다.
사용자의 이름이 포함된 이메일
전송 및 템플릿은 백엔드의 일부입니다. 앱에서 보내는 메일은 앱으로 브랜드화되고, 한 번 작성되며, 구성할 타사 메일 서비스 없이 전송됩니다.
빌드에 따라 관리
백엔드 서비스가 수행하지 않는 부분: AI는 빌드의 부작용으로 이 모든 것을 유지합니다. 기능을 설명하면 스키마 변경이 순서대로 추적된 마이그레이션으로 도착합니다. 액세스 규칙은 필요한 페이지에 따라 발전합니다. 백엔드는 결코 분리되지 않았기 때문에 앱을 따릅니다.
표준 장비
6개 부품, 하나의 시스템 — 각 부품은 이미 다른 부품과 연결되어 있습니다.
나만의 데이터베이스
모든 쿼리에 행 수준 보안이 적용됩니다. 사용자별 개인정보 보호는 데이터의 속성이지 코드에서 유지해야 하는 습관이 아닙니다.
로그인 및 ID
계정, 조직 및 역할 — 사용자를 위한 Google 및 Facebook로그인, 암호 키 및 2단계 요소
파일 저장소
비공개, 조직별 또는 구매 뒤 등 자체 액세스 규칙이 있는 파일입니다. 링크만으로는 아무것도 열리지 않습니다.
유형화된 서버 측 함수
컴파일러 검사 SDK에 대한 실제 TypeScript — 요청 시, 이벤트 또는 일정에 따라.
비밀 볼트
코드 및 브라우저 외부의 키 및 자격 증명 — 함수는 이를 런타임에 읽습니다.
이메일 전달
템플릿 및 전달 기능 내장 — 공급업체 이름이 아닌 앱 이름이 포함된 메일입니다.
로그인 내장
대부분의 빌더에서는 이메일과 비밀번호를 제공하고 이를 ID라고 부릅니다. Kliv는 앱 사용자에게 실제 제품에서 기대하는 로그인 기능을 제공하며 이는 흐름, 브랜딩, 기록 등 앱에 속합니다.
이메일 및 비밀번호
계정, 확인 및 재설정 — 테이블 스테이크가 올바르게 처리됩니다.
Google 및 Facebook으로 로그인
사용자가 이미 가지고 있는 계정으로 한 번의 탭으로 로그인하세요.
패스키
Face ID, Touch ID 또는 보안 키를 사용한 피싱 방지 로그인 — 비밀번호를 도용할 필요가 없습니다.
2단계 인증
문을 두 번째로 잠그고 싶은 사용자를 위한 인증 앱의 TOTP 코드
조직 및 역할
팀, 역할 및 조직 벽 — 데이터베이스 규칙이 작성되는 구조.
사용자의 사용자, 사용자의 기록
모든 계정은 자체 데이터베이스의 행입니다. 요청 시 계정을 분할하거나 내보내거나 삭제하세요. 관계는 사용자의 것입니다.
자주 묻는 질문
백엔드는 내가 관리해야 하는 별도의 서비스인가요?
아니요 — 그게 핵심입니다. 앱과 함께 탄생하고 앱을 구축하는 것과 동일한 대화를 통해 관리됩니다. 프로비저닝할 대시보드도 없고, 첫날에 붙여넣을 키도 없으며, 두 번째 시스템이 코드와 동기화되지 않는 일도 없습니다.
데이터베이스 마이그레이션은 누가 작성하나요?
AI는 건물의 부작용으로 그렇게 합니다. 기능을 설명하면 스키마 변경 사항이 순서대로 추적된 마이그레이션으로 도착합니다. 보고 싶은 경우 읽을 수 있고 순서대로 적용되므로 데이터베이스 기록이 앱 기록만큼 읽기 쉽습니다.
사용자별 개인정보 보호는 실제로 어떻게 시행되나요?
행에서. 규칙은 데이터 자체에 적용되므로 모든 쿼리는 로그인한 사용자가 볼 수 있는 것만 반환합니다. 따라서 페이지의 버그로 인해 데이터베이스가 넘겨주기를 거부하는 정보가 유출될 수 없습니다.
사용자가 Google로 로그인할 수 있나요?
예 — 패스키 및 TOTP 2단계와 함께 Google 및 Facebook. 그리고 타사 위젯이 아닌 앱의 로그인, 즉 흐름, 브랜딩, 사용자 기록이 자체 데이터베이스에 저장됩니다.
API 키와 자격 증명은 어디에 있나요?
볼트에 있습니다. 함수는 런타임에 이를 읽습니다. 브라우저가 볼 수 있는 코드에는 절대 나타나지 않으며 소스 기록에는 민감한 내용이 없습니다.
내 코드와 데이터를 외부로 가져올 수 있나요?
그렇습니다. 앱의 소스는 자신의 Git 저장소와 양방향으로 동기화되며 데이터는 자신의 데이터베이스이므로 언제든지 내보낼 수 있습니다. Kliv의 내기는 떠나는 것이 힘들어서가 아니라, 좋기 때문에 머무르는 것입니다.
앱을 설명하세요. 백엔드도 함께 제공됩니다.
내장되어 있다는 것은 함께 빌드된다는 의미입니다. 결제, 에이전트 및 테스트가 모두 동일한 백엔드에서 실행됩니다. 즉, 하나의 규칙 세트가 모든 곳에 적용됩니다.