Table of Contents

Wizzdi Cloud User Guide


Welcome to the Wizzdi Cloud documentation. Wizzdi Cloud is a no-code system that aims to simplify the application development process. Hosted at, the platform is currently in beta and available for free.


  1. You Built It; You Own It: Unlike most no-code systems, Wizzdi Cloud doesn’t lock you in any way, take the created system, deploy it anywhere, or continue developing it using dependencies’ free pure code in standard development tools and practices.
  2. Wizzdi Cloud provides a comprehensive, no-code backend development platform. Here’s what it offers:
    1. Quality Assurance: The backends created are top-notch, aligning with industry standards.
    2. Flexibility: Even though Wizzdi Cloud is feature-rich, it’s not restrictive. If needed, any backend system built within can be further refined externally.
    3. Tailored Solutions: While the platform caters to a wide range of needs, specific requirements might arise based on an organization’s unique technical background. Wizzdi Cloud is designed to be a starting point, allowing for such external enhancements.
    4. Risk-Free: Choosing Wizzdi Cloud carries no risk. It serves as a robust foundation, ensuring that users have the flexibility to expand and enhance their projects as required.
  3. AI integration: Wizzdi Cloud has several features that allow for seamless integration with ChatGPT, including the ability to move from problem descriptions to diagrams.
  4. Deployment: Users can transition from diagrams to deployment on the Wizzdi customer high availability cluster without coding.
  5. UI Builder: A UI builder tool will be available in Q1 2024. Wizzdi Cloud User Interface builder is designed to create Flutter-based mobile and web applications.
  6. Hosting Options: The backend system can be hosted on-premises, a user’s cloud, or the Wizzdi Cloud. It includes a one-line Docker boot option for easy deployment on Linux, Windows, and Mac.
  7. Repository Integration: The platform integrates with known repositories like GitHub and Bitbucket.
  8. Development Patterns: Wizzdi Cloud supports multiple development strategies: full no-code development, a combination of no-code with traditional development, or using the no-code system as an assistant tool in the development process, allowing Wizzdi Cloud to contribute to the code base like any developer.
  9. Reusability: Wizzdi Cloud is intended to facilitate reuse on a broad scale. This encompasses projects created by both yourself and others using Wizzdi Cloud, as well as the ability to access available artifacts from private or public repositories such as Maven Central. Maven Central houses over one million software artifacts.


When starting Wizzdi

You will see a screen similar to this; you may sign up using your email and password or your Google/GitHub accounts.

Wizzdi Cloud Sign-in Sign-up

Main View

In the main view, you can search for your apps. Apps are arranged in Workspaces, and you can invite other users to your workspace while controlling their permissions.


When starting the system the first time, you will be offered a walkthrough of the system, where you will be guided in building a complete backend.  You can always start the walkthrough from the top right menu. When stopped, the current walkthrough can always be resumed.

Opening screen with a Walkthrough prompt

Populated with Apps

apps in the main view

App creation

Understanding an App within Wizzdi Cloud:

In the context of Wizzdi Cloud, an “App” represents a holistic software solution, encompassing its back-end and front-end facets.

  1. Back-end Components:
    • These form the engine room of your app, managing the underlying logic, databases, and integrations.
    • Deployment Flexibility: With just a click, these components can be deployed either on Wizzdi Cloud’s infrastructure, your cloud setup, an on-premises server, or even directly on a laptop.
  2. Front-end Components:
    • This refers to the user interface – what the end-users interact with.
    • Deployment Options: The front end can be rolled out on platforms like the Apple App Store or Google Play for mobile applications. Conversely, the front end is deployed for web apps as static files residing on the back-end infrastructure.
  3. UI Development & Integration:
    • While Wizzdi Cloud’s UI builder is in the pipeline, users aren’t limited in their choice of interface design tools. You can craft the UI using your preferred software and subsequently integrate it with Wizzdi Cloud, which can serve as a web-based front-end.
  4. API Exposures:
    • The deployed back-end doesn’t exist in isolation; it provides a REST API suite, allowing for flexible integrations and interactions with other software or systems.
    • For ease of understanding and testing these APIs, they are accessible via our integrated Swagger interface, offering a clear, interactive representation of the available endpoints.

In essence, Wizzdi Cloud offers a platform that encapsulates an app’s operational core (back-end) and user-facing layer (front-end), allowing developers and organizations a streamlined approach to app development and deployment.

Creating an App

Click on the + new APP button and fill in the required fields for the app.

new-app button

