Se já tem experiência com programação clássica ou outra plataforma sem código/baixo código, muitos conceitos ser-lhe-ão familiares.
Ao contrário de outras soluções no-code e low-code, o AppMaster é construído com uma abordagem clássica para a construção de aplicações. O item básico no AppMaster é um projeto, não uma aplicação como em outras plataformas. Os projectos podem consistir em várias aplicações backend, web e móveis. A arquitetura da solução é cliente-servidor (não um monólito como no Bubble ou em plataformas semelhantes).
Ao mudar de outras plataformas sem código, tenha em mente que no AppMaster cria backend, web e móvel separadamente com diferentes ferramentas de plataforma. Um dos momentos mais frustrantes para esses utilizadores é lembrar-se que é necessário criar aplicações separadas e construir a lógica nessas aplicações.
Como começar?
Para a maioria dos projectos, terá de criar aplicações backend e web, ou backend e mobile ou mesmo todos os tipos de aplicações.
IMPORTANTE. Certifique-se de que implementa a maior parte da sua lógica na aplicação de backend. Nunca coloque lógica importante nas aplicações Web ou móveis, onde não tem qualquer controlo. O frontend destina-se apenas à visualização de dados e à recolha de informações a partir dos dados introduzidos pelo utilizador.
A forma mais simples é começar por criar uma aplicação de backend.
APLICAÇÕES DE BACKEND
Backend Passo 1. Defina seus modelos de dados no Designer de modelos de dados de back-end. Pode pensar em cada modelo como uma tabela na base de dados SQL (com relações). No AppMaster, os modelos de dados não são usados apenas para definir tabelas primárias do banco de dados, mas também como uma declaração de estrutura em todo o projeto. Por exemplo, se a sua lógica utilizar o modelo de dados "Utilizador", pode ter a certeza de que qualquer estrutura desse tipo terá o mesmo conjunto de campos.
Clique com o botão direito do rato na tela do Designer de modelos de dados para criar um novo modelo e arraste de uma borda de modelo para outra borda de modelo para criar uma relação. Clique no campo da relação ou do modelo para o editar.
Tenha cuidado com as propriedades de campo como Unique, Not NULL ou Index: se aplicar a política NOT NULL ou Unique à base de dados existente com valores vazios ou duplicados, a migração do esquema de BD acabará por falhar.
Backend Passo 2. Crie processos empresariais para a sua aplicação. O Processo Comercial (BP) em termos da Plataforma AppMaster é apenas um termo único para uma Função na programação clássica.
Cada BP de backend tem 2 blocos obrigatórios: Início e Fim. Se precisar de passar dados para o seu BP, tem de definir variáveis no bloco Início (funcionará como argumentos em funções da programação clássica) e ligá-las aos seus blocos dentro do BP.
Para devolver dados do BP, pode adicionar variáveis ao bloco Fim (como o retorno nas funções da programação clássica).
Existem 2 tipos de ligações entre blocos BP:
- linhas sólidas com setas azuis, chamadas conexões de fluxo, que definem a ordem de execução dos blocos (qual bloco deve ser executado em seguida)
- linhas finas de várias cores chamadas Conexões de Variáveis que definem os vínculos de dados (de onde obter dados - conexão de dados entre blocos BP). Cada cor corresponde a um tipo de dados diferente
Normalmente, os locais nos blocos BP para conexões de fluxo ou variáveis são chamados de conectores. Todos os conectores no lado esquerdo do bloco são Conectores de Entrada (recebem Fluxo ou dados), e no lado direito são Conectores de Saída (passam Fluxo ou dados para frente).
Para criar uma ligação, tens de arrastar de um conetor para outro (arrasta entre os blocos que precisas de ligar).
Independentemente do lado a partir do qual começar a arrastar, formar-se-á uma ligação.
O editor BP verifica automaticamente os tipos de dados para as ligações variáveis e não permite a ligação se os tipos de dados não forem idênticos, evitando também quaisquer loops ou más ligações.
Pode chamar um BP a partir de outro - basta arrastar e largar o bloco apropriado do painel esquerdo. Utilizamos frequentemente esta abordagem para minimizar a complexidade da lógica e reutilizar a mesma lógica várias vezes no projeto.
Existem 2 tipos de variáveis nas aplicações backend que pode colocar no BP para armazenar dados temporariamente:
- Variáveis locais - para armazenar dados durante o ciclo de vida do BP atual (mais eficiente, apenas na memória)
- Variáveis globais - armazenam os seus dados durante o ciclo de vida da aplicação backend (também apenas na memória, serão repostas quando a aplicação for reiniciada)
Antes de poder utilizar a variável global arrastando-a do painel esquerdo do BP Editor, é necessário criar uma variável global utilizando uma secção da lógica de backend.
Se o seu BP precisa de ser chamado a partir de uma fonte externa via API (a partir da sua web, telemóvel, usando postman/curl, a partir de um sistema externo), precisa de anexar o BP ao endpoint.
Backend Passo 3. Criar endpoints. No AppMaster nós usamos a mesma abordagem clássica de API REST para endpoints. Embora o AppMaster suporte não apenas endpoints da API REST, mas também WebHooks e endpoints WSS, vamos nos concentrar no primeiro tipo.
Ao criar pontos de extremidade, siga o padrão da API REST em termos de métodos (GET, POST, PUT, PATCH, DELETE), cargas (use JSON) e URLs (sem caracteres não-ASCII, sem espaços, começa e termina com uma barra).
O processo de criação de pontos finais é muito simples e direto: seleccione o BP, defina o URL e o método REST e, se precisar de autorização para esses pontos finais, verifique as definições de middleware.
Quando os modelos de dados, os processos empresariais e os pontos finais estiverem prontos, é altura de publicar - prima o botão publicar! Normalmente, em menos de 30 segundos, a plataforma AppMaster pegará todos os seus blueprints (sim, na verdade, tudo o que você fez foi criar blueprints para o futuro software), gerará o código-fonte, compilará, empacotará na imagem docker e implantará na nuvem do AppMaster. Quando o processo de publicação estiver concluído, pode abrir a documentação da API REST (OpenAPI/Swagger) e testar os seus pontos finais com pedidos integrados no Swagger ou utilizando ferramentas de terceiros como o Postman ou o Insomnia.
IMPORTANTE. Se estiver a executar com a subscrição Learn & Explore, o nosso Daemon de poupança de recursos irá parar o seu contentor de aplicações após 30 minutos de inatividade no Studio. Para executar novamente - clique no botão de alternância Implantar plano ou publique mais uma vez.
APLICAÇÕES WEB
Quando o backend estiver devidamente planeado e criado, é altura de passar para o frontend. Vamos começar com a aplicação Web.
WebApp Etapa 1. Crie uma aplicação web se ainda não tiver uma no projeto. A partir de agora, temos 2 tipos de Designers de aplicações Web: actuais e novos (em beta). A principal diferença é a quantidade de personalização. O WebApp Designer da geração atual tem capacidades de personalização da IU muito limitadas, mas é simples e fácil de construir interfaces IU padrão de painéis de administração e portais de clientes. O novo (atualmente em fase beta) tem uma personalização completa do aspeto e preenchimento da IU - uma abordagem flexbox com layouts de SPA (Vue, React way). Ambos os designers têm processos de negócio integrados, incluindo accionadores e uma série de blocos úteis.
WebApp Passo 2. Comece a desenhar a IU da sua aplicação Web arrastando e largando elementos da IU do painel superior (designer atual) ou do painel esquerdo (novo designer). Para alguns elementos que têm enumeração no interior (como tabelas e listas), terá de selecionar o modelo de dados durante a fase inicial de largada para ajustar automaticamente o elemento.
Existem 2 tipos de processos empresariais nas Aplicações Web: Acionador e Padrão. Os accionadores estão disponíveis para cada elemento da interface do utilizador e para o âmbito de toda a aplicação (accionadores de aplicações). Para aceder ao acionador do elemento da interface do utilizador, seleccione o elemento e, no separador PN, crie um. Ao contrário dos BPs padrão, os accionadores têm vários blocos de início: um bloco para cada evento e nenhum bloco de fim. Uma vez que os accionadores nunca devolvem quaisquer valores, não são necessários blocos de fim. Continua a ser possível criar processos empresariais padrão em aplicações Web, mas a única forma de os executar é chamá-los a partir dos accionadores. Essa é uma boa abordagem para mover a lógica usada com freqüência para os BPs da Web padrão e chamá-la apenas a partir dos acionadores.
IMPORTANTE. Lembre-se que os BPs de backend serão executados dentro de aplicações de backend, os BPs de aplicações Web serão executados nos browsers dos utilizadores e minimizar a carga de trabalho da Web será benéfico para a experiência do utilizador.
Existem alguns gatilhos de nível de aplicativo muito importantes. Por exemplo, o App onLaunch dispara quando um aplicativo no navegador acaba de ser iniciado. Este é o melhor local para verificar se o utilizador está autenticado e, se não estiver, redirecionar para a página correcta (se precisar de autenticação).
Não se esqueça de guardar o esquema da sua aplicação Web e de publicar o seu projeto para ver as alterações.
APLICAÇÕES MÓVEIS
Quando precisar de criar uma aplicação móvel, o processo é o mesmo que o de uma aplicação Web: crie ecrãs, coloque elementos de IU, crie accionadores de elementos de IU, ajuste o acionador App onLaunch e está pronto a começar. Não há pré-visualização na web para os aplicativos móveis AppMaster, mas você pode instalar o aplicativo móvel AppMaster Developer para Android e IOS para pré-visualizar seus aplicativos com todos os recursos relacionados ao hardware, como BLE, NFC e etc.
Quando tiver terminado o desenvolvimento da sua aplicação móvel e esta estiver pronta para ser publicada, o AppMaster tem um assistente de publicação especial disponível no menu de contexto na lista de todas as aplicações móveis do projeto. Para o Android, o AppMaster gera ficheiros APK e AAB que podem ser publicados.
RESUMO
O AppMaster é um grande IDE onde pode planear as suas aplicações com planos avançados no Data Models Designer, Business Process Editor, Web e Mobile Designers.
PERGUNTAS FREQUENTES
Por que precisamos de projetos com vários aplicativos por projeto?
O AppMaster usa uma arquitetura cliente-servidor e não um monólito. Há muitos casos em que você pode querer vários aplicativos por projeto quando você precisa separar recursos:
- Projetos complexos: como táxi quando um aplicativo para passageiros e outro para motoristas trabalham com o mesmo backend
- Criar várias aplicações de backend para equilibrar a carga de trabalho e tornar as alterações mais fáceis e menos arriscadas
Embora já seja possível criar várias aplicações Web e móveis por projeto, ainda estamos a trabalhar na introdução de várias aplicações de backend por projeto.
Quais são as vantagens e desvantagens das aplicações geradas?
As vantagens mais óbvias e visíveis são um desempenho significativamente mais elevado, a escalabilidade, a capacidade de obter ficheiros binários para serem executados no local e o código-fonte para passar nas certificações e auditorias. Utilizamos a versão mais recente da linguagem de programação Go para gerar aplicações de backend. A linguagem Go proporciona um elevado desempenho das aplicações compiladas, compilação cruzada para vários sistemas operativos e arquitecturas de CPU e simplicidade geral, mantendo-se flexível.
Os inconvenientes mais comuns são a necessidade de voltar a gerar e construir a aplicação sempre que se introduzem alterações nas plantas, o que normalmente demora cerca de 35-45 segundos em média para projectos de média dimensão. Além disso, há alguma complexidade e custos adicionais, uma vez que precisamos de executar aplicações na nossa nuvem: cada aplicação que executamos no contentor docker consome CPU e RAM (mesmo que esteja inativa) e requer a migração do esquema de BD (fazemo-lo automaticamente).
Mas, em geral, as aplicações geradas por código funcionam tão bem como as criadas com programação clássica.
Que tecnologia é utilizada nas aplicações Web?
Geramos aplicações Web utilizando a estrutura Vue3 com TypeScript (TS). As aplicações Web funcionam numa combinação dos modos SPA e SSG. O Server-Side Rendering (SSR) será adicionado mais tarde e apenas para o novo designer de aplicações Web.
Que tecnologia é utilizada nas aplicações móveis?
As nossas aplicações móveis são construídas utilizando uma abordagem declarativa orientada para o backend: utilizamos uma base de código totalmente nativa (a mais nativa) de Swift e SwiftUI para IOS, Kotlin e Jetpack Compose para Android. Tecnicamente, as aplicações móveis carregam a configuração e os ecrãs através da rede, a pedido, utilizando JSON e Protobuf para obter o máximo desempenho. Esta abordagem tem muitas vantagens: pode alterar as aplicações em tempo real, sem necessidade de publicar versões actualizadas das aplicações na AppStore ou no Play Market, pode trabalhar completamente offline e tem acesso a todas as funcionalidades do hardware. Não utilizamos a tecnologia HTML/JS/ReactNative ou PWA nas nossas aplicações móveis. As aplicações móveis criadas no AppMaster têm de ser distribuídas através da AppStore, do Play Market ou de qualquer outra plataforma de distribuição (tecnicamente, é possível partilhar ficheiros apk/aab para Android, mas isso exige muito esforço).
Onde é que vocês alojam as aplicações por defeito?
Nós construímos o AppMaster Cloud em cima da infraestrutura AWS para oferecer o serviço mais confiável e escalável aos nossos clientes. Por padrão, os clientes com qualquer assinatura podem usar uma das 3 regiões principais: América do Norte (EUA), Europa (Alemanha) e Ásia. Para os planos de alojamento dedicado, temos a maioria das regiões AWS disponíveis (para além das localizações principais). Se precisar de um país específico para alojar a sua aplicação, informe-nos.
Como posso obter o pacote de aplicações, o binário ou o código-fonte das minhas aplicações?
Para obter ficheiros binários ou pacotes, tem de ter, pelo menos, uma subscrição Business. As aplicações de backend podem ser descarregadas da loja de artefactos como ficheiros binários ou obtidas através de docker pull do nosso registo (como o Docker Hub). Os pacotes móveis e da Web também podem ser baixados do repositório de artefatos. Pode descarregar pacotes de aplicações móveis com qualquer subscrição, exceto Learn & Explore. Para obter o código-fonte do aplicativo, é necessário ter uma assinatura corporativa. Com uma subscrição empresarial, obterá um código-fonte completo de aplicações backend e Web, mas uma base de código limitada de aplicações móveis, uma vez que utilizamos uma abordagem orientada para o backend.
Qual é a diferença entre um Modelo e um Modelo Virtual?
Utilizamos o termo Modelo para indicar a estrutura para a qual criaremos tabelas numa base de dados e pré-criaremos automaticamente blocos de BD para efetuar operações básicas nessa tabela da base de dados, como pesquisar, criar registos, etc. Os modelos virtuais são a mesma coisa, exceto que não criaremos tabelas e não haverá blocos de BD. Os modelos virtuais eram uma das funcionalidades mais desejadas pela maioria dos programadores. O caso de uso mais frequente para modelos virtuais é quando se precisa criar uma estrutura (como Objetos em JS ou JSON) e usá-la para requisições externas, elementos de UI ou endpoints. É curioso que os modelos que são definidos nas aplicações de backend apareçam automaticamente nas aplicações Web e móveis como virtuais: nas aplicações Web e móveis é necessário conhecer qualquer estrutura de dados para poder trabalhar com ela.
Como posso trabalhar com modelos em processos empresariais? Como extrair campos, etc.
Para cada modelo, geramos previamente os blocos Make e Expand. O bloco Make vai juntar campos ao registo do modelo e o bloco Expand vai extrair campos do registo do modelo. Tenha em atenção que estes blocos não alteram os dados iniciais que são passados para a entrada dos blocos.
Como é que posso definir valores para as variáveis locais ou globais?
Todos os blocos que utilizar não alteram os dados iniciais quando os passa para a entrada. O único bloco que altera os dados é o Set Variable: ligue a variável e o valor e, após a execução do bloco, obterá o seu valor dentro da variável. As variáveis globais em aplicações móveis e Web podem ter persistência e sobreviverão ao reinício da aplicação se o sinalizador apropriado estiver definido.
Como posso fazer uma chamada de API para um sistema externo?
A melhor forma de efetuar pedidos a sistemas externos é a partir da sua aplicação backend. Ao fazê-lo, terá mais controlo sobre os dados e a segurança. Há duas maneiras de o fazer:
- Utilizar o bloco de pedidos HTTP é a forma mais fácil de o fazer, podendo utilizá-lo em qualquer BP de backend
- Usando o Designer de API externa para criar uma solicitação primeiro e depois usar blocos criados dentro de seus BPs.
Embora seja possível usar o bloco de solicitação HTTP para chamar sistemas externos não apenas em aplicativos de back-end, mas também na Web e em dispositivos móveis, é preciso ter um motivo para fazer isso: quando seu aplicativo de front-end quiser fazer uma chamada para o dispositivo na rede local, ou se isso for projetado para o sistema de terceiros.
Que tipos de pedidos e protocolos são suportados ao chamar sistemas externos?
A partir de agora, suportamos pedidos de API REST com cargas JSON ou XML, texto simples ou cargas binárias. O gRPC ainda não é suportado, mas estamos a trabalhar ativamente na sua introdução nos próximos meses com o nosso novíssimo Designer de API externa.
Os aplicativos criados pelo AppMaster suportam WebSockets?
Sim, é possível criar pontos de extremidade WSS no aplicativo backend e usá-los para se comunicar com aplicativos da Web ou móveis. Além disso, é possível definir suas próprias estruturas de carga útil usando modelos durante a criação do ponto de extremidade WSS. A comunicação com sistemas externos usando WebSockets não está implementada.
Como posso chamar o ponto de extremidade de backend a partir de uma aplicação Web ou móvel?
Para cada ponto de extremidade que criou na aplicação de backend, a plataforma cria um bloco de pedido de servidorpara aplicações Web e móveis. Basta colocar esse bloco em qualquer acionador e chamá-lo. Pode monitorizar a execução dos blocos de Pedidos de Servidor na consola de desenvolvimento do browser, separador Pedidos de Rede. Nas aplicações móveis, pode utilizar registos (deve ser ativado primeiro nas definições da AppMaster Developer App).
Posso criar autenticação e registo personalizados?
Claro, você pode desativar completamente o módulo de autenticação integrado e criar uma solução totalmente personalizada. Terá de criar um BP separado na aplicação backend que irá lidar com a tração do token de autenticação (normalmente a partir do cabeçalho do pedido) e verificar de acordo com as suas regras. Pode obter os cabeçalhos dos pedidos utilizando o bloco BP Get Request Headers. Tenha em atenção que, assim que desativar a autenticação integrada, não poderá utilizar o bloco Obter utilizador atual. Além disso, é possível usar qualquer ID, número de telefone ou outro identificador em vez do email com o módulo de autenticação padrão.
Existe alguma maneira de criar operações thread-safe para contadores confiáveis e outros casos de execução ordenada?
O AppMaster suporta um modo de thread único para a execução do processo comercial quando todas as chamadas do processo comercial são executadas numa ordem estrita, uma de cada vez. Este modo pode ter uma penalização do desempenho em situações de carga de trabalho elevada, mas na maioria dos casos, não causa qualquer degradação significativa do desempenho. Tenha em atenção que a pilha de chamadas (fila de espera) deste modo é limitada.
2FA com SMS, e-mail ou OTP?
Sim, pode ajustar a sua lógica de autenticação para incluir métodos 2FA. Para utilizar SMS ou correio eletrónico, tem de ligar um fornecedor externo como o Twilio. A maneira mais fácil é estender as sessões e incluir campos adicionais para controlar a 2FA na sessão. No terceiro trimestre de 2023, apresentaremos um módulo OTP baseado em tempo que funcionará com o Google e o Microsoft Authenticator.
Posso usar o backend gerado pelo AppMaster com outros aplicativos da Web ou móveis?
Sim, os aplicativos de back-end gerados pelo AppMaster têm pontos de extremidade da API REST padrão. Para cada aplicativo, a documentação da API REST (OpenAPI/Swagger) é gerada automaticamente e servida em um ponto de extremidade separado.
Posso utilizar modelos para criar projectos ou aplicações?
Ainda não temos modelos, mas isso é algo que lançaremos num futuro próximo. Os projectos AppMaster são mais complexos do que o WebFlow ou o Bubble e precisamos de mais tempo para os implementar.
Que tipo de base de dados o AppMaster suporta?
A aplicação backend gerada pelo AppMaster funciona com qualquer banco de dados compatível com PostgreSQL a partir do PG12, mas recomendamos usar a última versão disponível do PostgreSQL DB (15.3 no momento deste documento). O suporte para MSSQL, MariaDB, MySQL e SQLite está planeado e será adicionado no final de 2023/início de 2024.
Como posso aceder diretamente à base de dados para editar registos?
O AppMaster não oferece suporte ao acesso direto ao banco de dados para aplicativos hospedados no AppMaster Cloud. Se você usa hospedagem local, você pode acessar o banco de dados usando qualquer ferramenta visual como PGAdmin ou usando a ferramenta de linha de comando pgsql. No futuro, adicionaremos uma funcionalidade que permitirá aos clientes editar a BD diretamente.
Existe alguma colaboração em tempo real? Podemos trabalhar em equipa no mesmo projeto?
Só temos colaboração em tempo real no novo web designer. O novo web designer (beta) utiliza rascunhos de rede com o protocolo CRDT (Conflict-free Replicated Data Type Protocol) para abranger todos os casos de utilização e permitir a gestão do estado (Ctrl+Z, reversão de operações). No futuro, o CRDT será gradualmente integrado no editor BP e no Designer de modelos de dados, passo a passo. Se precisar de trabalhar em equipa, não edite o esquema do modelo de dados, o mesmo BP ou a mesma aplicação Web/Móvel, uma vez que isso pode levar à perda de dados.
Que funcionalidades importantes poderão faltar ao AppMaster?
- Visual SQL Designer. Embora a maioria das operações básicas, como pesquisa com filtros e junções, obter um registo por id, atualização, correção, eliminação e eliminação suave sejam suportadas, mas para uma melhor flexibilidade e desempenho, estamos a trabalhar no Visual SQL Designer e será lançado em outubro de 2023.
- Microsserviços de backend. Estamos a trabalhar ativamente na implementação de várias aplicações de backend por projeto. No momento, você pode criar apenas um aplicativo de back-end por projeto.
- Ainda não há SSR para aplicativos Web. Para os sites e aplicativos da Web mais altamente otimizados, o SSR adiciona benefícios adicionais para SEO. ETA Nov-2023.
- Suporte a gRPC para solicitações de API externas. Planeamos adicionar gRPC com carga útil protobuf e opções de compressão para alargar as possibilidades de interligação entre sistemas.
- Modelos de projectos, aplicações Web e móveis. Estamos a trabalhar na introdução de modelos. Como primeiro passo, adicionaremos modelos de aplicações Web em setembro de 2023. Os modelos de projectos completos ainda não têm data prevista de entrega.
