Nếu bạn đã có kinh nghiệm với lập trình cổ điển hoặc nền tảng không có mã/mã thấp khác, nhiều khái niệm sẽ quen thuộc.
Không giống như các giải pháp mã thấp và mã thấp khác, AppMaster được xây dựng theo cách tiếp cận cổ điển để xây dựng ứng dụng. Mục cơ bản trong AppMaster là dự án chứ không phải ứng dụng như trong các nền tảng khác. Các dự án có thể bao gồm nhiều ứng dụng phụ trợ, web và di động. Kiến trúc của giải pháp - máy chủ khách (không phải nguyên khối như trong Bubble hoặc các nền tảng tương tự).
Khi di chuyển từ các nền tảng không có mã khác, hãy nhớ rằng trong AppMaster, bạn tạo phần phụ trợ, web và thiết bị di động riêng biệt bằng các công cụ nền tảng khác nhau. Một trong những khoảnh khắc khó chịu nhất đối với những người dùng như vậy là hãy nhớ rằng bạn cần tạo các ứng dụng riêng biệt và xây dựng logic trong các ứng dụng đó.
Làm thế nào để bắt đầu?
Đối với hầu hết các dự án, bạn sẽ cần xây dựng phần phụ trợ và web, hoặc phần phụ trợ và thiết bị di động hoặc thậm chí tất cả các loại ứng dụng.
QUAN TRỌNG . Đảm bảo triển khai hầu hết logic của bạn trong ứng dụng phụ trợ. Không bao giờ đặt logic quan trọng trong web hoặc ứng dụng di động mà bạn không có quyền kiểm soát. Frontend chỉ dành cho trực quan hóa dữ liệu và thu thập thông tin từ đầu vào của người dùng.
Cách đơn giản nhất là bắt đầu bằng cách tạo một ứng dụng phụ trợ.
ỨNG DỤNG DỰ PHÒNG
Phần phụ trợ Bước 1 . Xác định các mô hình dữ liệu của bạn trong Trình thiết kế mô hình dữ liệu phụ trợ. Bạn có thể coi mỗi mô hình là một bảng trong cơ sở dữ liệu SQL (có quan hệ). Trong AppMaster, các Mô hình Dữ liệu không chỉ được sử dụng để xác định các bảng cơ sở dữ liệu chính mà còn là một khai báo cấu trúc trong toàn bộ dự án. Ví dụ: nếu logic của bạn sử dụng mô hình dữ liệu 'Người dùng', bạn có thể chắc chắn rằng bất kỳ cấu trúc nào thuộc loại đó sẽ có cùng một tập hợp các trường.
Nhấp chuột phải vào khung vẽ của Trình thiết kế mô hình dữ liệu để tạo mô hình mới và kéo từ đường viền mô hình này sang đường viền mô hình khác để tạo mối quan hệ. Nhấp vào trường quan hệ hoặc mô hình để chỉnh sửa nó.
Hãy cẩn thận với các thuộc tính trường như Duy nhất, Không phải NULL hoặc Chỉ mục: nếu bạn áp dụng chính sách KHÔNG NULL hoặc Duy nhất cho cơ sở dữ liệu hiện có với các giá trị trống hoặc trùng lặp, thì quá trình di chuyển lược đồ DB cuối cùng sẽ không thành công.
Phần phụ trợ Bước 2 . Tạo quy trình kinh doanh cho ứng dụng của bạn. Quy trình nghiệp vụ (BP) xét về Nền tảng AppMaster chỉ là một thuật ngữ duy nhất cho một Chức năng trong lập trình cổ điển.
Mọi BP phụ trợ đều có 2 khối bắt buộc: Bắt đầu và Kết thúc. Nếu bạn cần chuyển dữ liệu đến BP của mình, bạn cần xác định các biến trong khối Bắt đầu (nó sẽ hoạt động giống như các đối số trong các hàm từ lập trình cổ điển) và kết nối chúng với các khối của bạn bên trong BP.
Để trả về dữ liệu từ BP, bạn có thể thêm các biến vào khối Kết thúc (như trả về trong các hàm từ lập trình cổ điển).
Có 2 loại kết nối giữa các khối BP:
- đường mũi tên màu xanh liền được gọi là Kết nối luồng và xác định thứ tự thực hiện khối (khối nào sẽ được thực hiện tiếp theo)
- các đường mảnh nhiều màu được gọi là Kết nối biến xác định các ràng buộc dữ liệu (từ đâu để lấy dữ liệu - kết nối dữ liệu giữa các khối BP). Mỗi màu là một kiểu dữ liệu khác nhau
Thông thường, các vị trí trong Khối BP dành cho các kết nối Dòng hoặc Biến được gọi là các đầu nối. Tất cả các đầu nối ở phía bên trái của khối là Đầu nối vào (nhận Luồng hoặc dữ liệu) và ở phía bên phải là Đầu nối ra (chuyển Luồng hoặc dữ liệu về phía trước).
Để tạo kết nối, bạn cần kéo từ đầu nối này sang đầu nối khác (kéo giữa các khối bạn cần kết nối).
Bất kể bạn bắt đầu kéo từ phía nào, nó sẽ tạo thành một kết nối.
Trình chỉnh sửa BP tự động kiểm tra các loại dữ liệu cho các Kết nối có thể thay đổi và sẽ không cho phép bạn kết nối nếu các loại dữ liệu không giống nhau, nó cũng sẽ ngăn mọi vòng lặp hoặc kết nối xấu.
Bạn có thể gọi một BP từ một BP khác - chỉ cần kéo và thả khối thích hợp từ bảng điều khiển bên trái. Chúng tôi thường xuyên sử dụng phương pháp này để giảm thiểu độ phức tạp logic và tái sử dụng cùng một logic nhiều lần trong dự án.
Có 2 loại biến trong các ứng dụng phụ trợ mà bạn có thể đặt vào BP để lưu trữ dữ liệu tạm thời:
- Biến cục bộ - để lưu trữ dữ liệu trong vòng đời của BP hiện tại (hiệu quả nhất, chỉ trong bộ nhớ)
- Biến toàn cầu - sẽ lưu trữ dữ liệu của bạn trong suốt vòng đời của ứng dụng phụ trợ (cũng chỉ trong bộ nhớ, sẽ được đặt lại sau khi ứng dụng khởi động lại)
Trước khi bạn có thể sử dụng Biến toàn cầu bằng cách kéo nó từ bảng điều khiển bên trái của BP Editor, bạn cần tạo một biến bằng cách sử dụng một phần của logic phụ trợ.
Nếu BP của bạn cần được gọi từ nguồn bên ngoài thông qua API (từ web, điện thoại di động, sử dụng người đưa thư/curl, từ hệ thống bên ngoài), bạn cần đính kèm BP vào điểm cuối.
Backend Bước 3. Tạo điểm cuối. Trong AppMaster, chúng tôi sử dụng cùng một cách tiếp cận API REST cổ điển cho các điểm cuối. Mặc dù AppMaster không chỉ hỗ trợ Điểm cuối API REST mà còn cả điểm cuối WebHook và WSS, nhưng chúng tôi sẽ tập trung vào loại đầu tiên.
Khi tạo điểm cuối, vui lòng tuân thủ tiêu chuẩn API REST về các phương thức (GET, POST, PUT, PATCH, DELETE), tải trọng (sử dụng JSON) và URL (không có ký tự không phải ASCII, không có dấu cách, bắt đầu và kết thúc bằng một gạch chéo).
Quá trình tạo điểm cuối rất đơn giản và dễ hiểu: chọn BP, xác định URL và phương thức REST và nếu bạn cần ủy quyền trên điểm cuối đó - hãy kiểm tra cài đặt phần mềm trung gian.
Khi các mô hình dữ liệu, quy trình kinh doanh và điểm cuối đã sẵn sàng, đã đến lúc xuất bản - nhấn nút xuất bản! Thông thường, trong vòng chưa đầy 30 giây, Nền tảng AppMaster sẽ lấy tất cả các bản thiết kế của bạn (vâng, trên thực tế, mọi thứ bạn đã làm được tạo bản thiết kế cho phần mềm trong tương lai), tạo mã nguồn, biên dịch, đóng gói vào hình ảnh docker và triển khai lên đám mây AppMaster. Khi quá trình xuất bản kết thúc, bạn có thể mở tài liệu API REST (OpenAPI/Swagger) và kiểm tra các điểm cuối của mình bằng các yêu cầu tích hợp sẵn của Swagger hoặc sử dụng các công cụ của bên thứ 3 như Postman hoặc Insomnia.
QUAN TRỌNG . Nếu bạn đang chạy với đăng ký Tìm hiểu & Khám phá, Daemon tiết kiệm tài nguyên của chúng tôi sẽ dừng vùng chứa ứng dụng của bạn sau 30 phút bạn không hoạt động trong Studio. Để chạy lại - nhấp vào chuyển đổi hoặc xuất bản Kế hoạch triển khai một lần nữa.
ỨNG DỤNG WEB
Khi phần phụ trợ được lên kế hoạch và tạo đúng cách, đã đến lúc chuyển sang phần đầu. Chúng ta sẽ bắt đầu với ứng dụng web.
Ứng dụng web Bước 1 . Tạo một ứng dụng web nếu bạn không có một ứng dụng trong dự án. Hiện tại, chúng tôi có 2 loại Nhà thiết kế ứng dụng web: hiện tại và mới (trong phiên bản beta). Sự khác biệt chính là số lượng tùy chỉnh. Trình thiết kế WebApp thế hệ hiện tại có khả năng tùy chỉnh giao diện người dùng rất hạn chế, nhưng đơn giản và dễ dàng xây dựng giao diện người dùng tiêu chuẩn của bảng quản trị và cổng thông tin khách hàng. Cái mới (hiện đang trong giai đoạn thử nghiệm) có toàn bộ tùy chỉnh về giao diện và điền vào giao diện người dùng - một cách tiếp cận flexbox với bố cục từ SPA (cách Vue, React). Cả hai nhà thiết kế đều có Quy trình nghiệp vụ được tích hợp sẵn, bao gồm trình kích hoạt và một loạt các khối hữu ích.
Ứng dụng web Bước 2 . Bắt đầu thiết kế giao diện người dùng cho ứng dụng web của bạn bằng cách kéo và thả các phần tử giao diện người dùng từ bảng trên cùng (nhà thiết kế hiện tại) hoặc bảng điều khiển bên trái (nhà thiết kế mới). Đối với một số phần tử có liệt kê bên trong (như bảng và danh sách), bạn sẽ cần chọn mô hình dữ liệu trong giai đoạn thả ban đầu để tự động điều chỉnh phần tử.
Có 2 loại quy trình nghiệp vụ trong Ứng dụng web: Kích hoạt và Tiêu chuẩn. Trình kích hoạt có sẵn cho từng thành phần giao diện người dùng và cho phạm vi toàn ứng dụng (trình kích hoạt ứng dụng). Để truy cập trình kích hoạt của thành phần giao diện người dùng, hãy chọn thành phần đó và trong tab BP, hãy tạo một thành phần. Không giống như các BP tiêu chuẩn, trình kích hoạt có nhiều khối bắt đầu: một khối cho mỗi sự kiện và không có khối Kết thúc. Vì trình kích hoạt không bao giờ trả về bất kỳ giá trị nào nên không cần khối Kết thúc. Bạn vẫn có thể tạo các quy trình kinh doanh tiêu chuẩn trong các ứng dụng web, nhưng cách duy nhất để thực hiện chúng là gọi chúng từ trình kích hoạt. Đó là một cách tiếp cận tốt để chuyển logic được sử dụng thường xuyên sang các BP web tiêu chuẩn và chỉ cần gọi nó từ trình kích hoạt.
QUAN TRỌNG . Hãy nhớ rằng các BP phụ trợ sẽ chạy bên trong các ứng dụng phụ trợ, BP ứng dụng web sẽ chạy trong trình duyệt của người dùng và việc giảm thiểu khối lượng công việc web sẽ có lợi cho trải nghiệm người dùng.
Có một số trình kích hoạt cấp ứng dụng rất quan trọng. Ví dụ: Ứng dụng onLaunch kích hoạt khi một ứng dụng trong trình duyệt vừa khởi chạy. Đó là nơi tốt nhất để kiểm tra xem người dùng của bạn có được xác thực hay không và nếu không, hãy chuyển hướng đến đúng trang (nếu bạn cần xác thực).
Đừng quên lưu lược đồ ứng dụng web của bạn và xuất bản dự án của bạn để xem các thay đổi.
ỨNG DỤNG DI ĐỘNG
Khi bạn cần tạo ứng dụng dành cho thiết bị di động, quy trình này cũng giống như với ứng dụng web: tạo màn hình, đặt các thành phần giao diện người dùng, tạo trình kích hoạt thành phần giao diện người dùng, điều chỉnh trình kích hoạt App onLaunch và bạn đã sẵn sàng. Không có bản xem trước web cho ứng dụng di động AppMaster, nhưng bạn có thể cài đặt ứng dụng di động AppMaster Developer cho Android và IOS để xem trước trực tiếp ứng dụng của mình với tất cả các tính năng liên quan đến phần cứng như BLE, NFC, v.v.
Khi bạn đã hoàn thành việc phát triển ứng dụng dành cho thiết bị di động của mình và nó đã sẵn sàng để xuất bản, AppMaster có sẵn một trình hướng dẫn xuất bản đặc biệt từ menu ngữ cảnh trong danh sách tất cả các ứng dụng dành cho thiết bị di động trong dự án. Đối với Android, AppMaster sẽ tạo các tệp APK và AAB có thể.
BẢN TÓM TẮT
AppMaster là một IDE lớn nơi bạn có thể lập kế hoạch cho các ứng dụng của mình bằng các bản thiết kế nâng cao trong Trình thiết kế mô hình dữ liệu, Trình chỉnh sửa quy trình nghiệp vụ, Trình thiết kế web và thiết bị di động.
Câu hỏi thường gặp
Tại sao chúng ta cần các dự án có nhiều ứng dụng cho mỗi dự án?
AppMaster sử dụng kiến trúc máy khách-máy chủ chứ không phải nguyên khối. Có nhiều trường hợp bạn có thể muốn có nhiều ứng dụng cho mỗi dự án khi bạn cần tách các tính năng:
- Các dự án phức tạp: như taxi khi một ứng dụng cho hành khách và một ứng dụng cho tài xế làm việc với cùng một phụ trợ
- Tạo nhiều ứng dụng phụ trợ để cân bằng khối lượng công việc và thực hiện các thay đổi dễ dàng và ít rủi ro hơn
Mặc dù bạn đã có thể tạo nhiều ứng dụng web và thiết bị di động cho mỗi dự án, nhưng chúng tôi vẫn đang nỗ lực giới thiệu nhiều ứng dụng phụ trợ cho mỗi dự án.
Những lợi ích và hạn chế của các ứng dụng được tạo ra là gì?
Những lợi ích rõ ràng và đáng chú ý nhất là hiệu suất cao hơn đáng kể, khả năng mở rộng, khả năng tải các tệp nhị phân để chạy tại chỗ và mã nguồn để vượt qua các chứng nhận và kiểm tra. Chúng tôi sử dụng phiên bản mới nhất của ngôn ngữ lập trình Go để tạo các ứng dụng phụ trợ. Go mang lại rất nhiều hiệu suất cho các ứng dụng đã biên dịch, biên dịch chéo cho nhiều kiến trúc hệ điều hành và CPU và tính đơn giản tổng thể bằng cách duy trì tính linh hoạt.
Hạn chế phổ biến nhất là yêu cầu tạo lại và xây dựng lại ứng dụng mỗi khi bạn đưa ra các thay đổi đối với bản thiết kế của mình và trung bình thường mất khoảng 35-45 giây đối với các dự án cỡ trung bình. Ngoài ra, có một số phức tạp và chi phí bổ sung do chúng tôi cần chạy ứng dụng trong đám mây của mình: mỗi ứng dụng chúng tôi chạy trong bộ chứa docker sẽ tiêu tốn CPU và RAM (ngay cả khi không hoạt động) và yêu cầu di chuyển lược đồ DB (chúng tôi thực hiện tự động).
Nhưng nói chung, các ứng dụng được tạo bằng mã hoạt động tốt như những ứng dụng được tạo bằng lập trình cổ điển.
Công nghệ nào được sử dụng trong các ứng dụng web?
Chúng tôi tạo các ứng dụng web bằng khung Vue3 với TypeScript (TS). Các ứng dụng web hoạt động trong sự kết hợp của các chế độ SPA và SSG. Kết xuất phía máy chủ (SSR) sẽ được thêm sau và chỉ dành cho nhà thiết kế ứng dụng web mới.
Công nghệ nào được sử dụng trong các ứng dụng di động?
Các ứng dụng dành cho thiết bị di động của chúng tôi được xây dựng bằng cách sử dụng phương pháp tiếp cận dựa trên phụ trợ khai báo: chúng tôi sử dụng cơ sở mã gốc hoàn toàn (gốc nhất) của Swift và SwiftUI cho iOS, Kotlin và Jetpack Compose cho Android. Về mặt kỹ thuật, các ứng dụng di động tải cấu hình và màn hình qua mạng theo yêu cầu bằng cách sử dụng JSON và Protobuf để có hiệu suất tối đa. Có nhiều lợi ích của phương pháp này: bạn có thể thay đổi ứng dụng trong thời gian thực mà không cần xuất bản các phiên bản cập nhật của ứng dụng lên AppStore hoặc Play Market, có thể hoạt động hoàn toàn ngoại tuyến và có quyền truy cập vào tất cả các tính năng phần cứng. Chúng tôi không sử dụng công nghệ HTML/JS/ReactNative hoặc PWA trong các ứng dụng di động của mình. Ứng dụng dành cho thiết bị di động được tạo trong AppMaster cần được phân phối qua AppStore, Play Market hoặc bất kỳ nền tảng phân phối nào khác (về mặt kỹ thuật, bạn có thể chia sẻ tệp apk/aab cho Android, nhưng điều đó tốn rất nhiều công sức).
Bạn lưu trữ ứng dụng ở đâu theo mặc định?
Chúng tôi đã xây dựng AppMaster Cloud trên cơ sở hạ tầng AWS để cung cấp dịch vụ đáng tin cậy và có thể mở rộng nhất cho khách hàng của mình. Theo mặc định, khách hàng có đăng ký bất kỳ có thể sử dụng một trong 3 khu vực chính: Bắc Mỹ (Mỹ), Châu Âu (Đức), Châu Á. Đối với các gói lưu trữ dành riêng, chúng tôi có sẵn hầu hết các khu vực AWS (ngoài các vị trí cốt lõi). Nếu bạn cần một quốc gia cụ thể để lưu trữ ứng dụng của mình - hãy cho chúng tôi biết.
Làm cách nào tôi có thể lấy gói ứng dụng, mã nhị phân hoặc mã nguồn của các ứng dụng của mình?
Để nhận các gói hoặc tệp nhị phân, ít nhất bạn phải có đăng ký Doanh nghiệp. Các ứng dụng phụ trợ có thể được tải xuống từ cửa hàng tạo tác dưới dạng tệp nhị phân hoặc được kéo qua docker pull từ sổ đăng ký của chúng tôi (như Docker Hub). Các gói Di động và Web cũng có thể được tải xuống từ cửa hàng hiện vật. Bạn có thể tải gói ứng dụng dành cho thiết bị di động xuống với bất kỳ gói đăng ký nào ngoại trừ Tìm hiểu & Khám phá. Để lấy mã nguồn của ứng dụng, bạn phải có đăng ký doanh nghiệp. Với đăng ký doanh nghiệp, bạn sẽ nhận được mã nguồn hoàn chỉnh của ứng dụng web và phụ trợ nhưng cơ sở mã hạn chế của ứng dụng dành cho thiết bị di động vì chúng tôi sử dụng phương pháp tiếp cận dựa trên phụ trợ ở đó.
Sự khác biệt giữa Mô hình và Mô hình ảo là gì?
Chúng tôi sử dụng thuật ngữ Mô hình để chỉ cấu trúc mà chúng tôi sẽ tạo các bảng trong cơ sở dữ liệu và sẽ tự động tạo trước các khối DB để thực hiện các thao tác cơ bản trên bảng cơ sở dữ liệu đó như tìm kiếm, tạo bản ghi, v.v. Các mô hình ảo cũng giống như vậy, ngoại trừ chúng tôi sẽ không tạo bảng và sẽ không có khối DB. Các mô hình ảo là một trong những tính năng được hầu hết các nhà phát triển mong muốn nhất. Trường hợp sử dụng mô hình ảo thường xuyên nhất là khi bạn cần tạo cấu trúc (như Đối tượng trong JS hoặc JSON) và sử dụng nó cho các yêu cầu bên ngoài, thành phần giao diện người dùng hoặc điểm cuối. Thật tò mò rằng các Mô hình được xác định trong ứng dụng phụ trợ sẽ tự động xuất hiện trong ứng dụng web và thiết bị di động dưới dạng ảo: trong ứng dụng web và thiết bị di động, bạn cần biết về bất kỳ cấu trúc dữ liệu nào để có thể làm việc với.
Làm cách nào tôi có thể làm việc với các mô hình trong quy trình kinh doanh? Cách trích xuất các trường và v.v.
Đối với mỗi mô hình, chúng tôi tạo trước các khối Tạo và Mở rộng. Make sẽ tập hợp các trường vào Bản ghi mô hình, Mở rộng sẽ trích xuất các trường từ Bản ghi mô hình. Xin lưu ý rằng các khối đó không làm thay đổi dữ liệu ban đầu được chuyển đến đầu vào của các khối.
Làm cách nào tôi có thể đặt giá trị cho các biến cục bộ hoặc biến toàn cầu?
Tất cả các khối mà bạn sẽ sử dụng sẽ không làm thay đổi dữ liệu ban đầu khi bạn chuyển nó vào đầu vào. Khối duy nhất làm thay đổi dữ liệu là Đặt biến: kết nối biến và giá trị và sau khi thực hiện khối, bạn sẽ nhận được giá trị của mình bên trong biến. Các biến toàn cầu trong ứng dụng web và thiết bị di động có thể tồn tại lâu dài và sẽ tồn tại khi ứng dụng khởi động lại nếu cờ thích hợp được đặt.
Làm cách nào tôi có thể thực hiện lệnh gọi API tới hệ thống bên ngoài?
Cách tốt nhất để đưa ra yêu cầu cho các hệ thống bên ngoài là từ ứng dụng phụ trợ của bạn. Bằng cách đó, bạn sẽ có nhiều quyền kiểm soát hơn đối với dữ liệu và bảo mật. Có hai cách để bạn có thể làm điều đó:
- Sử dụng khối Yêu cầu HTTP là cách dễ nhất để làm điều đó, bạn có thể sử dụng nó trong bất kỳ BP phụ trợ nào
- Sử dụng Trình thiết kế API bên ngoài để tạo yêu cầu trước, sau đó sử dụng các khối được tạo thủ công bên trong BP của bạn.
Mặc dù bạn có thể sử dụng khối Yêu cầu HTTP để gọi các hệ thống bên ngoài không chỉ trong các ứng dụng phụ trợ mà còn trên web và thiết bị di động, nhưng bạn cần có lý do để thực hiện việc đó: khi ứng dụng giao diện người dùng của bạn muốn thực hiện cuộc gọi đến thiết bị trong mạng cục bộ hoặc nếu đó là do thiết kế cho hệ thống bên thứ 3.
Những loại yêu cầu và giao thức nào được hỗ trợ khi gọi các hệ thống bên ngoài?
Hiện tại, chúng tôi hỗ trợ các yêu cầu API REST với tải trọng JSON hoặc XML, văn bản thuần túy hoặc tải trọng nhị phân. gRPC chưa được hỗ trợ, nhưng chúng tôi đang tích cực làm việc để giới thiệu nó trong những tháng tới với Trình thiết kế API bên ngoài hoàn toàn mới của chúng tôi.
Các ứng dụng do AppMaster tạo có hỗ trợ WebSockets không?
Có, bạn có thể tạo các điểm cuối WSS trong ứng dụng phụ trợ và sử dụng chúng để liên lạc trong các ứng dụng web hoặc di động. Ngoài ra, bạn có thể xác định cấu trúc tải trọng của riêng mình bằng cách sử dụng các mô hình trong quá trình tạo điểm cuối WSS. Giao tiếp với các hệ thống bên ngoài bằng WebSockets không được triển khai.
Làm cách nào tôi có thể gọi điểm cuối phụ trợ từ ứng dụng Web hoặc Di động?
Đối với mọi điểm cuối mà bạn đã tạo trong ứng dụng phụ trợ, nền tảng sẽ tạo khối Yêu cầu máy chủ cho ứng dụng web và thiết bị di động. Chỉ cần đặt khối đó vào bất kỳ trình kích hoạt nào và gọi nó. Bạn có thể theo dõi quá trình thực thi khối Yêu cầu máy chủ trong bảng điều khiển dành cho nhà phát triển trình duyệt, tab yêu cầu mạng. Trong ứng dụng dành cho thiết bị di động, bạn có thể sử dụng nhật ký (trước tiên phải được bật trong cài đặt Ứng dụng dành cho nhà phát triển AppMaster).
Tôi có thể tạo đăng ký và xác thực tùy chỉnh không?
Chắc chắn rồi, bạn hoàn toàn có thể tắt mô-đun xác thực tích hợp sẵn và tạo một giải pháp hoàn toàn tùy chỉnh. Bạn sẽ cần tạo một BP riêng trong ứng dụng phụ trợ sẽ xử lý lực kéo mã thông báo xác thực (thường là từ tiêu đề yêu cầu) và kiểm tra theo quy tắc của bạn. Bạn có thể nhận các tiêu đề yêu cầu bằng cách sử dụng khối BP Nhận các tiêu đề yêu cầu . Xin lưu ý rằng sau khi tắt xác thực tích hợp, bạn sẽ không thể sử dụng khối Nhận người dùng hiện tại . Ngoài ra, bạn có thể sử dụng bất kỳ ID, số điện thoại hoặc số nhận dạng khác thay vì email với mô-đun Auth tiêu chuẩn.
Có cách nào để tạo các hoạt động an toàn theo luồng cho các bộ đếm đáng tin cậy và các trường hợp thực thi theo thứ tự khác không?
AppMaster hỗ trợ chế độ một luồng để thực thi quy trình công việc khi tất cả các cuộc gọi của quy trình công việc được thực hiện theo một thứ tự nghiêm ngặt, mỗi lần một. Chế độ này có thể có một hình phạt hiệu suất đối với các tình huống khối lượng công việc cao, nhưng trong hầu hết các trường hợp, nó không gây ra bất kỳ sự suy giảm hiệu suất đáng kể nào. Xin lưu ý rằng ngăn xếp cuộc gọi (hàng đợi) của chế độ này bị hạn chế.
2FA bằng SMS, email hay OTP?
Có, bạn có thể điều chỉnh logic xác thực của mình để bao gồm các phương thức 2FA. Để sử dụng SMS hoặc email, bạn phải kết nối với nhà cung cấp bên ngoài như Twilio. Cách dễ nhất là mở rộng phiên và bao gồm các trường bổ sung để kiểm soát 2FA trong phiên. Vào quý 3 năm 2023, chúng tôi sẽ giới thiệu mô-đun OTP dựa trên thời gian sẽ hoạt động với Google và Microsoft Authenticator.
Tôi có thể sử dụng chương trình phụ trợ do AppMaster tạo với các ứng dụng web hoặc di động khác không?
Có, các ứng dụng phụ trợ do AppMaster tạo có các điểm cuối API REST tiêu chuẩn. Đối với mỗi ứng dụng, tài liệu API REST (OpenAPI/Swagger) được tạo tự động và được cung cấp trên một điểm cuối riêng biệt.
Tôi có thể sử dụng các mẫu để tạo dự án hoặc ứng dụng không?
Chúng tôi chưa có mẫu, nhưng đó là thứ chúng tôi sẽ phát hành trong tương lai gần. Dự án AppMaster phức tạp hơn WebFlow hoặc Bubble và chúng tôi cần thêm thời gian để triển khai chúng.
AppMaster hỗ trợ loại cơ sở dữ liệu nào?
Ứng dụng phụ trợ do AppMaster tạo hoạt động với mọi cơ sở dữ liệu tương thích với PostgreSQL bắt đầu từ PG12, nhưng chúng tôi khuyên bạn nên sử dụng phiên bản mới nhất hiện có của PostgreSQL DB (15.3 tại thời điểm tạo tài liệu này). Hỗ trợ MSSQL, MariaDB, MySQL và SQLite đã được lên kế hoạch và sẽ được bổ sung vào cuối năm 2023/đầu năm 2024.
Làm cách nào tôi có thể truy cập trực tiếp vào cơ sở dữ liệu để chỉnh sửa bản ghi?
AppMaster không hỗ trợ truy cập DB trực tiếp cho các ứng dụng được lưu trữ trong Đám mây AppMaster. Nếu bạn sử dụng dịch vụ lưu trữ tại chỗ, bạn có thể truy cập DB bằng bất kỳ công cụ trực quan nào như PGAdmin hoặc sử dụng công cụ dòng lệnh pgsql. Trong tương lai, chúng tôi sẽ thêm tính năng cho phép khách hàng chỉnh sửa DB trực tiếp.
Có sự hợp tác thời gian thực nào không? Chúng ta có thể làm việc như một nhóm trong cùng một dự án không?
Chúng tôi chỉ cộng tác theo thời gian thực trong trình thiết kế web mới. Công cụ thiết kế web mới (beta) sử dụng bản nháp mạng với Giao thức kiểu dữ liệu sao chép không xung đột (CRDT) để bao gồm tất cả các trường hợp sử dụng và cung cấp quản lý trạng thái (Ctrl+Z, khôi phục hoạt động). Chúng tôi sẽ từng bước chuyển CRDT sang trình chỉnh sửa BP và Trình thiết kế mô hình dữ liệu trong tương lai. Nếu bạn cần làm việc theo nhóm, vui lòng không chỉnh sửa lược đồ mô hình dữ liệu, cùng một BP hoặc cùng một ứng dụng Web/Di động vì điều đó có thể dẫn đến mất dữ liệu.
AppMaster có thể thiếu những tính năng quan trọng nào?
- Trình thiết kế SQL trực quan . Mặc dù hầu hết các thao tác cơ bản như tìm kiếm bằng bộ lọc và tham gia, lấy một bản ghi theo id, cập nhật, vá lỗi, xóa và xóa mềm đều được hỗ trợ, nhưng để có hiệu suất và tính linh hoạt tốt hơn, chúng tôi đang làm việc trên Visual SQL Designer và nó sẽ được phát hành vào tháng 10 2023.
- Dịch vụ siêu nhỏ phụ trợ . Chúng tôi đang tích cực làm việc để triển khai nhiều ứng dụng phụ trợ cho mỗi dự án. Hiện tại, bạn chỉ có thể tạo một ứng dụng phụ trợ cho mỗi dự án.
- Chưa có SSR cho các ứng dụng web . Đối với các trang web và ứng dụng web được tối ưu hóa cao nhất, SSR bổ sung thêm các lợi ích cho SEO. ETA tháng 11 năm 2023.
- hỗ trợ gRPC cho Yêu cầu API bên ngoài . Chúng tôi dự định thêm gRPC với các tùy chọn nén và tải trọng protobuf để mở rộng khả năng kết nối giữa các hệ thống.
- Mẫu dự án, web và ứng dụng di động . Chúng tôi đang làm việc để giới thiệu các mẫu. Bước đầu tiên là chúng tôi sẽ thêm các mẫu ứng dụng web vào tháng 9 năm 2023. Toàn bộ mẫu dự án chưa có ETA.