Once clicked, the Create New App dialog is presented; enter a name for the app.

The advanced section is discussed later in this document.

Create a new app.

The App creation may take a while (~30 seconds); thanks for being patient.

The App settings

The App Dialog



Approaches to System Development in Wizzdi Cloud

 Domain-First Approach

A domain-first approach emphasizes the importance of understanding the essence of the system you want to create. Here’s how it works:

  • Begin with the Basics: Using Wizzdi Cloud’s intuitive diagramming tools, you’ll begin by outlining your domain model. This means identifying the core entities or ‘Things’ that your system will interact with.
  • Intuitive for Domain Experts: The beauty of this approach is its accessibility to domain experts — those who understand the requirements of an application from a functional perspective rather than a technical one. Take, for instance, a school principal: She would intuitively know that managing a school involves entities like Class, Classroom, Teacher, Student, Subject, etc.
  • Seamless Backend Generation: Once you’ve established the entities and their interrelationships, Wizzdi Cloud takes over. A functional backend gets generated automatically, with all necessary APIs to manage these entities. This can be visually grasped when running the Walkthrough.

 Contract-First Approach

The contract-first method flips the script by focusing on user interaction first. Here’s the breakdown:

  • UI as the Starting Point: Instead of diving deep into the domain model, this approach starts with the user interface design. This design process inherently outlines the services that the backend needs to facilitate.
  • Service Definition through OpenAPI: Post UI design, the next step is usually defining the services. This often culminates in creating an OpenAPI document, a contract for what the backend should offer.
  • Direct Integration with Wizzdi Cloud: Wizzdi Cloud can directly import and recognize the OpenAPI document. Upon importing, a set of exposed APIs materializes in the system. Subsequent steps involve fleshing out these APIs — linking them to specific business logic, integrating with other systems, drawing up custom queries, and aligning them with the eventual domain model.

Whether you’re a domain expert wanting to shape a system around core entities or a designer aiming to sculpt backend services based on user interfaces, Wizzdi Cloud accommodates both avenues, providing a robust platform to bring your visions to fruition.


Navigating the App Overview in Wizzdi Cloud

1. App Properties Modification: Users can adjust a few app properties within the App Overview.  These properties are related to the code generated behind the scenes by Wizzdi Cloud. The running back-end app has user-defined properties that are managed here.

2. Static File Management for Front-end: For those crafting web-based applications, there’s a provision to upload and manage static files. These files constitute the front end, ranging from stylesheets and scripts to media assets.

3. Real-time App Statistics: The Overview section offers a bird’s-eye view of your app’s performance. This includes insightful statistics.

4. App Building Progress: For users to track their app development progress effectively, there’s a visual representation of the various stages in the app-building process. Not only does this indicate where you currently stand, but it also highlights areas you’ve successfully covered and what’s pending.

5. Deployment Status on Wizzdi Cloud: The Overview informs you about the app’s deployment status on Wizzdi Cloud. If deployed.

6. Accessible URLs: Once your app is live and running, two crucial URLs are made available to you:

  • App URL: This is the direct link to your application. Share it with end-users, stakeholders, or testers to grant them access to your app.
  • Swagger Interface URL: An integral tool for developers and integrators, the Swagger interface offers interactive documentation of your app’s REST API services. You can access, test, and understand the various server services and endpoints your application exposes through this URL.

Domain Model

1. Entity Diagrams: You can create multiple entity diagrams within the domain model section. These visual representations aid in understanding and designing the core architecture of your system.

  • Creation and Import Options: Entities can be manually created or imported from various sources, such as other projects.
  • Integration with ‘My Market Place’: You can import projects from Maven or local software repositories here. Once these software artifacts are added to your App dependencies, entities can be imported into diagrams, extended, or used as is in your backend.

2. Understanding Entities: Entities are foundational blocks of the domain model. They depict the key ‘Things’ or elements your App interacts with or manages.

  • Extensibility and Inheritance: An entity isn’t restricted to a standalone structure. They can extend or inherit from other entities, cascading down properties and features from their parent or super-entities. This inheritance mechanism allows for a layered and hierarchical design, minimizing redundancy.
  • Relationships and Associations: Entities can be interconnected in various ways, reflecting their real-world relationships. Wizzdi Cloud supports diverse relation types:
    • One-to-Many: A single instance of one entity relates to multiple instances of another.
    • Many-to-One: Multiple instances of one entity associated with a single instance of another.
    • Many-to-Many: Instances of one entity can relate to multiple instances of another and vice-versa.

