Создание приложения с помощью no-code: Пошаговое руководство

В этой статье мы углубляемся в основные элементы no-code платформы AppMaster и предлагаем краткое руководство для новичков.

Те, кто имеет опыт традиционного программирования или опыт работы с другими платформами без кода или low-code, найдут в AppMaster много знакомых концепций.

В отличие от других решений no-code/low-code, AppMaster использует традиционный подход к разработке приложений. Основной единицей в AppMaster является «проект», а не «приложение», как в других платформах. Эти проекты могут включать в себя множество серверных (бэкенд), веб и мобильных приложений, использующих архитектуру клиент-сервер вместо монолитной структуры, характерной для таких платформ, как Bubble.

Для пользователей, переходящих с других no-code платформ, важно отметить, что AppMaster предполагает создание серверных (бэкенд), веб и мобильных компонентов отдельно, каждый со своим собственным набором инструментов. Общая проблема для таких пользователей — помнить о необходимости разработки отдельных приложений и построения логики внутри этих отдельных приложений.

Для большинства проектов вам потребуется создать серверную часть (бэкенд) и веб-интерфейс или серверную часть и мобильные приложения или даже все типы приложений.

Самый простой способ — начать с создания серверного приложения (бэкенда).

Серверная часть, шаг 1

Определите свои модели данных в Backend Data Models Designer. Вы можете представить каждую модель как таблицу в базе данных SQL (с отношениями). В AppMaster модели данных используются не только для определения основных таблиц базы данных, но и в качестве объявления структуры в рамках проекта. Например, если ваша логика использует модель данных «Пользователь», вы можете быть уверены, что любая структура этого типа будет иметь одинаковый набор полей.

Щелкните правой кнопкой мыши на холсте конструктора моделей данных, чтобы создать новую модель, и перетащите ее от одной границы модели к другой границе модели, чтобы создать связь. Нажмите на поле отношения или модели, чтобы отредактировать его.

Будьте осторожны с такими свойствами полей, как «Unique», «Not NULL» или «Index»: если вы примените политику NOT NULL или Unique к существующей базе данных с пустыми или повторяющимися значениями, миграция схемы БД в конечном итоге завершится неудачей.

Серверная часть, шаг 2

Создайте бизнес-процессы для вашего приложения. Бизнес-процесс (БП) с точки зрения платформы AppMaster — это просто уникальный термин для функции в классическом программировании.

Каждый бэкэнд-BP имеет 2 обязательных блока: Start и End. Если вам нужно передать данные в ваш БП, вам необходимо определить переменные в блоке Start (он будет работать как аргументы в функциях из классического программирования) и подключить их к вашим блокам внутри БП.

Для возврата данных из БП можно добавить переменные в блок End (как в функциях из классического программирования).

Существует 2 типа связей между блоками БП:

• жирная синяя линия в форме стрелки, называемая Flow Connections и определяющая порядок выполнения блоков (какой блок должен выполняться следующим). Рис1
• тонкие линии нескольких цветов, называемые Variable Connections, которые определяют привязки данных (откуда брать данные — связь данных между блоками БП). Каждый цвет представляет собой отдельный тип данных. Рис2

Обычно места в блоках БП для соединений потока или переменной называются соединителями. Все разъемы на левой стороне блока являются входными разъемами (получают поток или данные), а с правой стороны — выходными разъемами (передают поток или данные вперед).

Чтобы создать соединение, нужно перетащить от одного соединителя к другому (перетаскивать между блоками, которые нужно соединить).

Неважно, с какой стороны вы начнете тянуть, это сформирует соединение.

Редактор БП автоматически проверяет типы данных на наличие переменных соединений и не позволит вам подключиться, если типы данных не идентичны, а также предотвратит возникновение петель или плохих соединений.

Вы можете вызвать один БП из другого — просто перетащите соответствующий блок с левой панели. Мы часто используем этот подход, чтобы минимизировать сложность логики и многократно использовать одну и ту же логику в проекте.

В серверных приложениях есть 2 типа переменных, которые вы можете поместить в БП для временного хранения данных:

• Локальные переменные — для хранения данных в течение жизненного цикла текущего БП (наиболее эффективно, только в памяти).
• Глобальные переменные — будут хранить ваши данные в течение жизненного цикла серверного приложения (также только в памяти, будут сброшены после перезапуска приложения).

Прежде чем вы сможете использовать глобальную переменную, перетащив ее с левой панели редактора БП, вам необходимо создать ее, используя раздел внутренней логики.

Если ваш БП необходимо вызвать из внешнего источника через API (из вашего веб, мобильного, с помощью postman/curl, из внешней системы), вам необходимо прикрепить к эндпоинту.

Серверная часть, шаг 3

Создайте эндпоинты. В AppMaster мы используем тот же классический подход REST API для эндпоинтов. Хотя AppMaster поддерживает не только эндпоинты REST API, но также эндпоинты WebHooks и WSS, мы сосредоточимся на первом типе.

