Als je al ervaring hebt met klassiek programmeren of een ander no-code/low-code platform, zullen veel concepten je bekend voorkomen.
In tegenstelling tot andere no-code en low-code oplossingen, is AppMaster gebouwd met een klassieke benadering van het bouwen van applicaties. Het basisitem in AppMaster is een project, niet een applicatie zoals in andere platformen. Projecten kunnen bestaan uit meerdere backend-, web- en mobiele applicaties. De architectuur van de oplossing - client-server (geen monoliet zoals in Bubble of vergelijkbare platforms).
Als je overstapt van andere no-code platforms, houd er dan rekening mee dat je in AppMaster backend, web en mobiel apart creëert met verschillende platformtools. Een van de meest frustrerende momenten voor dergelijke gebruikers is om te onthouden dat je aparte applicaties moet maken en daar logica in moet bouwen.
Hoe te beginnen?
Voor de meeste projecten moet je backend en web, of backend en mobiel of zelfs alle soorten applicaties bouwen.
BELANGRIJK. Zorg ervoor dat je het grootste deel van je logica in de backendapplicatie implementeert. Plaats nooit belangrijke logica in de web- of mobiele applicaties waar je geen controle over hebt. Frontend is alleen bedoeld voor datavisualisatie en het verzamelen van informatie op basis van gebruikersinvoer.
De meest eenvoudige manier is om te beginnen met het maken van een backendtoepassing.
BACKEND-TOEPASSINGEN
Backend Stap 1. Definieer je datamodellen in Backend Data Models Designer. Je kunt elk model zien als een tabel in de SQL database (met relaties). In AppMaster worden datamodellen niet alleen gebruikt om primaire databasetabellen te definiëren, maar ook als een structuurverklaring voor het hele project. Als uw logica bijvoorbeeld het gegevensmodel 'Gebruiker' gebruikt, kunt u er zeker van zijn dat elke structuur van dat type dezelfde set velden zal hebben.
Klik met de rechtermuisknop op het canvas van de Data Models Designer om een nieuw model te maken en sleep van de ene modelrand naar de andere modelrand om een relatie te maken. Klik op de relatie of het modelveld om het te bewerken.
Wees voorzichtig met veldeigenschappen zoals Uniek, Niet NULL of Index: als je een NIET NULL of Uniek beleid toepast op de bestaande database met lege of dubbele waarden, zal de migratie van het DB-schema uiteindelijk mislukken.
Backend Stap 2. Creëer bedrijfsprocessen voor je applicatie. Bedrijfsproces (BP) in termen van AppMaster Platform is gewoon een unieke term voor een Functie in klassiek programmeren.
Elke backend BP heeft 2 verplichte blokken: Start en Einde. Als je gegevens moet doorgeven aan je BP, moet je variabelen definiëren in het Start-blok (het werkt als argumenten in functies uit het klassieke programmeren) en ze verbinden met je blokken in de BP.
Om gegevens terug te sturen van de BP kunt u variabelen toevoegen aan het End-blok (zoals return in functies van klassieke programmering).
Er zijn 2 soorten verbindingen tussen BP-blokken:
- ononderbroken blauwe pijllijn genaamd Flow Connections en definieert de volgorde van blokuitvoering (welk blok moet als volgende worden uitgevoerd)
- dunne lijnen met meerdere kleuren, Variable Connections genaamd, die de gegevensbindingen definiëren (van waar gegevens moeten komen - gegevensverbinding tussen BP-blokken). Elke kleur is een ander gegevenstype
Gewoonlijk worden de plaatsen in BP-blokken voor Flow- of Variabele-verbindingen connectors genoemd. Alle connectors aan de linkerkant van het blok zijn In Connectors (ontvangt Flow of gegevens), en aan de rechterkant zijn Out Connectors (geeft Flow of gegevens door).
Om een verbinding te maken, sleep je van de ene connector naar de andere (sleep tussen blokken die je moet verbinden).
Het maakt niet uit vanaf welke kant je begint te slepen, het zal een verbinding vormen.
BP editor controleert automatisch datatypes voor Variabele Verbindingen en zal je niet laten verbinden als datatypes niet identiek zijn, het zal ook lussen of slechte verbindingen voorkomen.
U kunt een BP aanroepen vanuit een andere BP - sleep gewoon het juiste blok vanuit het linkerpaneel. We gebruiken deze aanpak vaak om de complexiteit van de logica te minimaliseren en dezelfde logica meerdere keren in het project te hergebruiken.
Er zijn 2 soorten variabelen in de backend applicaties die je in de BP kunt plaatsen om tijdelijk gegevens op te slaan:
- Lokale variabelen - om gegevens op te slaan tijdens de levenscyclus van de huidige BP (meest efficiënt, alleen in het geheugen)
- Globale variabelen - om je gegevens op te slaan tijdens de levenscyclus van de backendtoepassing (ook alleen in het geheugen, wordt gereset zodra de app opnieuw wordt gestart)
Voordat je globale variabelen kunt gebruiken door ze te slepen vanuit het linkerpaneel van de BP-editor, moet je er een maken met behulp van een deel van de backend logica.
Als je BP moet worden aangeroepen vanaf een externe bron via API (vanaf je web, mobiel, met postman/curl, vanaf een extern systeem), moet je BP koppelen aan het eindpunt.
Backend stap 3. Eindpunten maken. In AppMaster gebruiken we dezelfde klassieke REST API benadering voor endpoints. Hoewel AppMaster niet alleen REST API eindpunten ondersteunt, maar ook WebHooks en WSS eindpunten, zullen we ons richten op het eerste type.
Houd je bij het maken van endpoints aan de REST API-standaard wat betreft methoden (GET, POST, PUT, PATCH, DELETE), payloads (gebruik JSON) en URL's (geen niet-ASCII-tekens, geen spaties, begint en eindigt met een schuine streep).
Het proces om eindpunten aan te maken is heel eenvoudig en rechttoe rechtaan: selecteer BP, definieer URL en REST-methode, en als je autorisatie nodig hebt voor die eindpunten - controleer dan de middleware-instellingen.
Zodra de datamodellen, bedrijfsprocessen en endpoints klaar zijn, is het tijd om te publiceren - druk op de publish knop! Gewoonlijk zal het AppMaster Platform in minder dan 30 seconden al uw blauwdrukken nemen (ja, eigenlijk is alles wat u hebt gedaan het maken van blauwdrukken voor de toekomstige software), broncode genereren, compileren, inpakken in een docker image en deployen naar de AppMaster cloud. Als het publicatieproces is voltooid, kunt u REST API-documentatie (OpenAPI/Swagger) openen en uw eindpunten testen met de ingebouwde Swagger-verzoeken of met hulpmiddelen van derden zoals Postman of Insomnia.
BELANGRIJK. Als u met een Learn & Explore-abonnement werkt, stopt onze Resource Saving Daemon uw applicatiecontainer na 30 minuten inactiviteit in Studio. Om opnieuw te starten - klik op de Deploy Plan toggle of publiceer opnieuw.
WEBTOEPASSINGEN
Als de backend goed is gepland en gemaakt, is het tijd om naar de frontend te gaan. We beginnen met de webapplicatie.
WebApp Stap 1. Maak een webapplicatie als je die nog niet in het project hebt. Op dit moment hebben we 2 soorten webapplicatieontwerpers: huidige en nieuwe (in bèta). Het grootste verschil is de hoeveelheid aanpassingen. De huidige generatie WebApp Designer heeft zeer beperkte UI aanpassingsmogelijkheden, maar eenvoudige en gemakkelijk te bouwen standaard UI interfaces van admin panels en klantportalen. De nieuwe (momenteel in beta) heeft een volledige aanpassing van de UI look en fill - een flexbox aanpak met lay-outs van SPA (Vue, React manier). Beide ontwerpers hebben bedrijfsprocessen ingebouwd, inclusief triggers en een heleboel handige blokken.
WebApp Stap 2. Begin met het ontwerpen van de UI van je webapplicatie door UI-elementen te slepen vanuit het bovenste paneel (huidige designer) of linker paneel (nieuwe designer). Voor sommige elementen die opsommingen bevatten (zoals tabellen en lijsten), moet je het datamodel selecteren tijdens de eerste drop-fase om het element automatisch aan te passen.
Er zijn 2 soorten bedrijfsprocessen in Webapplicaties: Trigger en Standaard. Triggers zijn beschikbaar voor elk UI-element en voor applicatiebreed bereik (app-triggers). Om de trigger van een UI-element te openen, selecteer je het element en maak je er een aan op het tabblad BP. In tegenstelling tot standaard BP's hebben triggers meerdere startblokken: één blok voor elke gebeurtenis en geen eindblok. Aangezien triggers nooit waarden teruggeven, zijn er geen eindblokken nodig. Je kunt nog steeds standaard bedrijfsprocessen aanmaken in webapplicaties, maar de enige manier om ze uit te voeren is door ze aan te roepen vanuit de triggers. Dat is een goede aanpak om veelgebruikte logica te verplaatsen naar de standaard web BP's en ze gewoon aan te roepen vanuit triggers.
BELANGRIJK. Onthoud dat backend BP's zullen draaien in backend applicaties, terwijl web app BP's zullen draaien in de browsers van de gebruikers, en het minimaliseren van de web werklast zal de gebruikerservaring ten goede komen.
Er zijn een paar zeer belangrijke triggers op applicatieniveau. App onLaunch bijvoorbeeld vuurt af wanneer een applicatie in de browser net is gestart. Dat is de beste plek om te controleren of je gebruiker is geauthenticeerd en, zo niet, om te leiden naar de juiste pagina (als je al auth nodig hebt).
Vergeet niet het schema van je webapplicatie op te slaan en je project te publiceren om wijzigingen te bekijken.
MOBIELE TOEPASSINGEN
Als je een mobiele applicatie moet maken, is het proces hetzelfde als bij een webapplicatie: schermen maken, UI-elementen plaatsen, UI-elementen triggers maken, App onLaunch trigger aanpassen en je bent klaar om te gaan. Er is geen web preview voor AppMaster mobiele applicaties, maar je kunt de AppMaster Developer mobiele applicatie voor Android en IOS installeren om een live preview van je apps te bekijken met alle hardware-gerelateerde functies zoals BLE, NFC enz.
Als je klaar bent met het ontwikkelen van je mobiele app en deze klaar is om gepubliceerd te worden, heeft AppMaster een speciale publicatiewizard die beschikbaar is via het contextmenu in de lijst van alle mobiele applicaties in het project. Voor Android genereert AppMaster APK- en AAB-bestanden die kunnen worden.
SAMENVATTING
AppMaster is een grote IDE waar je je applicaties kunt plannen met geavanceerde blauwdrukken in Data Models Designer, Business Process Editor, Web en Mobile Designers.
FAQ
Waarom zijn er projecten nodig met meerdere apps per project?
AppMaster gebruikt een client-server architectuur en geen monolith. Er zijn veel gevallen waarin je meerdere apps per project nodig hebt om functies te scheiden:
- Complexe projecten: zoals taxi als één app voor passagiers en één voor chauffeurs werken met dezelfde backend
- Maak meerdere backend-applicaties om de werklast in balans te houden en wijzigingen eenvoudig en minder riskant te maken
Hoewel je al meerdere web- en mobiele apps per project kunt maken, werken we nog aan de introductie van meerdere back-end applicaties per project.
Wat zijn de voor- en nadelen van gegenereerde applicaties?
De meest voor de hand liggende en merkbare voordelen zijn aanzienlijk hogere prestaties, schaalbaarheid, de mogelijkheid om binaire bestanden te krijgen om on-premise te draaien en broncode om certificeringen en audits te doorstaan. We gebruiken de nieuwste versie van de programmeertaal Go om back-end apps te genereren. Go biedt veel prestaties van de gecompileerde applicaties, cross-compilatie voor meerdere OS- en CPU-architecturen en algehele eenvoud door flexibel te blijven.
De meest voorkomende nadelen zijn de vereiste om de app elke keer opnieuw te genereren en te bouwen als je wijzigingen aanbrengt in je blauwdrukken en dit duurt gemiddeld zo'n 35-45 seconden voor middelgrote projecten. Ook zijn er wat extra complexiteit en kosten omdat we apps in onze cloud moeten draaien: elke app die we in de docker container draaien verbruikt CPU en RAM (zelfs als deze stationair draait), en vereist DB schema migratie (we doen dit automatisch).
Maar over het algemeen werken applicaties die met code zijn gemaakt net zo goed als applicaties die met klassiek programmeren zijn gemaakt.
Welke technologie wordt gebruikt in webapplicaties?
We genereren webapplicaties met behulp van het Vue3 framework met TypeScript (TS). Webapplicaties werken in een combinatie van SPA- en SSG-modi. Server-Side Rendering (SSR) wordt later toegevoegd en alleen voor nieuwe webdesigners.
Welke technologie wordt gebruikt in mobiele applicaties?
Onze mobiele applicaties worden gebouwd met behulp van een declaratieve backend-gedreven aanpak: we gebruiken een volledig native (de meest native) codebase van Swift en SwiftUI voor IOS, Kotlin en Jetpack Compose voor Android. Technisch gezien laden mobiele applicaties on demand configuraties en schermen via het netwerk met behulp van JSON en Protobuf voor maximale prestaties. Deze aanpak heeft veel voordelen: je kunt applicaties in realtime wijzigen zonder dat je bijgewerkte versies van applicaties hoeft te publiceren in de AppStore of Play Market, je kunt volledig offline werken en je hebt toegang tot alle hardwarefuncties. We gebruiken geen HTML/JS/ReactNative of PWA-technologie in onze mobiele applicaties. Mobiele apps die zijn gemaakt in AppMaster moeten worden gedistribueerd via AppStore, Play Market of een ander distributieplatform (technisch gezien kun je apk/aab-bestanden delen voor Android, maar dat kost veel moeite).
Waar hosten jullie standaard applicaties?
We hebben AppMaster Cloud gebouwd bovenop de AWS-infrastructuur om onze klanten de meest betrouwbare en schaalbare service te bieden. Standaard kunnen klanten met elk abonnement een van de 3 kernregio's gebruiken: Noord-Amerika (VS), Europa (Duitsland), Azië. Voor dedicated hostingpakketten hebben we de meeste AWS-regio's beschikbaar (buiten de kernlocaties). Als u een specifiek land nodig hebt om uw applicatie te hosten - laat het ons weten.
Hoe kan ik de applicatiebundel, binaire bestanden of broncode van mijn applicaties krijgen?
Om binaire bestanden of bundels te krijgen, moet je ten minste een Business-abonnement hebben. Backend applicaties kunnen worden gedownload uit de artifact store als binaire bestanden of worden opgehaald via docker pull uit ons register (zoals Docker Hub). Mobiele en webbundels kunnen ook worden gedownload vanuit de artifact store. Je kunt mobiele app bundels downloaden met elk abonnement behalve Learn & Explore. Om de broncode van de applicatie te krijgen, moet je een enterprise abonnement hebben. Met een enterprise-abonnement krijg je de volledige broncode van backend- en webapplicaties, maar een beperkte codebase van mobiele apps omdat we daar een backend-gedreven aanpak gebruiken.
Wat is het verschil tussen een Model en een Virtueel Model?
We gebruiken de term Model om te verwijzen naar de structuur waarvoor we tabellen in een database maken en automatisch DB-blokken aanmaken om basisbewerkingen op die databasetabel uit te voeren, zoals zoeken, records aanmaken, enzovoort. Virtuele modellen zijn hetzelfde, behalve dat we geen tabellen aanmaken en er geen DB-blokken zijn. Virtuele modellen was een van de meest gevraagde functies door de meeste ontwikkelaars. De meest voorkomende use case voor virtuele modellen is wanneer je een structuur moet maken (zoals objecten in JS of JSON) en deze moet gebruiken voor externe verzoeken, UI-elementen of eindpunten. Het is merkwaardig dat modellen die zijn gedefinieerd in back-end applicaties automatisch als virtueel worden weergegeven in web- en mobiele apps: in web- en mobiele apps moet je elke gegevensstructuur kennen om ermee te kunnen werken.
Hoe kan ik met modellen werken in bedrijfsprocessen? Hoe extraheer ik velden enz.
Voor elk model maken we vooraf blokken Make en Expand. Make verzamelt velden in het Model Record, Expand haalt velden uit het Model Record. Houd er rekening mee dat deze blokken de initiële gegevens die worden doorgegeven aan de invoer van de blokken niet wijzigen.
Hoe kan ik een waarde instellen voor de lokale of globale variabelen?
Alle blokken die u zult gebruiken, zullen de initiële gegevens niet wijzigen wanneer u deze doorgeeft aan de invoer. Het enige blok dat gegevens wijzigt is Set Variable: verbind variabele en waarde en na uitvoering van het blok krijgt u uw waarde in de variabele. Globale variabelen in mobiele en webapplicaties kunnen persistentie hebben en overleven de herstart van de applicatie als de juiste vlag is ingesteld.
Hoe kan ik een API-aanroep doen naar een extern systeem?
De beste manier om requests te maken naar externe systemen is vanuit je backend applicatie. Door dit te doen, krijg je meer controle over gegevens en beveiliging. Er zijn twee manieren om dit te doen:
- HTTP Request block gebruiken is de eenvoudigste manier, je kunt het in elke backend BP gebruiken.
- Gebruik van External API Designer om eerst een verzoek te maken en gebruik dan crafted blokken in je BP's.
Hoewel je HTTP Request blok kunt gebruiken om externe systemen aan te roepen, niet alleen in backend applicaties maar ook in web en mobiel, moet je wel een reden hebben om het te doen: als je frontend app een oproep wil doen naar het apparaat in het lokale netwerk, of als dat het ontwerp is voor het systeem van de derde partij.
Welke soorten verzoeken en protocollen worden ondersteund bij het aanroepen van externe systemen?
Op dit moment ondersteunen we REST API-aanvragen met JSON of XML payloads, platte tekst of binaire payloads. gRPC wordt nog niet ondersteund, maar we werken er actief aan om dit in de komende maanden te introduceren met onze gloednieuwe External API Designer.
Ondersteunen door AppMaster gemaakte applicaties WebSockets?
Ja, u kunt WSS endpoints aanmaken in de backend applicatie en deze gebruiken om te communiceren binnen web- of mobiele apps. U kunt ook uw eigen payloadstructuren definiëren met behulp van modellen tijdens het maken van het WSS-eindpunt. Communiceren met externe systemen via WebSockets is niet geïmplementeerd.
Hoe kan ik het backend endpoint aanroepen vanuit een web- of mobiele applicatie?
Voor elk eindpunt dat je hebt gemaakt in de back-end applicatie, maakt het platform een Server Request-blokvoor web- en mobiele apps. Plaats dat blok gewoon in een trigger en roep het aan. Je kunt de uitvoering van Server Request-blokken controleren in de ontwikkelaarsconsole van de browser, tabblad Netwerkverzoeken. In mobiele apps kunt u logboeken gebruiken (moet eerst worden ingeschakeld in de instellingen van AppMaster Developer App).
Kan ik aangepaste authenticatie en aanmelding maken?
Natuurlijk, u kunt de ingebouwde auth-module volledig uitschakelen en een volledig aangepaste oplossing maken. U moet een aparte BP maken in de back-end applicatie die de auth token tractie afhandelt (meestal uit de request header) en controleert volgens uw regels. Je kunt request headers krijgen door het BP-blok Get Request Headers te gebruiken. Houd er rekening mee dat als je ingebouwde auth uitschakelt, je het blok Get Current User niet meer kunt gebruiken. U kunt ook een ID, telefoonnummer of andere identificator gebruiken in plaats van e-mail met de standaard Auth-module.
Is er een manier om thread-veilige operaties te maken voor betrouwbare tellers en andere geordende uitvoeringsgevallen?
AppMaster ondersteunt een single-thread modus voor het uitvoeren van bedrijfsprocessen waarbij alle aanroepen van het bedrijfsproces in een strikte volgorde worden uitgevoerd, één voor één. Deze modus kan een prestatieverlies hebben voor situaties met hoge werkbelasting, maar in de meeste gevallen veroorzaakt het geen significante prestatievermindering. Houd er rekening mee dat de oproepstapel (wachtrij) van deze modus beperkt is.
2FA met SMS, e-mail of OTP?
Ja, je kunt je auth logica aanpassen om 2FA methodes toe te voegen. Om SMS of e-mail te gebruiken, moet je verbinding maken met een externe provider zoals Twilio. De eenvoudigste manier is om sessies uit te breiden en extra velden op te nemen om 2FA in de sessie te regelen. In Q3 2023 introduceren we een Time-based OTP module die zal werken met Google en Microsoft Authenticator.
Kan ik een door AppMaster gegenereerde backend gebruiken met andere web- of mobiele applicaties?
Ja, AppMaster gegenereerde backend applicaties hebben standaard REST API endpoints. Voor elke applicatie wordt automatisch REST API documentatie (OpenAPI/Swagger) gegenereerd en geserveerd op een apart eindpunt.
Kan ik sjablonen gebruiken om projecten of applicaties te maken?
We hebben nog geen templates, maar dat is iets wat we in de nabije toekomst zullen uitbrengen. AppMaster Projecten zijn complexer dan WebFlow of Bubble en we hebben meer tijd nodig om ze te implementeren.
Welk type database ondersteunt AppMaster?
AppMaster gegenereerde backend applicaties werken met alle PostgreSQL-compatibele databases vanaf PG12, maar we raden aan om de laatste beschikbare versie van PostgreSQL DB te gebruiken (15.3 op het moment van dit document). Ondersteuning voor MSSQL, MariaDB, MySQL en SQLite is gepland en zal eind 2023/begin 2024 worden toegevoegd.
Hoe krijg ik direct toegang tot de database om records te bewerken?
AppMaster ondersteunt geen directe DB-toegang voor applicaties die worden gehost in de AppMaster Cloud. Als u on-premise hosting gebruikt, kunt u toegang krijgen tot de DB met behulp van een visuele tool zoals PGAdmin of met behulp van pgsql command-line tool. In de toekomst zullen we een functie toevoegen waarmee klanten de DB direct kunnen bewerken.
Is er real-time samenwerking? Kunnen we als team aan hetzelfde project werken?
We hebben alleen real-time samenwerking in de nieuwe webdesigner. De nieuwe webdesigner (bèta) gebruikt netwerkontwerpen met Conflictvrij Replicated Data Type Protocol (CRDT) om alle gebruikssituaties te dekken en geeft statusbeheer (Ctrl+Z, operations rollback). We zullen CRDT in de toekomst stap voor stap uitrollen naar de BP editor en Data Models Designer. Als je in teamverband moet werken, bewerk dan alsjeblieft geen datamodel schema's, dezelfde BP of dezelfde Web/Mobile app omdat dit kan leiden tot dataverlies.
Welke belangrijke functies kan AppMaster missen?
- Visuele SQL-ontwerper. Hoewel de meeste basisbewerkingen zoals zoeken met filters en joins, een record krijgen op id, updaten, patchen, verwijderen en zacht verwijderen worden ondersteund, maar voor betere flexibiliteit en prestaties, werken we aan Visual SQL Designer en het zal worden vrijgegeven in oktober 2023.
- Backend microservices. We werken actief aan het implementeren van meerdere backend applicaties per project. Vanaf nu kun je maar één backend-app per project maken.
- Nog geen SSR voor webapplicaties. Voor de meest geoptimaliseerde webapplicaties en websites voegt SSR extra voordelen voor SEO toe. ETA nov-2023.
- gRPC-ondersteuning voor externe API-verzoeken. We zijn van plan om gRPC met protobuf payload en compressieopties toe te voegen om de mogelijkheden voor interconnectie tussen systemen uit te breiden.
- Sjablonen van projecten, web- en mobiele applicaties. We werken aan de introductie van sjablonen. Als eerste stap zullen we in september 2023 sjablonen voor webapps toevoegen. De sjablonen voor hele projecten hebben nog geen ETA.