3. Backend Representation: Entities typically translate to tables within a database in traditional backend structures for those who want a peek behind the curtain.

  • Relational Database Integration: Wizzdi Cloud is engineered to leverage relational databases’ power when deployed. So, in essence, each entity you design likely corresponds to a table in this database, establishing the groundwork for your backend’s architecture. When entity inheritance is used, the tables’ structure may differ.
Typical Entity Diagram View

Domain Model Creation Guide

Introduction to Entities and Enums in Software Development


In software development, particularly within object-oriented programming and database design, an entity is a distinct item that can be identified in the user’s domain of knowledge. It usually represents a real-world object or concept. Each entity has fields or properties that give it a unique identity or describe its characteristics. In simple terms, if you think of a database as a digital representation of a world of information, entities are the various objects or things in that world.

Enums (Enumerations):

Enums, short for enumerations, are a data type that consists of a set of named values. These values are constants and do not change. Enums define a variable that can be assigned one of the predefined values, ensuring that the value stays within the set bounds. It’s like giving a list of options and saying, “Pick one from this list.”

Understanding Entities and Enums with the School Example:

Let’s break down a school environment to understand entities and enums better.

  1. Entity: Student
    • Properties: Student ID, First Name, Last Name, Date of Birth, Level, Subjects Enrolled, Class Assigned, etc.
  2. Entity: Teacher
    • Properties: Teacher ID, First Name, Last Name, Specialization (subject they teach), Classes Assigned, etc.
  3. Entity: Subject
    • Properties: Subject ID, Name, Level, etc.
  4. Entity: Class
    • Properties: Class Id, Name
  5. Entity: Room
    • Properties: Room ID, Room Number, Capacity, Room Type, Location (like building or floor), Assigned Subjects, etc.
  6. Entity: Level
    • Properties: Level ID, Name, Like  Age Group, Subjects Offered, etc.
  7. Entity: Grade
    • Properties: 
  8. Enum: Levels
    • Values: Primary, Secondary, High School, etc.
    • Purpose: To classify different stages of school education. When assigning a level to a student or a subject, one can only choose from this predefined list, ensuring consistency.
  9. Enum: Subject Types
    • Values: Compulsory, Elective.
    • Purpose: To categorize subjects based on their mandatory or optional status in the curriculum.

In this example, entities like ‘Student,’ ‘Teacher,’ ‘Subject,’ ‘Room,’ and ‘Level’ help capture and represent the complex world of a school in a structured, organized manner in software or a database. At the same time, enums like ‘Levels’ and ‘Subject Types’ ensure that specific attributes take on only predefined values, bringing consistency and clarity to the system.

User Interface Description

You will see an empty diagram when you start the domain model in a new App; you can use a single diagram or create more diagrams for the various sections of your domain.

Domain model buttons
Buttons’ Description
  1. Edit the diagram name and add a description.
  2. Create a new Entity or  Enum; this can also be achieved through a right-mouse click on a space in the diagram.
  3. Import an Entity or Enum; this can be achieved through a right-click menu on a space in the diagram.
  4. Search for entities or entities’s fields in the diagram.
  5. Zoom diagram: You can also zoom by using the mouse wheel. Click on the zoom value to restore to 100%
  6. Undo/Redo changes
  7. auto arrange the diagram; you can always drag entities and arrange the diagram; the auto arrange provides satisfactory results in most cases.
  8. Go full screen and get some more working area.
  9. Add a diagram. You can build the App’s domain model on a large diagram or split it into subjets.
  10. Use OpenAI (ChatGPT) integration to generate and manage the domain model through textual description; this requires you to add an API token in your account settings.
Adding A New Entity

A new Entity can be created through the right-side panel

a new entity from the right-side panel

A new Entity can also be added from the right-click menu from an empty area on the diagram.

Adding a new Entity from the right-click menu

A new Entity must have a name starting with a capital letter.

New Teacher entity

Once created, the Entity looks similar to this.

The created Teacher entity
Adding fields

To add fields, click on the ‘+New Field’ option at an Entity’s bottom. (If the Entity is not currently selected, click on its top to select it) . Next, enter the name of the field and press ‘Enter’ on the keyboard. If you want to add more fields, continue this process. If you are finished adding fields, click on the green check mark to save the current field and stop.

Stop adding fields by the ‘Esc’ key or clicking the green checkmark.

Changing Fields Order

Click on a field and then use the dot array to drag the field to its desired location ->

Setting Field Type

Each new field’s type is String; This type holds characters. Its size can be practically unlimited when adequately set.