При создании эндпоинтов придерживайтесь стандарта REST API в отношении методов (GET, POST, PUT, PATCH, DELETE), полезных данных (используйте JSON) и URL-адресов (без символов, отличных от ASCII, без пробелов, начинается и заканчивается слэш).

Процесс создания эндпоинтов очень прост и понятен: выберите BP, определите URL и метод REST, и если вам нужна авторизация на этих эндпоинтах — проверьте настройки промежуточного программного обеспечения.

Когда модели данных, бизнес-процессы и эндпоинты готовы, пришло время публикации — нажмите кнопку публикации! Обычно платформа AppMaster менее чем за 30 секунд возьмет все ваши чертежи (да, на самом деле все, что вы сделали, — это созданные чертежи для будущего программного обеспечения), сгенерирует исходный код, скомпилирует, упакует в образ докера и развернет в облаке AppMaster. Когда процесс публикации будет завершен, вы можете открыть документацию по REST API (OpenAPI/Swagger) и протестировать свои эндпоинты с помощью встроенных запросов Swagger или с помощью сторонних инструментов, таких как Postman или Insomnia.

Когда бэкэнд правильно спланирован и создан, пришло время перейти к интерфейсу. Начнем с веб-приложения.

Веб-приложения, шаг 1

Создайте веб-приложение, если у вас его нет в проекте. На данный момент у нас есть два типа дизайнеров веб-приложений: текущий и новый (в бета-версии). Основное отличие – это количество настроек. WebApp Designer текущего поколения имеет очень ограниченные возможности настройки пользовательского интерфейса, но с его помощью легко и просто создавать стандартные интерфейсы пользовательского интерфейса панелей администратора и клиентских порталов. Новый (в настоящее время находится в стадии бета-тестирования) имеет полную настройку внешнего вида пользовательского интерфейса — подход flexbox с макетами из SPA (способ Vue, React).

Оба дизайнера имеют встроенные бизнес-процессы, включая триггеры и кучу полезных блоков.

Веб-приложения, шаг 2

Начните разработку пользовательского интерфейса вашего веб-приложения, перетаскивая элементы пользовательского интерфейса с верхней панели (текущий дизайнер) или левой панели (новый дизайнер). Для некоторых элементов, внутри которых есть перечисление (например, таблиц и списков), вам потребуется выбрать модель данных на начальном этапе удаления, чтобы автоматически настроить элемент.

В веб-приложениях существует два типа бизнес-процессов: триггерный и стандартный. Триггеры доступны для каждого элемента пользовательского интерфейса и для всего приложения (триггеры приложения). Чтобы получить доступ к триггеру элемента пользовательского интерфейса, выберите элемент и на вкладке БП создайте его. В отличие от стандартных БП, триггеры имеют несколько стартовых блоков: по одному блоку для каждого события и без конечного блока. Поскольку триггеры никогда не возвращают никаких значений, нет необходимости в блоках End. Вы по-прежнему можете создавать стандартные бизнес-процессы в веб-приложениях, но единственный способ их выполнить — вызвать их из триггеров. Это хороший подход, позволяющий переместить часто используемую логику в стандартные веб-БП и просто вызывать ее из триггеров.

Есть несколько очень важных триггеров уровня приложения. Например, App onLaunch срабатывает, когда приложение в браузере только что запускается. Это лучшее место, чтобы проверить, аутентифицирован ли ваш пользователь, и, если нет, перенаправить на нужную страницу (если вам вообще нужна аутентификация).

Не забудьте сохранить схему веб-приложения и опубликовать проект, чтобы увидеть изменения.

Когда вам нужно создать мобильное приложение, процесс такой же, как и с веб-приложением: создайте экраны, разместите элементы пользовательского интерфейса, создайте триггеры элементов пользовательского интерфейса, настройте триггер App onLaunch, и все готово. Для мобильных приложений AppMaster нет предварительной версии в Интернете, но вы можете установить мобильное приложение AppMaster Developer для Android и IOS, чтобы предварительно просмотреть свои приложения в реальном времени со всеми аппаратными функциями, такими как BLE, NFC и т. д.

Когда вы закончите разработку своего мобильного приложения и оно будет готово к публикации, в AppMaster появится специальный мастер публикации, доступный из контекстного меню в списке всех мобильных приложений в проекте. Для Android AppMaster сгенерирует файлы APK и AAB.

В заключении
AppMaster — это большая интегрированная среда разработки, в которой вы можете планировать свои приложения с помощью расширенных чертежей в конструкторе моделей данных, редакторе бизнес-процессов, веб-дизайнерах и дизайнерах мобильных устройств.

1) Зачем нам нужны проекты с несколькими приложениями в каждом проекте?

AppMaster использует архитектуру клиент-сервер, а не монолит. Во многих случаях вам может понадобиться несколько приложений для каждого проекта, когда вам нужно разделить функции:

• Сложные проекты - такие как такси, когда одно приложение для пассажиров и одно для водителей работают с одним бэкендом
• Создание нескольких серверных приложений, чтобы сбалансировать рабочую нагрузку и сделать изменения простыми и менее рискованными

