Если у вас уже есть опыт работы с классическим программированием или другими no-code/low-code платформами, то многие понятия будут вам знакомы.
В отличие от других no-code и low-code решений, AppMaster построен на основе классического подхода к созданию приложений. Основным элементом в AppMaster является проект, а не приложение, как в других платформах. Проект может состоять из нескольких бэкенд-, веб- и мобильных приложений. Архитектура решения - клиент-серверная (не монолит, как в Bubble и подобных платформах).
При переходе с других no-code платформ следует помнить, что в AppMaster вы создаете backend, web и mobile отдельно с помощью разных инструментов платформы. Один из самых неприятных моментов для таких пользователей - вспомнить, что нужно создавать отдельные приложения и строить в них логику.
Как начать?
Для большинства проектов необходимо создать backend и web, backend и mobile или даже все типы приложений.
ВАЖНО. Обязательно реализуйте большую часть логики в бэкенд-приложении. Никогда не размещайте важную логику в веб- или мобильных приложениях, где у вас нет контроля. Фронтенд предназначен только для визуализации данных и сбора информации с пользовательского ввода.
Наиболее простой путь - начать с создания backend-приложения.
БЭКЕНД-ПРИЛОЖЕНИЯ
Backend Шаг 1. Определите модели данных в Backend Data Models Designer. Каждую модель можно представить как таблицу в базе данных SQL (с отношениями). В AppMaster модели данных используются не только для определения первичных таблиц базы данных, но и в качестве объявления структуры всего проекта. Например, если в вашей логике используется модель данных 'User', то вы можете быть уверены, что любая структура этого типа будет иметь тот же набор полей.
Щелкните правой кнопкой мыши на холсте конструктора моделей данных, чтобы создать новую модель, и перетащите ее с одной границы модели на другую, чтобы создать отношение. Щелкните на отношении или поле модели, чтобы отредактировать его.
Будьте осторожны с такими свойствами полей, как Unique, Not NULL или Index: если применить политику NOT NULL или Unique к существующей базе данных с пустыми или дублирующимися значениями, миграция схемы БД завершится неудачей.
Backend Шаг 2. Создайте бизнес-процессы для вашего приложения. Бизнес-процесс (БП) в терминах AppMaster Platform - это просто уникальный термин для обозначения функции в классическом программировании.
Каждый БП бэкенда имеет 2 обязательных блока: Начало и Конец. Если вам нужно передать данные в БП, то в блоке Start необходимо определить переменные (они будут работать как аргументы в функциях из классического программирования) и связать их с вашими блоками внутри БП.
Для возврата данных из БП можно добавить переменные в блок End (как return в функциях классического программирования).
Существует два типа связей между блоками ВР:
- сплошная линия со стрелками синего цвета называется Flow Connections и определяет порядок выполнения блока (какой блок должен быть выполнен следующим)
- тонкие линии нескольких цветов, называемые переменными (Variable Connections), которые определяют привязку данных (откуда брать данные - связь между блоками ВР). Каждый цвет соответствует своему типу данных
Обычно места в блоках ВР для потоковых или переменных соединений называются коннекторами. Все коннекторы, расположенные в левой части блока, являются In Connectors (принимают поток или данные), а в правой части - Out Connectors (передают поток или данные вперед).
Чтобы создать соединение, необходимо перетащить коннектор с одной стороны на другую (перетащить между блоками, которые необходимо соединить).
Независимо от того, с какой стороны вы начнете перетаскивать, соединение будет сформировано.
Редактор БП автоматически проверяет типы данных для переменных соединений и не позволит соединить их, если типы данных не совпадают, а также предотвратит возникновение циклов или плохих соединений.
Вы можете вызывать один BP из другого - просто перетащите соответствующий блок с левой панели. Мы часто используем этот подход для минимизации сложности логики и многократного использования одной и той же логики в проекте.
В бэкенд-приложениях существует 2 типа переменных, которые можно поместить в БП для временного хранения данных:
- Локальные переменные - для хранения данных в течение жизненного цикла текущего БП (наиболее эффективны, только в памяти)
- Глобальные переменные - для хранения данных в течение жизненного цикла внутреннего приложения (также только в памяти, сбрасываются при перезапуске приложения).
Прежде чем использовать глобальную переменную, перетащив ее из левой панели редактора BP, необходимо создать ее на участке логики бэкенда.
Если ваш BP должен вызываться из внешнего источника через API (из web, мобильного, с помощью postman/curl, из внешней системы), то необходимо привязать BP к конечной точке.
Бэкенд Шаг 3. Создание конечных точек. В AppMaster мы используем тот же классический подход REST API для конечных точек. Хотя AppMaster поддерживает не только REST API Endpoints, но и WebHooks и WSS endpoints, мы остановимся на первом типе.
При создании конечных точек следует придерживаться стандарта REST API в части методов (GET, POST, PUT, PATCH, DELETE), полезной нагрузки (использовать JSON) и URL-адресов (не использовать символы, отличные от ASCII, без пробелов, начинать и заканчивать косой чертой).
Процесс создания конечных точек очень прост и понятен: выберите БП, определите URL и REST-метод, а если требуется авторизация на этой конечной точке - проверьте настройки промежуточного ПО.
Когда модели данных, бизнес-процессы и конечные точки готовы, наступает время публикации - нажимаем кнопку publish! Обычно менее чем за 30 секунд AppMaster Platform возьмет все ваши чертежи (да, собственно, все, что вы делали, - это и есть чертежи будущего ПО), сгенерирует исходный код, скомпилирует, упакует в docker-образ и развернет в облаке AppMaster. Когда процесс публикации завершен, можно открыть документацию по REST API (OpenAPI/Swagger) и протестировать свои конечные точки с помощью встроенных запросов Swagger или с помощью сторонних инструментов, таких как Postman или Insomnia.
ВАЖНО. Если вы работаете по подписке Learn & Explore, наш демон экономии ресурсов остановит контейнер приложения через 30 минут вашего бездействия в Studio. Для повторного запуска нажмите на переключатель Deploy Plan или опубликуйте его еще раз.
ВЕБ-ПРИЛОЖЕНИЯ
Когда бэкенд спланирован и создан, пора переходить к фронтенду. Начнем мы с веб-приложения.
WebApp Шаг 1. Создайте веб-приложение, если его еще нет в проекте. На данный момент у нас есть 2 типа конструкторов веб-приложений: текущий и новый (в бета-версии). Основное различие заключается в количестве настроек. Текущее поколение WebApp Designer имеет очень ограниченные возможности по кастомизации пользовательского интерфейса, но позволяет легко и просто строить стандартные UI-интерфейсы админ-панелей и клиентских порталов. Новое (пока бета-версия) имеет возможность полной кастомизации внешнего вида и наполнения UI - flexbox-подход с макетами из SPA (Vue, React way). В оба конструктора встроены бизнес-процессы, включая триггеры и кучу полезных блоков.
WebApp Шаг 2. Начните проектирование пользовательского интерфейса веб-приложения, перетаскивая элементы пользовательского интерфейса из верхней панели (текущий конструктор) или левой панели (новый конструктор). Для некоторых элементов, имеющих внутри перечисления (например, таблиц и списков), необходимо выбрать модель данных на этапе первоначального перетаскивания, чтобы автоматически настроить элемент.
В Web-приложениях существует 2 типа бизнес-процессов: Триггерный и Стандартный. Триггеры доступны для каждого элемента пользовательского интерфейса и для всего приложения (app triggers). Чтобы получить доступ к триггеру элемента пользовательского интерфейса, выберите этот элемент и на вкладке BP создайте его. В отличие от стандартных БП, триггеры имеют несколько начальных блоков: по одному блоку на каждое событие и не имеют конечного блока. Поскольку триггеры не возвращают никаких значений, нет необходимости в блоках End. Вы по-прежнему можете создавать стандартные бизнес-процессы в веб-приложениях, но единственный способ их выполнения - это вызов из триггеров. Это хороший подход, чтобы перенести часто используемую логику в стандартные веб-БП и просто вызывать ее из триггеров.
ВАЖНО. Помните, что backend BP будут работать внутри backend-приложений, а web-приложения будут работать в браузерах пользователей, и минимизация нагрузки на web-приложения благотворно скажется на удобстве работы пользователей.
Есть несколько очень важных триггеров на уровне приложений. Например, App onLaunch срабатывает, когда приложение в браузере только что запустилось. Это лучшее место для проверки аутентификации пользователя и, если нет, перенаправления на нужную страницу (если аутентификация вообще нужна).
Не забудьте сохранить схему веб-приложения и опубликовать проект, чтобы увидеть изменения.
МОБИЛЬНЫЕ ПРИЛОЖЕНИЯ
При необходимости создания мобильного приложения процесс аналогичен веб-приложению: создайте экраны, разместите элементы пользовательского интерфейса, создайте триггеры элементов пользовательского интерфейса, настройте триггер App onLaunch, и все готово. Для мобильных приложений AppMaster нет возможности предварительного просмотра в Интернете, но вы можете установить мобильное приложение AppMaster Developer для Android и IOS, чтобы вживую увидеть свои приложения со всеми функциями, связанными с аппаратным обеспечением, такими как BLE, NFC и т.д.
Когда вы закончили разработку мобильного приложения и готовы его опубликовать, в AppMaster есть специальный мастер публикации, доступный из контекстного меню в списке всех мобильных приложений проекта. Для Android AppMaster генерирует APK- и AAB-файлы, которые могут быть использованы.
РЕЗЮМЕ
AppMaster - это большая среда разработки, в которой вы можете планировать свои приложения с помощью продвинутых чертежей в конструкторе моделей данных, редакторе бизнес-процессов, веб- и мобильном конструкторах.
FAQ
Зачем нужны проекты с несколькими приложениями в одном проекте?
AppMaster использует клиент-серверную архитектуру, а не монолит. Существует множество случаев, когда вам может понадобиться несколько приложений в одном проекте, когда необходимо разделить функции:
- Сложные проекты: например, такси, когда одно приложение для пассажиров и одно для водителей работают с одним и тем же бэкендом.
- Создание нескольких бэкенд-приложений для балансировки рабочей нагрузки и упрощения внесения изменений с меньшим риском.
В то время как вы уже можете создавать несколько веб- и мобильных приложений для одного проекта, мы все еще работаем над внедрением нескольких бэкенд-приложений для одного проекта.
Каковы преимущества и недостатки генерируемых приложений?
Наиболее очевидными и заметными преимуществами являются значительно более высокая производительность, масштабируемость, возможность получения бинарных файлов для локального запуска, а также исходного кода для прохождения сертификации и аудита. Для генерации backend-приложений мы используем последнюю версию языка программирования Go. Go обеспечивает высокую производительность скомпилированных приложений, кросс-компиляцию для различных архитектур ОС и процессоров, а также общую простоту за счет гибкости.
К наиболее распространенным недостаткам можно отнести необходимость каждый раз заново генерировать и собирать приложение при внесении изменений в чертежи, что в среднем занимает около 35-45 секунд для проектов среднего размера. Кроме того, возникают дополнительные сложности и затраты, поскольку нам необходимо запускать приложения в нашем облаке: каждое приложение, запущенное в докер-контейнере, потребляет CPU и RAM (даже в режиме ожидания), а также требует миграции схемы БД (мы делаем это автоматически).
Но в целом приложения, созданные с помощью кода, работают не хуже, чем приложения, созданные с помощью классического программирования.
Какие технологии используются в веб-приложениях?
Мы создаем веб-приложения с помощью фреймворка Vue3 с использованием TypeScript (TS). Веб-приложения работают в комбинации режимов SPA и SSG. Server-Side Rendering (SSR) будет добавлен позже и только для нового дизайнера веб-приложений.
Какие технологии используются в мобильных приложениях?
Наши мобильные приложения создаются на основе декларативного бэкенд-ориентированного подхода: мы используем полностью нативную (самую нативную) кодовую базу из Swift и SwiftUI для IOS, Kotlin и Jetpack Compose для Android. Технически мобильные приложения загружают конфигурацию и экраны через сеть по требованию, используя JSON и Protobuf для достижения максимальной производительности. Преимуществ у такого подхода много: можно изменять приложения в реальном времени без необходимости публикации обновленных версий в AppStore или Play Market, можно работать полностью автономно и иметь доступ ко всем аппаратным возможностям. Мы не используем в своих мобильных приложениях технологии HTML/JS/ReactNative или PWA. Мобильные приложения, созданные в AppMaster, должны распространяться через AppStore, Play Market или любую другую платформу распространения (технически, для Android можно распространять apk/aab-файлы, но это требует больших усилий).
Где вы размещаете приложения по умолчанию?
Мы построили AppMaster Cloud на базе инфраструктуры AWS, чтобы предложить нашим клиентам наиболее надежный и масштабируемый сервис. По умолчанию клиенты с любой подпиской могут использовать один из 3 основных регионов: Северная Америка (США), Европа (Германия), Азия. Для выделенных хостинг-планов у нас доступно большинство регионов AWS (помимо основных). Если вам нужна конкретная страна для размещения вашего приложения - сообщите нам об этом.
Как я могу получить пакет приложений, бинарный или исходный код моих приложений?
Чтобы получить бинарные файлы или пакеты, необходимо иметь подписку не ниже Business. Бэкенд-приложения можно загрузить из хранилища артефактов в виде бинарных файлов или получить с помощью docker pull из нашего реестра (например, Docker Hub). Пакеты мобильных и веб-приложений также могут быть загружены из хранилища артефактов. Пакеты мобильных приложений можно загрузить с любой подпиской, кроме Learn & Explore. Чтобы получить исходный код приложения, необходимо иметь корпоративную подписку. При корпоративной подписке вы получите полный исходный код бэкенда и веб-приложений, но ограниченную кодовую базу мобильных приложений, поскольку мы используем подход, ориентированный на бэкенд.
В чем разница между моделью и виртуальной моделью?
Термин "модель" мы используем для обозначения структуры, для которой мы будем создавать таблицы в базе данных и автоматически создавать блоки БД для выполнения основных операций с таблицами базы данных, таких как поиск, создание записей и т.д. Виртуальные модели - это то же самое, только мы не будем создавать таблицы и не будет блоков БД. Виртуальные модели были одной из самых востребованных функций у большинства разработчиков. Наиболее часто виртуальные модели используются в тех случаях, когда необходимо создать структуру (например, объекты в JS или JSON) и использовать ее для внешних запросов, элементов пользовательского интерфейса или конечных точек. Любопытно, что модели, определенные в бэкенд-приложениях, автоматически появляются в веб- и мобильных приложениях как виртуальные: в веб- и мобильных приложениях для работы с любой структурой данных необходимо знать о ней.
Как я могу работать с моделями в бизнес-процессах? Как извлекать поля и т.д.
Для каждой модели мы предварительно генерируем блоки Make и Expand. Блок Make будет собирать поля в запись модели, а блок Expand будет извлекать поля из записи модели. Обратите внимание, что эти блоки не изменяют исходные данные, которые передаются на вход блоков.
Как я могу задать значение локальной или глобальной переменной?
Все блоки, которые вы будете использовать, не будут мутировать исходные данные при передаче их на вход. Единственный блок, который мутирует данные, - это Set Variable: соедините переменную и значение, и после выполнения блока вы получите значение внутри переменной. Глобальные переменные в мобильных и веб-приложениях могут обладать персистентностью и сохраняться после перезапуска приложения, если установлен соответствующий флаг.
Как я могу сделать API-вызов к внешней системе?
Лучше всего делать запросы к внешним системам из своего внутреннего приложения. Так вы получите больше контроля над данными и безопасностью. Это можно сделать двумя способами:
- Использование блока HTTP-запросов - самый простой способ, его можно использовать в любом бэкенде BP.
- с помощью External API Designer сначала создать запрос, а затем использовать созданные блоки внутри BP.
Хотя блок HTTP Request можно использовать для вызова внешних систем не только в backend-приложениях, но и в web- и мобильных, для этого должны быть основания: когда ваше frontend-приложение хочет сделать вызов устройства в локальной сети, или если это предусмотрено дизайном сторонней системы.
Какие типы запросов и протоколов поддерживаются при обращении к внешним системам?
На данный момент мы поддерживаем REST API-запросы с полезной нагрузкой в виде JSON или XML, обычного текста или бинарных файлов. gRPC пока не поддерживается, но мы активно работаем над его внедрением в ближайшие месяцы с помощью нашего нового конструктора внешних API.
Поддерживают ли приложения, созданные в AppMaster, WebSockets?
Да, вы можете создавать конечные точки WSS в бэкенд-приложении и использовать их для взаимодействия в веб- или мобильных приложениях. Кроме того, при создании конечной точки WSS можно определять собственные структуры полезной нагрузки с помощью моделей. Обмен данными с внешними системами с помощью WebSockets не реализован.
Как я могу вызвать конечную точку бэкенда из веб- или мобильного приложения?
Для каждой конечной точки, созданной в бэкенд-приложении, платформа создает блок Server Requestдля веб- и мобильных приложений. Просто поместите этот блок в любой триггер и вызовите его. Выполнение блоков Server Request можно отслеживать в консоли разработчика браузера, вкладка "Сетевые запросы". В мобильных приложениях можно использовать журналы (их необходимо предварительно включить в настройках приложения для разработчиков AppMaster).
Можно ли создать пользовательскую аутентификацию и регистрацию?
Конечно, вы можете полностью отключить встроенный модуль аутентификации и создать полностью индивидуальное решение. Для этого необходимо создать отдельный БП в бэкенд-приложении, который будет обрабатывать получение auth-токена (обычно из заголовка запроса) и проверять его в соответствии с вашими правилами. Получить заголовки запросов можно с помощью BP-блока Get Request Headers. Обратите внимание, что после отключения встроенного auth вы не сможете использовать блок Get Current User. Кроме того, с помощью стандартного модуля Auth можно использовать любой ID, номер телефона или другой идентификатор вместо email.
Можно ли как-то создать потокобезопасные операции для надежных счетчиков и других случаев упорядоченного выполнения?
AppMaster поддерживает однопоточный режим выполнения бизнес-процессов, когда все вызовы бизнес-процесса выполняются в строгом порядке, по одному. Этот режим может иметь недостаток производительности в условиях высокой нагрузки, но в большинстве случаев он не приводит к существенному снижению производительности. Следует учитывать, что стек (очередь) вызовов в этом режиме ограничен.
2FA с помощью SMS, электронной почты или OTP?
Да, вы можете настроить логику аутентификации таким образом, чтобы она включала методы 2FA. Для использования SMS или электронной почты необходимо подключить внешнего провайдера, например Twilio. Самый простой способ - расширить сессии и включить в них дополнительные поля для управления 2FA в сессии. В третьем квартале 2023 года мы представим модуль Time-based OTP, который будет работать с Google и Microsoft Authenticator.
Могу ли я использовать сгенерированный AppMaster бэкенд в других веб- или мобильных приложениях?
Да, сгенерированные AppMaster бэкенды имеют стандартные конечные точки REST API. Для каждого приложения автоматически генерируется документация по REST API (OpenAPI/Swagger), которая предоставляется на отдельной конечной точке.
Могу ли я использовать шаблоны для создания проектов или приложений?
Пока у нас нет шаблонов, но мы планируем выпустить их в ближайшем будущем. Проекты AppMaster сложнее, чем WebFlow или Bubble, и нам нужно больше времени для их реализации.
Какие типы баз данных поддерживает AppMaster?
Создаваемые AppMaster бэкенд-приложения работают с любыми PostgreSQL-совместимыми базами данных, начиная с PG12, но мы рекомендуем использовать последнюю доступную версию PostgreSQL DB (15.3 на момент подготовки этого документа). Поддержка MSSQL, MariaDB, MySQL и SQLite запланирована и будет добавлена в конце 2023 - начале 2024 года.
Как я могу получить прямой доступ к базе данных для редактирования записей?
AppMaster не поддерживает прямой доступ к БД для приложений, размещенных в AppMaster Cloud. Если вы используете локальный хостинг, вы можете получить доступ к БД с помощью любого визуального инструмента, например PGAdmin, или с помощью инструмента командной строки pgsql. В будущем мы добавим возможность прямого редактирования БД.
Существует ли возможность совместной работы в режиме реального времени? Можем ли мы работать в одной команде над одним проектом?
Совместная работа в реальном времени есть только в новом веб-дизайнере. В новом веб-дизайнере (бета-версия) используются сетевые черновики с протоколом бесконфликтной репликации типов данных (CRDT), что позволяет охватить все случаи использования и обеспечить управление состоянием (Ctrl+Z, откат операций). В дальнейшем мы будем постепенно внедрять CRDT в редактор БП и конструктор моделей данных. Если вам необходимо работать в команде, пожалуйста, не редактируйте схему модели данных, один и тот же БП или одно и то же Web/Mobile приложение, так как это может привести к потере данных.
Каких важных функций может не хватать AppMaster?
- Визуальный конструктор SQL. Хотя большинство базовых операций, таких как поиск с фильтрами и объединениями, получение одной записи по id, обновление, исправление, удаление и мягкое удаление, поддерживаются, но для большей гибкости и производительности мы работаем над Visual SQL Designer, и он будет выпущен в октябре 2023 года.
- Микросервисы бэкенда. Мы активно работаем над реализацией нескольких бэкенд-приложений в одном проекте. В настоящее время в одном проекте можно создать только одно внутреннее приложение.
- SSR для веб-приложений пока нет. Для наиболее высоко оптимизированных веб-приложений и веб-сайтов SSR дает дополнительные преимущества для SEO. Ориентировочное время выхода - ноябрь 2023 года.
- Поддержка gRPC для внешних API-запросов. Мы планируем добавить gRPC с полезной нагрузкой protobuf и опциями сжатия для расширения возможностей взаимодействия между системами.
- Шаблоны проектов, веб- и мобильных приложений. Мы работаем над внедрением шаблонов. В качестве первого шага мы добавим шаблоны веб-приложений в сентябре 2023 года. Шаблоны проектов в целом пока не имеют ETA.