You can select the field type as one of the system’s basic types.  Field types of entities are defined through association, see below.


Click on the field type to select its type->   

Find a type by typing its name; 2-3 letters will filter the list. In the image above, we need the creationDate to be OffSetDateTime. This is a type that stores dates with their time zones.


Setting Field Purpose

Select a field to highlight it, then select the Purpose drop-down to the right. ->


Normal Field

Most Fields have no particular purpose. No need to set a purpose in such a case.


This is similar to a unique identification number for an entity’s instance. Every entity should have this field, which can be inherited from a Super Entity. See below.

In Wizzdi Cloud, an Id


The password value is encrypted in the password field, preventing access.


A LOB field is a type of text field that can accommodate large amounts of text, compared to regular text fields with a limit of a few hundred characters.

Creation Date

The system automatically maintains a creation date for any instance created if a field is set to OffSetDateTime type and its purpose is set to creation date purpose.

Update Date

The system automatically maintains an update date for any instance created if a field is set to OffSetDateTime type and its purpose is set to update date purpose.


To rearrange the fields of an entity, click on the field and drag it up or down to the desired position.


When creating a domain model, we sometimes prefer predefined values over entities. For instance, for Gender, we might list:

  • Female
  • Male
  • Undisclosed

To create an enum, click the +new button and select the “New Enum” option.     


Type a capitalized name, click the green checkmark, or hit the “enter” key.     

To add values to an Enum, select it and click “add value”. You can continue adding values by hitting the “enter” key after each one.
Enumeration values can begin with either a capital or non-capital letter.

To rearrange Enum values, simply drag and drop to a new position..



Associating Entities, creation relations

In Wizzdi Cloud’s architecture, entities can be linked using different association types, resulting in diverse relationships and data mappings. Specifically, the available association types are:

  • Many-to-One
  • One-to-Many
  • Many-to-Many

In the diagram below, we have two entities, Person and Address.

Although a person may have only one address, that same address could be shared by multiple individuals. This creates a ‘Many-to-One’ relationship from the person’s perspective, meaning that many people live at one address. From the viewpoint of the address entity, however, it’s ‘One-to-Many’ — one address linked to many people. When defining such relationships, it’s important to establish the association from the ‘many’ side. Therefore, it’s necessary to include an ‘address’ field within the person entity. Here’s how we can achieve this:

One-to-Many and Many-to-one

  • Click on the one-sided entity, which in this example is the Address. We start with the one-side, but as you will see, the many-side holds the definition.
    The entity ID should now have two small circles on either side.


  • Drag the small circle onto the name of the other entity, in this case, the Person entity. Release it when the pointer is over the other entity’s name.

A field named “address” has been added to the “Person” entity to indicate ownership of the connection. A list of “Person” type instances has also been added to the “Address” entity.

Manage Diagrams

Wizzdi Cloud supports multiple diagrams for large domain models.

To add a new diagram, simply click on the “+” located in the bottom left corner of the diagram.


Access the context menu by right-clicking on the diagram name to rename or delete a diagram.

If a diagram has grown too big, you can make a fresh one and transfer or duplicate the entity shapes across the diagrams. Note that the entity itself won’t be copied, only its delegate on the diagram. This way, dividing diagrams that have become too large is simple.

To establish connections between entities on separate diagrams, you must first transfer an entity to the diagram where the other entity is located. Once connected, you may remove the entity shape from one of the diagrams to simplify it.

Moving, removing, and copying entity shapes can be done from the three-dot menu on the entity shape.

The bottom right toolbar


Zoom: Use the +/- signs or mouse wheel to zoom in/out. To return to 100% Zoom, click on the percentage number for Zoom.

Pan: Click and drag an empty diagram area to move it.

Undo/Redo:  To undo or redo changes, simply use the standard undo/redo function. This will allow you to revert any changes that you have made, or to undo any changes that you have already reverted.

Auto arrange: To automatically arrange the diagram, simply click on the icon  Please note that this action cannot be undone, so proceed with caution.

Full screen: To free up more workspace, consider getting rid of the menu on the left-hand side by clicking on this icon.

Advanced Concepts

Consider the following entity diagram.

A simplified teacher and student diagram

This diagram illustrates three entities: Student, Teacher, and Subject. When a single teacher instructs multiple students, and a student may receive guidance from multiple teachers, a Many-to-Many relationship is formed. In Wizzdi Cloud, you can establish a many-to-many relationship between entities by dragging the id field circle of one entity onto the id field of the other. Simply drag the small circle of the id field of the first entity (Teacher) and release it over the id field of the other entity (Student) when it becomes selected.

