기존 프로그래밍 또는 기타 노코드/로우코드 플랫폼에 대한 경험이 있다면 많은 개념이 익숙할 것입니다.
다른 노코드 및 로우코드 솔루션과 달리 AppMaster는 애플리케이션 구축에 대한 고전적인 접근 방식으로 구축되었습니다. AppMaster의 기본 항목은 다른 플랫폼과 같은 응용 프로그램이 아닌 프로젝트입니다. 프로젝트는 여러 백엔드, 웹 및 모바일 애플리케이션으로 구성될 수 있습니다. 솔루션의 아키텍처 - 클라이언트 서버(Bubble 또는 유사한 플랫폼과 같은 모놀리스가 아님).
다른 노코드 플랫폼에서 전환할 때 AppMaster에서는 서로 다른 플랫폼 도구를 사용하여 백엔드, 웹 및 모바일을 별도로 생성한다는 점을 염두에 두십시오. 이러한 사용자에게 가장 실망스러운 순간 중 하나는 별도의 애플리케이션을 만들고 해당 앱에서 로직을 빌드해야 한다는 점을 기억하는 것입니다.
시작하는 방법?
대부분의 프로젝트에서 백엔드와 웹, 백엔드와 모바일 또는 모든 유형의 애플리케이션을 구축해야 합니다.
중요합니다 . 백엔드 애플리케이션에서 대부분의 논리를 구현해야 합니다. 제어할 수 없는 웹 또는 모바일 애플리케이션에 중요한 로직을 배치하지 마십시오. 프런트엔드는 사용자 입력에서만 데이터 시각화 및 정보 수집을 위한 것입니다.
가장 간단한 방법은 백엔드 애플리케이션을 만드는 것으로 시작하는 것입니다.
백엔드 애플리케이션
백엔드 1단계 . 백엔드 데이터 모델 디자이너에서 데이터 모델을 정의합니다. 각 모델은 관계가 있는 SQL 데이터베이스의 테이블로 생각할 수 있습니다. AppMaster에서 데이터 모델은 기본 데이터베이스 테이블을 정의하는 데만 사용되는 것이 아니라 프로젝트 전체에서 구조 선언으로도 사용됩니다. 예를 들어, 로직이 '사용자' 데이터 모델을 사용하는 경우 해당 유형의 모든 구조가 동일한 필드 집합을 갖도록 보장할 수 있습니다.
데이터 모델 디자이너의 캔버스를 마우스 오른쪽 버튼으로 클릭하여 새 모델을 생성하고 한 모델 경계에서 다른 모델 경계로 드래그하여 관계를 생성합니다. 관계 또는 모델 필드를 클릭하여 편집합니다.
Unique, Not NULL 또는 Index와 같은 필드 속성에 주의하십시오. 값이 비어 있거나 중복된 기존 데이터베이스에 NOT NULL 또는 Unique 정책을 적용하면 결국 DB 스키마 마이그레이션이 실패합니다.
백엔드 2단계 . 애플리케이션에 대한 비즈니스 프로세스를 만듭니다. AppMaster 플랫폼 측면에서 비즈니스 프로세스(BP)는 클래식 프로그래밍에서 기능에 대한 고유한 용어입니다.
모든 백엔드 BP에는 2개의 필수 블록(시작 및 종료)이 있습니다. BP에 데이터를 전달해야 하는 경우 Start 블록에서 변수를 정의하고(클래식 프로그래밍의 함수에서 인수처럼 작동함) BP 내부의 블록에 연결해야 합니다.
BP에서 데이터를 반환하려면 End 블록에 변수를 추가할 수 있습니다(클래식 프로그래밍의 함수 반환과 유사).
BP 블록 사이에는 두 가지 유형의 연결이 있습니다.
- 흐름 연결이라고 하는 파란색 실선 화살표는 블록 실행 순서(다음에 실행해야 하는 블록)를 정의합니다.
- 데이터 바인딩을 정의하는 가변 연결이라고 하는 여러 색상의 가는 선(데이터를 가져올 위치 - BP 블록 간의 데이터 연결). 모든 색상은 다른 데이터 유형입니다.
일반적으로 Flow 또는 Variable 연결을 위한 BP 블록의 위치를 커넥터라고 합니다. 블록의 왼쪽에 있는 모든 커넥터는 In 커넥터(흐름 또는 데이터 수신)이고 오른쪽에는 Out 커넥터(흐름 또는 데이터 전달 전달)입니다.
연결을 생성하려면 한 커넥터에서 다른 커넥터로 드래그해야 합니다(연결해야 하는 블록 사이를 드래그).
어느 쪽에서 드래그를 시작하든 연결이 형성됩니다.
BP 편집기는 변수 연결에 대한 데이터 유형을 자동으로 확인하고 데이터 유형이 동일하지 않은 경우 연결을 허용하지 않으며 루프 또는 잘못된 연결도 방지합니다.
다른 BP에서 하나의 BP를 호출할 수 있습니다. 왼쪽 패널에서 적절한 블록을 끌어다 놓기만 하면 됩니다. 우리는 이 접근 방식을 자주 사용하여 논리 복잡성을 최소화하고 프로젝트에서 동일한 논리를 여러 번 재사용합니다.
데이터를 임시로 저장하기 위해 BP에 배치할 수 있는 백엔드 애플리케이션에는 두 가지 유형의 변수가 있습니다.
- 로컬 변수 - 현재 BP의 수명 주기 동안 데이터를 저장합니다(가장 효율적인 메모리 내 전용).
- 전역 변수 - 백엔드 애플리케이션의 수명 주기 동안 데이터를 저장합니다(메모리 내에만 해당, 앱이 다시 시작되면 재설정됨).
BP Editor의 왼쪽 패널에서 전역 변수를 드래그하여 사용하기 전에 백엔드 로직 섹션을 사용하여 변수를 생성해야 합니다.
API를 통해 외부 소스(웹, 모바일, postman/curl 사용, 외부 시스템)에서 BP를 호출해야 하는 경우 엔드포인트에 BP를 연결해야 합니다.
백엔드 3단계. 엔드포인트를 생성합니다. AppMaster에서는 엔드포인트에 대해 동일한 기존 REST API 접근 방식을 사용합니다. AppMaster는 REST API 엔드포인트뿐만 아니라 WebHooks 및 WSS 엔드포인트도 지원하지만 첫 번째 유형에 중점을 둘 것입니다.
엔드포인트를 생성할 때 메소드(GET, POST, PUT, PATCH, DELETE), 페이로드(JSON 사용) 및 URL(비ASCII 문자 없음, 공백 없음, 삭감).
끝점을 만드는 과정은 매우 간단하고 간단합니다. BP를 선택하고 URL 및 REST 메서드를 정의하고 해당 끝점에 대한 권한이 필요한 경우 미들웨어 설정을 확인하십시오.
데이터 모델, 비즈니스 프로세스 및 엔드포인트가 준비되면 게시할 시간입니다. 게시 버튼을 누르세요! 일반적으로 AppMaster Platform은 30초 이내에 모든 청사진을 가져오고(실제로 수행한 모든 작업은 향후 소프트웨어를 위한 청사진을 생성함) 소스 코드를 생성하고 컴파일하고 도커 이미지로 압축한 다음 AppMaster 클라우드에 배포합니다. 게시 프로세스가 완료되면 REST API 문서(OpenAPI/Swagger)를 열고 Swagger 내장 요청 또는 Postman 또는 Insomnia와 같은 타사 도구를 사용하여 끝점을 테스트할 수 있습니다.
중요합니다 . 학습 및 탐색 구독으로 실행하는 경우 Studio에서 30분 동안 활동이 없으면 리소스 절약 데몬이 애플리케이션 컨테이너를 중지합니다. 다시 실행하려면 Deploy Plan 토글을 클릭하거나 다시 한 번 게시하십시오.
웹 애플리케이션
백엔드가 적절하게 계획되고 생성되면 프런트엔드로 이동할 때입니다. 웹 애플리케이션부터 시작하겠습니다.
웹앱 1단계 . 프로젝트에 웹 애플리케이션이 없는 경우 웹 애플리케이션을 생성합니다. 현재 웹 애플리케이션 디자이너에는 현재 및 신규(베타)의 두 가지 유형이 있습니다. 주요 차이점은 사용자 정의의 양입니다. 현재 세대의 WebApp Designer는 UI 사용자 정의 기능이 매우 제한적이지만 관리자 패널 및 고객 포털의 표준 UI 인터페이스를 간단하고 쉽게 구축할 수 있습니다. 새로운 것 (현재 베타 버전)에는 UI 모양과 채우기의 전체 사용자 지정 기능이 있습니다. 두 설계자 모두 트리거 및 여러 가지 유용한 블록을 포함하여 비즈니스 프로세스가 내장되어 있습니다.
웹앱 2단계 . 상단 패널(현재 디자이너) 또는 왼쪽 패널(새 디자이너)에서 UI 요소를 끌어다 놓아 웹 애플리케이션의 UI 디자인을 시작합니다. 내부에 열거형이 있는 일부 요소(예: 테이블 및 목록)의 경우 요소를 자동으로 조정하려면 초기 드롭 단계에서 데이터 모델을 선택해야 합니다.
웹 애플리케이션에는 트리거와 표준의 두 가지 유형의 비즈니스 프로세스가 있습니다. 트리거는 각 UI 요소 및 애플리케이션 전체 범위(앱 트리거)에 사용할 수 있습니다. UI 요소의 트리거에 액세스하려면 요소를 선택하고 BP 탭에서 하나를 생성합니다. 표준 BP와 달리 트리거에는 여러 시작 블록이 있습니다. 각 이벤트에 대해 하나의 블록이 있고 종료 블록이 없습니다. 트리거는 값을 반환하지 않으므로 End 블록이 필요하지 않습니다. 여전히 웹 애플리케이션에서 표준 비즈니스 프로세스를 생성할 수 있지만 이를 실행하는 유일한 방법은 트리거에서 호출하는 것입니다. 이는 자주 사용되는 로직을 표준 웹 BP로 이동하고 트리거에서 호출하는 좋은 접근 방식입니다.
중요합니다 . 백엔드 BP는 백엔드 애플리케이션 내에서 실행되고 웹 앱 BP는 사용자 브라우저에서 실행되며 웹 작업량을 최소화하는 것이 사용자 경험에 도움이 된다는 점을 기억하십시오.
몇 가지 매우 중요한 애플리케이션 수준 트리거가 있습니다. 예를 들어 App onLaunch는 브라우저의 애플리케이션이 방금 실행되었을 때 실행됩니다. 사용자가 인증되었는지 확인하고 그렇지 않은 경우 올바른 페이지로 리디렉션하는 가장 좋은 장소입니다(인증이 필요한 경우).
웹 애플리케이션 스키마를 저장하고 프로젝트를 게시하여 변경 사항을 확인하는 것을 잊지 마십시오.
모바일 애플리케이션
모바일 애플리케이션을 생성해야 하는 경우 프로세스는 웹 애플리케이션과 동일합니다. 화면 생성, UI 요소 배치, UI 요소 트리거 생성, App onLaunch 트리거 조정 및 준비 완료입니다. AppMaster 모바일 애플리케이션에 대한 웹 미리보기는 없지만 Android 및 IOS용 AppMaster Developer 모바일 애플리케이션을 설치하여 BLE, NFC 등과 같은 모든 하드웨어 관련 기능을 사용하여 앱을 실시간으로 미리 볼 수 있습니다.
모바일 앱 개발을 완료하고 게시할 준비가 되면 AppMaster에는 프로젝트의 모든 모바일 애플리케이션 목록에 있는 상황에 맞는 메뉴에서 사용할 수 있는 특수 게시 마법사가 있습니다. Android의 경우 AppMaster는 가능한 APK 및 AAB 파일을 생성합니다.
요약
AppMaster는 데이터 모델 디자이너, 비즈니스 프로세스 편집기, 웹 및 모바일 디자이너의 고급 청사진으로 애플리케이션을 계획할 수 있는 대규모 IDE입니다.
자주하는 질문
프로젝트당 여러 앱이 있는 프로젝트가 필요한 이유는 무엇입니까?
AppMaster는 모놀리스가 아닌 클라이언트-서버 아키텍처를 사용합니다. 기능을 분리해야 할 때 프로젝트당 여러 앱이 필요한 경우가 많습니다.
- 복잡한 프로젝트: 승객을 위한 하나의 앱과 동일한 백엔드로 작업하는 운전자를 위한 하나의 앱인 택시와 같습니다.
- 여러 백엔드 애플리케이션을 만들어 워크로드의 균형을 맞추고 변경을 쉽고 덜 위험하게 만듭니다.
이미 프로젝트당 여러 웹 및 모바일 앱을 만들 수 있지만 프로젝트당 여러 백엔드 애플리케이션을 도입하기 위해 계속 노력하고 있습니다.
생성된 애플리케이션의 장점과 단점은 무엇입니까?
가장 분명하고 눈에 띄는 이점은 훨씬 더 높은 성능, 확장성, 바이너리 파일을 온프레미스에서 실행하는 기능, 인증 및 감사를 통과하는 소스 코드입니다. 최신 버전의 Go 프로그래밍 언어를 사용하여 백엔드 앱을 생성합니다. Go는 컴파일된 애플리케이션의 많은 성능, 여러 OS 및 CPU 아키텍처에 대한 교차 컴파일, 유연성을 유지함으로써 전반적인 단순성을 제공합니다.
가장 일반적인 단점은 청사진에 변경 사항을 도입할 때마다 앱을 다시 생성하고 빌드해야 한다는 요구 사항이며 보통 중간 규모 프로젝트의 경우 평균 35-45초 정도 걸립니다. 또한 클라우드에서 앱을 실행해야 하기 때문에 약간의 추가 복잡성과 비용이 있습니다. 도커 컨테이너에서 실행하는 각 앱은 CPU와 RAM(유휴 상태인 경우에도)을 사용하고 DB 스키마 마이그레이션이 필요합니다(자동으로 수행).
그러나 일반적으로 코드 생성 애플리케이션은 기존 프로그래밍으로 생성된 애플리케이션만큼 잘 작동합니다.
웹 애플리케이션에는 어떤 기술이 사용됩니까?
TypeScript(TS)와 함께 Vue3 프레임워크를 사용하여 웹 애플리케이션을 생성합니다. 웹 애플리케이션은 SPA와 SSG 모드의 조합으로 작동합니다. SSR(Server-Side Rendering)은 나중에 새로운 웹 앱 디자이너에게만 추가될 예정입니다.
모바일 애플리케이션에는 어떤 기술이 사용됩니까?
우리의 모바일 애플리케이션은 선언적 백엔드 기반 접근 방식을 사용하여 구축되었습니다. IOS용 Swift 및 SwiftUI, Android용 Kotlin 및 Jetpack Compose의 완전 네이티브(가장 네이티브) 코드베이스를 사용합니다. 기술적으로 모바일 애플리케이션은 최대 성능을 위해 JSON 및 Protobuf를 사용하여 온디맨드 네트워크를 통해 구성 및 화면을 로드합니다. 이 접근 방식에는 많은 이점이 있습니다. 업데이트된 버전의 애플리케이션을 AppStore 또는 Play Market에 게시할 필요 없이 실시간으로 애플리케이션을 변경할 수 있고, 완전히 오프라인으로 작업할 수 있으며, 모든 하드웨어 기능에 액세스할 수 있습니다. 우리는 모바일 애플리케이션에서 HTML/JS/ReactNative 또는 PWA 기술을 사용하지 않습니다. AppMaster에서 만든 모바일 앱은 AppStore, Play Market 또는 기타 배포 플랫폼을 통해 배포되어야 합니다(기술적으로는 Android용 apk/aab 파일을 공유할 수 있지만 많은 노력이 필요합니다).
기본적으로 애플리케이션을 어디에서 호스팅합니까?
고객에게 가장 안정적이고 확장 가능한 서비스를 제공하기 위해 AWS 인프라 위에 AppMaster Cloud를 구축했습니다. 기본적으로 모든 구독 고객은 북미(미국), 유럽(독일), 아시아의 3개 핵심 지역 중 하나를 사용할 수 있습니다. 전용 호스팅 계획의 경우 대부분의 AWS 리전을 사용할 수 있습니다(핵심 위치 이외). 애플리케이션을 호스팅하기 위해 특정 국가가 필요한 경우 알려주십시오.
내 애플리케이션의 애플리케이션 번들, 바이너리 또는 소스 코드를 얻으려면 어떻게 해야 합니까?
바이너리 파일 또는 번들을 받으려면 최소한 비즈니스 구독이 있어야 합니다. 백엔드 애플리케이션은 아티팩트 저장소에서 바이너리 파일로 다운로드하거나 레지스트리(예: Docker Hub)에서 docker pull을 통해 가져올 수 있습니다. 모바일 및 웹 번들도 아티팩트 스토어에서 다운로드할 수 있습니다. 학습 및 탐색을 제외한 모든 구독으로 모바일 앱 번들을 다운로드할 수 있습니다. 애플리케이션의 소스 코드를 얻으려면 엔터프라이즈 구독이 있어야 합니다. 엔터프라이즈 구독을 통해 백엔드 및 웹 애플리케이션의 완전한 소스 코드를 얻을 수 있지만 백엔드 기반 접근 방식을 사용하기 때문에 모바일 앱의 제한된 코드 기반을 얻을 수 있습니다.
모델과 가상 모델의 차이점은 무엇입니까?
우리는 모델이라는 용어를 사용하여 데이터베이스에 테이블을 생성할 구조를 가리키며 자동으로 DB 블록을 미리 생성하여 해당 데이터베이스 테이블에서 검색, 레코드 생성 등과 같은 기본 작업을 수행합니다. 가상 모델은 다음을 제외하고는 동일합니다. 테이블을 생성하지 않으며 DB 블록이 없습니다. 가상 모델은 대부분의 개발자가 가장 원하는 기능 중 하나였습니다. 가상 모델의 가장 빈번한 사용 사례는 구조(예: JS 또는 JSON의 개체)를 만들고 외부 요청, UI 요소 또는 끝점에 사용해야 하는 경우입니다. 백엔드 애플리케이션에서 정의된 모델이 자동으로 웹 및 모바일 앱에 가상으로 표시된다는 것이 궁금합니다. 웹 및 모바일 앱에서 작업할 수 있는 모든 데이터 구조에 대해 알아야 합니다.
비즈니스 프로세스에서 모델로 작업하려면 어떻게 해야 합니까? 필드 추출 방법 등
각 모델에 대해 Make 및 Expand 블록을 미리 생성합니다. Make는 모델 레코드에 필드를 수집하고 Expand는 모델 레코드에서 필드를 추출합니다. 해당 블록은 블록의 입력으로 전달되는 초기 데이터를 변경하지 않습니다.
로컬 또는 전역 변수의 값을 어떻게 설정할 수 있습니까?
사용할 모든 블록은 입력에 전달할 때 초기 데이터를 변경하지 않습니다. 데이터를 변경하는 유일한 블록은 변수 설정: 변수와 값을 연결하고 블록 실행 후 변수 내부에서 값을 가져옵니다. 모바일 및 웹 애플리케이션의 전역 변수는 지속성을 가질 수 있으며 적절한 플래그가 설정된 경우 애플리케이션을 다시 시작해도 유지됩니다.
외부 시스템에 API 호출을 하려면 어떻게 해야 합니까?
외부 시스템에 요청하는 가장 좋은 방법은 백엔드 애플리케이션에서 요청하는 것입니다. 이렇게 하면 데이터와 보안을 더 잘 제어할 수 있습니다. 다음 두 가지 방법이 있습니다.
- HTTP 요청 블록을 사용하는 것이 가장 쉬운 방법이며 모든 백엔드 BP에서 사용할 수 있습니다.
- 외부 API Designer를 사용하여 먼저 요청을 생성한 다음 BP 내부에서 제작된 블록을 사용합니다.
HTTP 요청 블록을 사용하여 백엔드 애플리케이션뿐만 아니라 웹 및 모바일에서도 외부 시스템을 호출할 수 있지만 이를 수행할 이유가 있어야 합니다. 타사 시스템용으로 설계된 경우입니다.
외부 시스템을 호출할 때 어떤 유형의 요청 및 프로토콜이 지원됩니까?
현재 JSON 또는 XML 페이로드, 일반 텍스트 또는 이진 페이로드가 포함된 REST API 요청을 지원합니다. gRPC는 아직 지원되지 않지만 새로운 외부 API 디자이너와 함께 다음 달에 도입하기 위해 적극적으로 노력하고 있습니다.
AppMaster에서 만든 애플리케이션은 WebSocket을 지원합니까?
예, 백엔드 애플리케이션에서 WSS 엔드포인트를 생성하고 이를 사용하여 웹 또는 모바일 앱 내에서 통신할 수 있습니다. 또한 WSS 끝점을 만드는 동안 모델을 사용하여 고유한 페이로드 구조를 정의할 수 있습니다. WebSocket을 사용한 외부 시스템과의 통신은 구현되지 않습니다.
웹 또는 모바일 애플리케이션에서 백엔드 엔드포인트를 호출하려면 어떻게 해야 합니까?
백엔드 애플리케이션에서 생성한 모든 엔드포인트에 대해 플랫폼은 웹 및 모바일 앱에 대한 서버 요청 블록을 생성합니다. 해당 블록을 트리거에 놓고 호출하기만 하면 됩니다. 브라우저 개발자 콘솔의 네트워크 요청 탭에서 서버 요청 블록 실행을 모니터링할 수 있습니다. 모바일 앱에서 로그를 사용할 수 있습니다(AppMaster 개발자 앱 설정에서 먼저 활성화해야 함).
사용자 지정 인증 및 가입을 만들 수 있습니까?
물론 내장된 인증 모듈을 완전히 비활성화하고 완전한 맞춤형 솔루션을 만들 수 있습니다. 백엔드 애플리케이션에서 인증 토큰 견인(일반적으로 요청 헤더에서)을 처리하고 규칙에 따라 확인하는 별도의 BP를 생성해야 합니다. BP 블록 Get Request Headers 를 사용하여 요청 헤더를 가져올 수 있습니다. 기본 제공 인증을 비활성화하면 현재 사용자 가져오기 블록을 사용할 수 없습니다. 또한 표준 인증 모듈을 사용하면 이메일 대신 ID, 전화번호 또는 기타 식별자를 사용할 수 있습니다.
신뢰할 수 있는 카운터 및 기타 순서가 지정된 실행 사례에 대해 스레드로부터 안전한 작업을 생성할 수 있는 방법이 있습니까?
AppMaster는 비즈니스 프로세스의 모든 호출이 한 번에 하나씩 엄격한 순서로 실행될 때 비즈니스 프로세스 실행을 위한 단일 스레드 모드를 지원합니다. 이 모드는 워크로드가 높은 상황에서 성능이 저하될 수 있지만 대부분의 경우 성능이 크게 저하되지 않습니다. 이 모드의 호출 스택(대기열)은 제한되어 있습니다.
SMS, 이메일 또는 OTP를 통한 2FA?
예, 2FA 방법을 포함하도록 인증 로직을 조정할 수 있습니다. SMS 또는 이메일을 사용하려면 Twilio와 같은 외부 공급자를 연결해야 합니다. 가장 쉬운 방법은 세션을 확장하고 세션에서 2FA를 제어하기 위한 추가 필드를 포함하는 것입니다. 2023년 3분기에 Google 및 Microsoft Authenticator와 함께 작동하는 시간 기반 OTP 모듈을 도입할 예정입니다.
AppMaster에서 생성한 백엔드를 다른 웹 또는 모바일 애플리케이션과 함께 사용할 수 있습니까?
예, AppMaster에서 생성한 백엔드 애플리케이션에는 표준 REST API 엔드포인트가 있습니다. 각 애플리케이션에 대해 REST API 문서(OpenAPI/Swagger)가 자동으로 생성되어 별도의 엔드포인트에서 제공됩니다.
템플릿을 사용하여 프로젝트나 애플리케이션을 만들 수 있습니까?
아직 템플릿이 없지만 가까운 시일 내에 출시할 예정입니다. AppMaster 프로젝트는 WebFlow 또는 Bubble보다 복잡하며 이를 구현하는 데 더 많은 시간이 필요합니다.
AppMaster가 지원하는 데이터베이스 유형은 무엇입니까?
AppMaster에서 생성된 백엔드 애플리케이션은 PG12부터 모든 PostgreSQL 호환 데이터베이스와 함께 작동하지만 사용 가능한 최신 버전의 PostgreSQL DB(이 문서에서는 15.3)를 사용하는 것이 좋습니다. MSSQL, MariaDB, MySQL 및 SQLite 지원이 계획되어 있으며 2023년 말/2024년 초에 추가될 예정입니다.
레코드를 편집하기 위해 데이터베이스에 직접 액세스하려면 어떻게 해야 합니까?
AppMaster는 AppMaster Cloud에서 호스팅되는 애플리케이션에 대한 직접 DB 액세스를 지원하지 않습니다. 온 프레미스 호스팅을 사용하는 경우 PGAdmin과 같은 시각적 도구 또는 pgsql 명령줄 도구를 사용하여 DB에 액세스할 수 있습니다. 향후 고객이 DB를 직접 편집할 수 있는 기능을 추가할 예정입니다.
실시간 협업이 있습니까? 같은 프로젝트에서 팀으로 작업할 수 있습니까?
신규 웹디자이너에서만 실시간 협업이 가능합니다. 새로운 웹 디자이너(베타)는 CRDT(Conflict-free Replicated Data Type Protocol)와 함께 네트워크 초안을 사용하여 모든 사용 사례를 다루고 상태 관리(Ctrl+Z, 작업 롤백)를 제공합니다. 향후 단계적으로 CRDT를 BP 편집기 및 Data Models Designer에 점진적으로 적용할 예정입니다. 팀으로 작업해야 하는 경우 데이터 손실이 발생할 수 있으므로 데이터 모델 스키마, 동일한 BP 또는 동일한 웹/모바일 앱을 편집하지 마십시오.
AppMaster에 부족한 중요한 기능은 무엇입니까?
- 비주얼 SQL 디자이너 . 필터 및 조인을 사용한 검색과 같은 대부분의 기본 작업은 ID로 하나의 레코드 가져오기, 업데이트, 패치, 삭제 및 일시 삭제가 지원되지만 더 나은 유연성과 성능을 위해 Visual SQL Designer에서 작업하고 있으며 10월에 릴리스될 예정입니다. 2023.
- 백엔드 마이크로서비스 . 우리는 프로젝트당 여러 백엔드 애플리케이션을 구현하기 위해 적극적으로 노력하고 있습니다. 현재로서는 프로젝트당 하나의 백엔드 앱만 만들 수 있습니다.
- 아직 웹 애플리케이션용 SSR이 없습니다 . 고도로 최적화된 웹 애플리케이션 및 웹사이트의 경우 SSR은 SEO에 추가적인 이점을 제공합니다. 예상 도착 시간은 2023년 11월입니다.
- 외부 API 요청에 대한 gRPC 지원 . 시스템 간 상호 연결 가능성을 확장하기 위해 protobuf 페이로드 및 압축 옵션이 있는 gRPC를 추가할 계획입니다.
- 프로젝트, 웹 및 모바일 애플리케이션의 템플릿 . 템플릿을 도입하기 위해 노력하고 있습니다. 2023년 9월 첫 단계로 웹 앱 템플릿을 추가할 예정입니다. 전체 프로젝트 템플릿에는 아직 ETA가 없습니다.