Хотя вы уже можете создавать несколько веб-приложений и мобильных приложений для каждого проекта, мы все еще работаем над внедрением нескольких серверных приложений для каждого проекта.

2) Каковы преимущества и недостатки созданных приложений?

Наиболее очевидными и заметными преимуществами являются значительно более высокая производительность, масштабируемость, возможность запускать двоичные файлы локально и исходный код для прохождения сертификации и аудита. Мы используем последнюю версию языка программирования Go для создания серверных приложений. Go обеспечивает высокую производительность скомпилированных приложений, кросс-компиляцию для нескольких архитектур ОС и ЦП, а также общую простоту, сохраняя гибкость.

Наиболее распространенными недостатками являются необходимость заново создавать и собирать приложение каждый раз, когда вы вносите изменения в свои чертежи, и обычно это занимает в среднем около 35–45 секунд для проектов среднего размера. Кроме того, существуют некоторые дополнительные сложности и затраты, поскольку нам необходимо запускать приложения в нашем облаке: каждое приложение, которое мы запускаем в Docker-контейнере, потребляет ресурсы ЦП и ОЗУ (даже в режиме ожидания) и требует миграции схемы БД (мы делаем это автоматически).

Но в целом приложения, генерируемые кодом, работают так же хорошо, как и приложения, созданные с помощью классического программирования.

3) Какая технология используется в веб-приложениях?

Мы создаем веб-приложения, используя фреймворк Vue3 с TypeScript (TS). Веб-приложения работают в комбинации режимов SPA и SSG. Серверный рендеринг (SSR) будет добавлен позже и только для новых дизайнеров веб-приложений.

4) Какие технологии используются в мобильных приложениях?

Наши мобильные приложения создаются с использованием декларативного подхода, управляемого серверной частью: мы используем полностью нативную кодовую базу Swift и SwiftUI для IOS, Kotlin и Jetpack Compose для Android. Технически мобильные приложения загружают конфигурацию и экраны по сети по требованию, используя JSON и Protobuf для максимальной производительности. У такого подхода много преимуществ: вы можете менять приложения в режиме реального времени без необходимости публиковать обновленные версии приложений в AppStore или Play Market, можете работать полностью в автономном режиме и иметь доступ ко всем функциям оборудования. Мы не используем технологии HTML/JS/ReactNative или PWA в наших мобильных приложениях. Мобильные приложения, созданные в AppMaster, необходимо распространять через AppStore, Play Market или любую другую платформу распространения (технически вы можете делиться файлами apk/aab для Android, но это требует больших усилий).

5) Где вы размещаете приложения по умолчанию?

Мы построили AppMaster Cloud поверх инфраструктуры AWS, чтобы предложить нашим клиентам самый надежный и масштабируемый сервис. По умолчанию клиенты с любой подпиской могут использовать один из трех основных регионов: Северная Америка (США), Европа (Германия), Азия. Для планов выделенного хостинга у нас доступно большинство регионов AWS (кроме основных местоположений). Если вам нужна конкретная страна для размещения вашего приложения, сообщите нам об этом.

6) Как я могу получить пакет приложений, двоичный файл или исходный код моих приложений?

Чтобы получать двоичные файлы или пакеты, у вас должна быть как минимум подписка Business. Серверные приложения можно загрузить из хранилища артефактов в виде двоичных файлов или извлечь через Docker из нашего реестра (например, Docker Hub). Мобильные и веб-пакеты также можно загрузить из магазина артефактов. Вы можете загружать пакеты мобильных приложений с любой подпиской, кроме Learn & Explore. Чтобы получить исходный код приложения, вам необходимо иметь корпоративную подписку. С корпоративной подпиской вы получите полный исходный код серверных и веб-приложений, но ограниченную базу кода мобильных приложений, поскольку мы используем здесь подход, основанный на серверной части.

7) Какие типы запросов и протоколов поддерживаются при вызове внешних систем?

На данный момент мы поддерживаем запросы REST API с полезными нагрузками JSON или XML, обычным текстом или двоичными данными. gRPC пока не поддерживается, но мы активно работаем над его внедрением в ближайшие месяцы с помощью нашего нового внешнего конструктора API.

8) Поддерживают ли приложения, созданные AppMaster, WebSockets?

Да, вы можете создавать конечные точки WSS в серверном приложении и использовать их для взаимодействия в веб-приложениях или мобильных приложениях. Кроме того, вы можете определить свои собственные структуры полезной нагрузки с помощью моделей при создании конечной точки WSS.

9) Могу ли я использовать серверную часть, созданную AppMaster, с другими веб-приложениями или мобильными приложениями?

Да, серверные приложения, созданные с помощью AppMaster, имеют стандартные эндпоинты REST API. Для каждого приложения документация по REST API (OpenAPI/Swagger) создается автоматически и обслуживается на отдельном эндпоинте.

Не нашли ответ на свой вопрос? Спросите команду AppMaster:

• В комьюнити
• В телеграмме