A new connection entity is generated upon being released.

When you create a relationship between two entities, a connection entity is automatically generated. However, if you prefer, you can create this entity manually and link it to both associated entities as the ‘Many’ side. It’s important to note that this connection entity is a primary participant in the schema, not a secondary one. For instance, the absence of a field serving the ‘id’ purpose is indicated by a yellow flag above it.

A common way to improve the information about a connection is by adding extra fields that describe the nature or features of the relationship. For example, when arranging a class, it would be useful to include fields that indicate the day of the week, start time, and end time of the class. So, let’s add these fields to enhance the information about the class. have already added an entity called subject, which can be dragged (from the id circle) onto the connection entity head to include the Subject in the connection.

Tripple Connection

Wizzdi Cloud supports the concept of inheritance, a cornerstone of Object-Oriented Programming (OOP). In data modeling and entity structures, inheritance allows one entity to inherit attributes or characteristics from another, establishing a hierarchical relationship between them.

For example, if there’s a base entity named ‘Vehicle‘ with attributes like speed and weight, a derived entity such as ‘Car‘ can inherit these attributes and might introduce new ones specific to it, like trunk size. By supporting inheritance in Wizzdi Cloud, users can create data models that depict these structured, hierarchical relationships, ensuring a more organized and intuitive representation of data. Furthermore, Wizzdi Cloud adeptly manages the underlying complexity of handling inheritance at the database level, abstracting these intricacies from the user and providing a seamless experience.
Furthermore, it’s important to note that inheritance is a crucial factor in reusing domain models that have been created by you or other users on the Wizzdi cloud or available from the Wizzdi marketplace. Through inheritance, you have the ability to modify and improve upon the original design of these models.


Vehicles Cars and Motorcycles

To create an inheritance link between an entity and its Super Entity, select the entity, drag the small circle on top of the Entity shape, and release it above the name of the super-entity.

An entity can have only a single Super-Entity.  A single Super-Entity can have multiple ‘children’ entities.

To detach an entity from its Super Entity, click on the three dots menu. When an entity extends a super entity, all fields from the super-entity are automatically inherited and visible within the extending entity. This inheritance can cascade through multiple levels or layers of hierarchy. It’s important to note that once fields are inherited, they become unchangeable on the child entity. To modify these fields, one must navigate to the original super entity where they are defined, even if this means moving up several levels in the inheritance chain.


An entity can use indexes to improve performance. However, indexes are not required for fields that reference other entities, which are known as “foreign keys” in database terminology. The database server automatically adds these.

Setting an Index on an Entity

Indexes are attributes of an Entity, and multiple can be added. They can enforce uniqueness and may also be composite. Composite indexes are beneficial for data requiring multi-level sorting.

To set an index, select an entity and click ‘manage indexes.’

Manage indexes

When creating an index, you can designate it as unique. A field indexed as unique will ensure that no two entity instances have the same value in the field associated with the index.


Add entity fields to the index.

To create a composite index, you can add multiple fields. Adjust the sequence of these fields by dragging them, as the order can be crucial for querying and sorting operations.

Consider this example involving a composite index:

In an e-commerce application, purchases are tracked in a database, each with fields such as ‘date‘ and ‘totalCost.’

If you want to retrieve all purchases between Date A and Date B and within a cost range of X to Y, a composite index encompassing both ‘date‘ and ‘totalCost‘ can enhance the query’s performance. If questions frequently specify a specific date with a range of costs, then ‘date‘ should be the first field in the index, followed by ‘totalCost.’

Also, if the primary requirement is to sort the results by ‘date’ and then by ‘totalCost,’ then the ‘date’ field should precede the ‘totalCost’ field in the index.

Additionally, if there’s often a need to query just based on the ‘date‘ without specifying ‘totalCost,’ having ‘date’ as the first field in the composite index would also be beneficial, as databases can effectively use the “prefix” of the index for such queries.

External Projects and Reusability


In Wizzdi Cloud’s no-code platform, modularity and reusability are core principles. This allows users to efficiently construct applications by leveraging components from multiple projects. Here’s how it works:

  1. Project References: Within a user’s workspace, it’s possible to reference other projects directly from the current project or application. This is achieved through the “dependencies” menu option.
  2. Workspace Reference: You can reference project components from other workspaces you can access. Workspace owners can invite other users to use their projects; access can be read-only, so invitees are blocked from changing them.
  3. Marketplace Workspaces: Wizzdi Marketplace workspaces are available for users of Wizzdi Cloud. The ever-growing repository of solutions can be the starting point for a new project or form most of it.
  4. Code access:  Including dependencies in your code is possible from private and public repositories, such as Maven Central. This allows your business logic (flows) to access the methods and public classes defined in the referenced code. But, it is essential to have a basic understanding of Java code and the services that the referenced code offers.
External Entities Integration

In this section, we will provide a concrete example of how to reuse one app within another.

Here is the domain model for an app called Organization. It describes the structure of the organization, including its employees, branches, and addresses.

Organization App Domain Model

The Address part is defined in this domain model:


Here is a very simplified domain model for an e-commerce app seller entity



After clicking, you may encounter a view similar to this:

Click on ‘+ Add Dependency’ to add one,

Click on ‘Search Projects’ 

Consumed APIs

1. Purpose of Consumed APIs:

  • Broaden Functional Scope: By integrating with external services, your app can extend its capabilities without building every feature from scratch.
  • Streamline Processes: Utilizing pre-existing and well-established services like SendGrid ensures that specific processes, such as email delivery, are handled efficiently.

2. Methods of Defining Consumed APIs:

  • Manual Definition: When you have distinct requirements or an OpenAPI file isn’t available, Wizzdi Cloud allows you to set up and define the consumed API endpoints manually. This gives developers a granular level of control, tailoring each endpoint to their specific needs.
  • OpenAPI Import: Numerous current service providers provide OpenAPI (previously known as Swagger) definitions. These documents present a structured explanation of each of the API’s endpoints, responses, request formats, and other essential details. Wizzdi Cloud streamlines the import process of these files, automating the setup of the used API endpoints. This helps save time and guarantees that your backend conforms to the recommended standards and constructions of the external service..

The Consumed APIs section in Wizzdi Cloud serves as a bridge, connecting your backend to the broader ecosystem of web services. Whether plugging in manually or importing an OpenAPI specification, this integration ensures your application remains versatile, dynamic, and capable of leveraging the best of what the digital world offers.

Interconnectedness with Wizzdi Cloud Apps: Building SOA Systems


Service-Oriented Architecture (SOA) emphasizes building easily reusable and interchangeable software components. With the rise of microservices and distributed architectures, SOA’s principles have gained significant traction. In this context, Wizzdi Cloud offers a unique advantage by allowing one app to interact with another seamlessly.

1. Consumed APIs in an SOA Ecosystem:

  • OpenAPI for Inter-App Communication: Consumed APIs are not restricted to external services like Gmail or SendGrid. When working within the Wizzdi Cloud ecosystem, one app can directly import the OpenAPI of another Wizzdi Cloud app. This paves the way for fluid data exchange and service usage between different apps, fostering a cohesive network of interconnected applications.
  • Standardization with OpenAPI: By leveraging the OpenAPI specification, Wizzdi Cloud ensures that the communication between apps adheres to a recognized and consistent format. This standardization reduces integration overhead and potential discrepancies, allowing for a smoother interoperability experience.

2. Benefits of SOA Integration in Wizzdi Cloud:

  • Reusable Components: Embracing SOA principles means you can design an app component once and then deploy and utilize it across multiple applications. This not only reduces redundant effort but also ensures consistency across projects.
  • Scalability & Flexibility: As your system grows, you can easily add or modify new services without disrupting the entire application ecosystem.
  • Optimized Maintenance & Upgrades: With distinct apps handling specific services, updating or patching one service doesn’t necessitate taking down the entire system. This modular approach streamlines maintenance tasks and minimizes downtime.

3. OpenAPI Publishing in Wizzdi Cloud:

Every app built on Wizzdi Cloud automatically publishes its exposed APIs via an OpenAPI document. This self-documenting feature means that any other app, within or outside the Wizzdi Cloud environment, can access and understand the functionalities. It acts as an open invitation, encouraging other systems to leverage the services provided by the app.

In summary, Wizzdi Cloud’s support for SOA principles and its inherent capabilities around Consumed APIs position it as a robust platform for creating intricate, interconnected software ecosystems. Whether you’re aiming for a vast web of interlinked applications or want two apps to share resources, Wizzdi Cloud provides the tools and frameworks to make it happen effortlessly.

Exposed Apis



Wizzdi Cloud automatically generates API endpoints based on the entities you define within your domain model. This feature simplifies the backend development process, ensuring that every entity you create is instantly accessible and manageable. Additionally, Wizzdi Cloud offers flexibility in adding or importing API endpoints for advanced use cases or specific requirements. This feature can be turned off.

1. Default API Generation:

  • Entity-Based Automation: As soon as you create entities within the domain model section, Wizzdi Cloud takes the initiative to generate corresponding API endpoints. These entities’ basic CRUD (Create, Read, Update, Delete) operations are instantly set up without further intervention.
  • Immediate Usability: With automatically generated APIs, your backend is instantly operational. As you evolve your domain model, the system adapts in real time, updating the available API endpoints as necessary.

2. Advanced API Management:

  • Manual Endpoint Addition: There might be scenarios where you require custom API endpoints for specialized operations or to cater to unique functionalities. Wizzdi Cloud’s interface allows for the intuitive addition of individual API endpoints, granting you full control over the specifics.
  • OpenAPI Document Import: To further streamline the process and accommodate extensive API structures, Wizzdi Cloud supports importing OpenAPI documents. This feature is especially beneficial when migrating or integrating extensive systems, as it bypasses the need for manual entry. Upon importing, all the endpoints defined in the OpenAPI document are readily available within Wizzdi Cloud.

Wizzdi Cloud’s approach to managing exposed API endpoints balances automation and customization. Whether building from scratch or integrating existing systems, the platform offers tools to ensure your backend is robust, responsive, and ready for deployment.


Custom Queries

Advanced-Data Management in Wizzdi Cloud


Wizzdi Cloud strives to simplify the backend development process by automating foundational aspects, like creating repositories and generating code for CRUD operations on entities. However, real-world applications often demand more granular control and nuanced data interactions. Recognizing this need, Wizzdi Cloud offers advanced tools such as the custom query builder.

1. Automated Entity Management:

  • Instant Repository & Service Generation: As you sculpt entities within Wizzdi Cloud, the system recognizes these entities and instantaneously crafts the requisite data repositories and accompanying services to facilitate basic CRUD operations.
  • Smart Data Retrieval: Wizzdi Cloud is designed with an innate understanding of entity relationships. For instance, when querying for an entity related to another entity, the system automatically fetches relevant connected data. This feature ensures that data remains contextually rich and relevant. Using the authors and books example, when books are queried, their corresponding authors are nested within the retrieved data, providing comprehensive insights without additional requests. This happens only when you retrieve the ‘many’ side of the relation, in this case, the Book.

2. Custom Query Builder:

  • Beyond Basic CRUD: While automated CRUD operations suffice for many scenarios, there are times when the default isn’t enough. Whether it’s complex filtering, advanced aggregations, or specific data transformations, there are myriad cases where a more hands-on approach to data access is warranted.
  • Intuitive Interface: The custom query builder is designed with user-friendliness in mind. It provides a visual platform to define specific data retrieval conditions, ensuring you get the exact slice of data you need in your desired format.
  • Integrated Code & Repository Creation: As with entity creation, Wizzdi Cloud takes over the heavy lifting once you design a custom query. It generates the necessary data repository structures and crafts the service code, ensuring that your custom queries are not just designs but instantly actionable components of your backend.




Dependency management within Wizzdi Cloud ensures your application integrates seamlessly with other projects and artifacts. This facility allows for incorporating and reusing external resources, streamlining development by building upon existing components. Let’s explore this in more detail.

1. Adding Dependencies:

  • Workspace Dependencies: You can incorporate components from other projects within your current workspace. This is especially helpful if you have multiple interrelated projects and want to leverage functionalities or data structures from one project in another.
  • My Market Place Integration: Beyond your workspace, “My Market Place” is a repository to import external projects and artifacts. Once imported, these become available across all your workspaces, making integrating and reusing established components in various apps easy.

2. Referencing and Utilization:

  • Domain Model Integration: You can refer to or integrate entities from other domain models with the defined dependencies. This facilitates a modular approach, where specific domain components can be standardized and reused across multiple projects.
  • Custom Queries and APIs: Dependencies aren’t limited to domain models. You can also reference and utilize custom queries and APIs from other projects, ensuring you don’t reinvent the wheel and maintain consistency in data access and manipulation.
  • Business Flow Interactions: Business flows, which define your applications’ logic and operational flow, can also integrate functionalities from dependencies. This is particularly beneficial when standard operational patterns are established and must be replicated across applications.

Wizzdi Cloud’s dependency management is a modular and integrated application development cornerstone. Userd can ensure consistent, efficient, and integrated application functionalities across projects by defining and managing dependencies effectively.



In Wizzdi Cloud, when initiating a new application, users have a choice between two runtime environments: Spring Boot, a well-known framework, and its counterpart, FlexiCore Boot. FlexiCore boot has all the features of Spring, a Spring Boot with additional features.
Components apply to FlexiCore boot only.


Key Features of FlexiCore Boot:

  • Access Control: In environments with multi-tenancy systems, refined controls over data and APIs are often needed. FlexiCore Boot offers tools to address these requirements effectively.
  • Modularity in Action: Rather than confining feature modifications to the development stage, FlexiCore Boot supports real-time component integration or removal. It accomplishes this by treating these components as active plugins. This dynamic nature has several benefits:
    • Integration: Enables the smooth addition or removal of components without a complete system reset.
    • Adaptability: As application requirements shift or grow, it’s possible to introduce new functions seamlessly.

Component Types in FlexiCore Boot:

  • Model Component:
    • Purpose: To define the domain model of the application.
    • Features:
      • Structures essential data entities and their interrelationships.
      • Dictates how data will be organized, preserved, and accessed.
      • Serves as the foundational framework for services, APIs, and business logic.
  • Service Component:
    • Purpose: Handles nearly all functions outside of the domain model.
    • Features:
      • Manages both exposed and consumed APIs.
      • Supports custom queries and business flows, shaping the application’s interactions with its data and other systems.
  • Module Component:
    • Purpose: Generates a usable module for integration into the FlexiCore Boot runtime.
    • Features:
      • Modular design for easy runtime integration.
      • Supports specific functionalities or features for modular addition or subtraction.
      • Facilitates scalability by allowing for the addition of new modules as needs change.


While FlexiCore Boot offers dynamic modularity and refined access control, it does come with a consideration. Applications developed using FlexiCore Boot become dependent on the FlexiCore framework. This dependency contrasts with the more universally applicable Spring Boot framework. To ensure flexibility and to cater to varied requirements, Wizzdi Cloud provides support for both runtime environments, allowing users to choose the one that aligns best with their needs and future plans.



Within Wizzdi Cloud, users have tools to oversee the app’s commits, versions, and repositories. While the intricacies of the generated code might remain hidden, the platform ensures that these files are safely stored in repositories. Think of this as a safeguard for your work, akin to an external storage or backup system for your digital creations.

Breaking Down the Terminology:

  1. Commits:
    • Explanation: A commit represents a set of changes or additions to a project’s files. When you commit, you save a version of your files at a particular time.
    • Purpose in Wizzdi Cloud: This allows you to track the modifications made to the app, offering a history of changes and the ability to revert to earlier states if needed.
  2. Versions:
    • Explanation: In software, a version refers to your application’s specific state or iteration.
    • Purpose in Wizzdi Cloud: Versions lets you manage and navigate through different stages of your app’s development, ensuring you can return to a previous version if necessary or progress forward with updates and enhancements.
  3. Repositories:
    • Explanation: A repository (or ‘repo’ for short) is a centralized place where code is stored and managed. It contains all the files and the historical record of changes made to those files.
    • Purpose in Wizzdi Cloud: Repositories store your app’s codebase. They facilitate collaboration, version control, and your app’s intellectual property backup.

Storing Your Code with Repositories:

Even if you aren’t interacting with the code directly, Wizzdi Cloud ensures your work is backed up. It pushes the created files to a repository, safeguarding your intellectual property.

You have several options when choosing where to store this code:

  1. Public GitHub Account:
    • Explanation: GitHub is a popular platform for hosting and managing code repositories. A public account means that the contents of your repository are visible to anyone on the internet.
    • Benefits: Easy accessibility and visibility. It’s free to use.
  2. Private GitHub Account:
    • Explanation: This is a version of GitHub where your repositories are hidden from public view and only accessible to those you grant permission.
    • Benefits: Greater control over who sees your work. It provides more privacy than a public account.
  3. Self-Hosted GitLab Account:
    • Explanation: GitLab is another platform for code hosting, similar to GitHub. A self-hosted GitLab means you’re running GitLab on your servers.
    • Benefits: Offers increased control over your repositories. You can ensure privacy and security based on your personal or organizational preferences. However, it must remain accessible online for proper integration with Wizzdi Cloud.


Managing commits, versions, and repositories in Wizzdi Cloud gives you greater control over your app’s development history. By understanding the terminology and the importance of repositories as backups for your intellectual property, you can make informed decisions on how and where to store your work.











My Marketplace