This study explores the efficiency gains achievable when using the Wizzdi Cloud no-code platform compared to traditional backend development. Wizzdi Cloud uniquely combines the flexibility of standard development tools with the speed of no-code, promising to accelerate developer workflows significantly without imposing proprietary dependencies. Through a controlled experiment involving professional developers, the study demonstrates substantial time savings and an accessible learning curve, with completion times reduced up to 30 times compared to conventional development. Follow-up research will further investigate the impact of hybrid workflows (combining Wizzdi Cloud and traditional development) and evaluate Wizzdi Cloud’s performance on more complex projects involving additional aspects beyond domain modeling and CRUD operations.

Introduction

While most no-code platforms offer efficiency improvements, Wizzdi Cloud stands out by seamlessly integrating with established development tools and providing dependency-free code. This unique approach enables backend developers to use Wizzdi Cloud as an accelerator, enhancing productivity without the constraints commonly associated with no-code environments. Wizzdi Cloud-generated code is 100% free from platform dependencies, allowing developers to accelerate their work significantly. New users can learn its basic functionality within 30 to 90 minutes, even without prior experience.

This case study examines the efficiency gains achievable by backend developers using Wizzdi Cloud compared to traditional development methods. The study involved a group of Spring Boot developers who completed the same backend task using both traditional coding and Wizzdi Cloud. Results reveal considerable time savings, particularly for developers who previously trained with Wizzdi Cloud.

Methodology

Objective
The goal was to measure the efficiency of Wizzdi Cloud in creating a backend system compared to traditional development.

Participants
Four backend developers proficient in Java and Spring Boot were recruited, each with an average of three years of experience. The group included three developers (Developers A, B, and C) who had no prior experience with Wizzdi Cloud and one experienced Wizzdi Cloud user (Developer D).

Task Description
Developers were tasked with building a backend system to manage books, authors, and libraries. The system required:

• Entity definitions for Book, Book Instance, Author, Genre, Lender, Library, AppUser, and several linking entities to handle many-to-many relationships.

• CRUD REST APIs to manage the entities.

• Backend implementation using JPA 2.1 and type-safe criteria API.

• User management endpoints for registration and login.

• Docker script for launching the server in one command.

Process

1. Each developer was first asked to complete the task using standard development.

2. Developers with no prior Wizzdi Cloud experience (A, B, C) were then introduced to Wizzdi Cloud.

3. They were allowed a short learning period with the platform and asked to complete the task again on Wizzdi Cloud.

4. Developer D, already familiar with Wizzdi Cloud, completed the task on the platform for comparative purposes.

Results

The results show a significant reduction in development time for those using Wizzdi Cloud.

Developer	Time to Complete (Traditional)	Time to Learn Wizzdi Cloud	Time to Complete (Wizzdi Cloud)
A	419 minutes	N/A	N/A
B	639 minutes	50 minutes	22 minutes
C	340 minutes	N/A	N/A
D	N/A	N/A	9 minutes

• Developer B: Despite being new to Wizzdi Cloud, Developer B completed the task in only 22 minutes after a brief 50-minute learning period.

• Developer D: An experienced Wizzdi Cloud user, Developer D completed the task in just 9 minutes.

• Developers A and C, who worked using traditional development methods alone, took significantly longer to complete the task, ranging from 340 to 639 minutes.

The results underscored such a large efficiency gap that further testing was halted for Developers A and C, as it was clear they would not match the speed achievable on Wizzdi Cloud.

Discussion

The study illustrates the impact of Wizzdi Cloud’s no-code capabilities on backend development. Even developers with no previous experience saw a remarkable reduction in task completion time after a short training session. Wizzdi Cloud’s automatic handling of non-domain logic—such as API, criteria API implementation, and containerization—streamlines backend setup and enables developers to focus on core business logic.

Developers new to the platform achieved up to 30 times acceleration in task completion when using Wizzdi Cloud over traditional development environments. For experienced users, the speed was even more pronounced, reflecting the value of familiarity with the platform.

Conclusion

Wizzdi Cloud enables backend developers to significantly accelerate their workflows, achieving up to 30-fold improvements in speed without sacrificing the flexibility of traditional coding tools. The platform’s ability to generate fully independent, standard-compliant code offers developers the best of both worlds—speed and integration with traditional development workflows. Wizzdi Cloud is positioned as a powerful tool for organizations seeking to maximize efficiency in backend development without compromising code portability or flexibility.

Future Research

Future research will examine hybrid workflows that combine Wizzdi Cloud with traditional development environments, assessing whether combining both approaches yields further benefits. Additionally, research will focus on more complex projects that go beyond domain modeling and CRUD operations to explore Wizzdi Cloud’s capabilities in areas like security, business logic, and third-party integrations.

The post Efficiency Gains in Backend Development Using Wizzdi Cloud first appeared on wizzdi.

In this short blog, we are discussing the merits and drawbacks of no-code systems. For startups, building a minimum-value product is often the only visible goal.

Resources may be scarce, and entrepreneurs may prefer to avoid hiring developers, even if it may require them to rewrite an application once resources are available.

What are no code systems?

No-code systems are platforms or tools that enable users to create software applications without coding. These systems offer a visual development environment where users can drag and drop components, configure workflows, and set up integrations to build fully functional applications. The main objective of no-code systems is to make software development accessible to individuals who do not possess conventional programming skills.

Common Use Cases

• Internal Tools: Companies often use no-code platforms to build internal tools, dashboards, and workflow automation to streamline business processes.

• MVP Development: Startups can use no-code tools to build Minimum Viable Products (MVPs) and quickly validate ideas before committing to full-scale development.

• Automating Business Processes: No-code platforms are commonly used to automate repetitive tasks such as data entry, reporting, and communication workflows.

Atypical Use Cases

• Large-scale applications that serve a large number of users.

• Applications with complex security requirements and advanced data access control.

• Applications with complex integration requirements.

• Enterprise-grade applications.

• SaaS applications supporting multitenancy.

The Benefits of No Codes Systems

Speed of Development

• No-code platforms allow you to quickly bring your ideas to life, enabling rapid prototyping and iteration without waiting for a complete development cycle.

• Time to Market: If your startup needs to launch a product or service quickly, using a no-code solution can significantly reduce development time, enabling you to capture opportunities faster.

Cost Reduction

• Cost-Effective Development: No-code platforms do not require a large development team, lowering the initial costs of custom coding.

Allow more people to participate

• When your team lacks technical expertise, a no-code platform allows you to create and manage applications without hiring expensive developers.

• No-code systems allow entrepreneurs to focus on their business strategy and operations instead of getting bogged down by technical challenges.

Fits the startup’s early stage

• No-code platforms are ideal for startups in the early stages, where the focus is on validating the idea rather than scaling rapidly.

The drawbacks

Most drawbacks are irrelevant if you plan to build a minimum viable product (MVP), knowing that a rewrite from scratch will be required.

In a recent user survey conducted on Reddit, the following drawbacks were specified by readers:

Vendor Lock-In

More than half of the users consider this the main issue with no-code systems. Vendor lock-in has several implications, some of which are not immediately apparent when implementing a new system.

Intellectual Property lock-in

Almost all no-code systems are designed to run exclusively within their environment, utilizing libraries and paradigms specific to the platform. As a result, any intellectual property created within the no-code platform has limited usability outside of it.

Deployment Lock-in

Most no-code vendors only allow deployment on their infrastructure. Some offer an on-premises installation option, which can ease the hosting costs. However, this option is still based on proprietary technology that can cease to be developed and maintained.

Mandatory hosting can lead to uncontrolled and high costs for a startup at the scale-out stage. Some solutions even charge a monthly fee for each end user, who is not a developer but a user of the running system.

Lock in through a technical debt

For every no-code system, there may be a small number of knowledgeable developers who can further develop anything you build. Expanding such systems using traditional programming languages is sometimes possible but relies on specific non-standard software interfaces. Covering the technical debt may necessitate a full rewrite using conventional development tools.

Lack of some features

No-code systems have a set of features. When a system in development becomes complex, more features are required, and adding them can be impossible or difficult. In that sense, traditional development is way more flexible and practically limitless.

Unlike the frequent hype, not every missing feature in a no-code system can be implemented via code.

For example, suppose a no-code system does not support multitenancy or fine-granularity data access control. In that case, it will be tough to add such a feature, as it is built into the system at a deep level.

If all you aim for is a prototype, you may forgo some features until you complete a rewrite using a traditional development workflow.

Complexity and Steep Learning Curve

One of the fallacies associated with no-code development is the belief that ‘anyone can become a no-code developer.’

This is as incorrect as claiming anyone can master Photoshop or Excel.

Powerful no-code platforms are designed to solve complex problems and have many features and workflows that must be mastered.

To successfully use a no-code system, you need to:

• Deeply understand the application domain in which your product operates. This is crucial for designing any system using any development workflows and tools.

• Be willing to invest time in learning, trying, and making mistakes.

• Understand that you may need developers’ help even before a Minimum Viable Product is completed, let alone when you need to scale.

• Understand that a system cannot be viewed through its user interface. Sometimes, entrepreneurs see only the user interface of their product. In most cases, the backend matters more.

• Realize that many workflows are faster to implement in a no-code system while others may be faster to code. Developers tend to prefer doing everything in code.

Low performance of the created App

A discussion of the two main no-code deployment types is required to understand the reason for this observation.

In general, no-code systems are implemented using two main approaches:

The Immediate Execution System.

• Immediate execution systems offer immediate feedback as you develop without compiling a target code. You can sometimes identify such a system by adding data to your data store immediately after defining an entity. The runtime and design phase are intermixed. However, these systems typically run slower in production and require more resources to prevent slowdowns. It can be confidently stated that these systems do not provide any flexibility in deployment, whether on-premises or elsewhere. Some of the vendors offer a guarantee that in the case of going out of business, they will allow on-premise deployment; no one has ever tried that….

The Immediate Execution System may have an advantage related to debugging an application.

The Code Generators

• Systems that compile a target image include the necessary dependencies and database setup. These systems separate the design phase from the deployment phase. The deployment becomes available after a noticeable amount of time is needed to prepare a deployable image. Such systems may deliver better performance once the runtime is deployed, and their performance is inherently similar to compiled code in other programming workflows and tools. Deploying these solutions on-premises or outside a no-code vendor’s cloud is more practical.

Data lock-in

This is a frequently overlooked disadvantage. One of the main assets of any organization is the collected data.

Most no-code vendors do not provide an easy way to access the data accumulated in their systems.

Apis for accessing the data can be implemented on some of the systems, but direct access to the database server, if one exists as such, is unavailable.

When you have control over the deployment and can access the database anytime, you can back it up, clone it, or copy data from specific tables/collections.

Data lock-in may be critical when switching from a no-code solution to a traditional development solution, as the accumulated data may be valuable.

Conclusion

In summary, while no-code systems offer significant benefits in speed, cost, and accessibility, especially for startups and small businesses, they also have inherent limitations that can affect scalability, flexibility, and long-term sustainability. These platforms are great for quickly bringing ideas to life, building MVPs, and streamlining internal processes. However, for more complex, large-scale applications or those with specific security and integration requirements, the disadvantages of no-code systems—such as vendor lock-in, limited features, and potential data lock-in—can present significant challenges.

When evaluating a no-code platform, it’s crucial to determine if it meets your project’s specific requirements and long-term goals. For early-stage startups, the benefit of rapidly prototyping and validating ideas might outweigh any potential drawbacks, making no-code an attractive option. However, as your business grows and your technical needs evolve, transitioning to traditional development may be essential to maintain control, flexibility, and performance.

Fortunately, recent no-code developments address most of these challenges while retaining the benefits. For example, no-lock, no-code platforms like Flutter Flow for the front end and Wizzdi Cloud for the backend offer more flexibility by allowing users to export clean, usable code that isn’t tied to a specific vendor’s ecosystem. This approach mitigates the risk of vendor lock-in and provides greater control over the deployment and future development of the application.

As the demand for no-code solutions continues to grow, more vendors will likely adopt similar approaches, offering tools that combine the speed and accessibility of no-code with the flexibility and control typically associated with traditional development. This evolution could make no-code platforms an even more attractive option for a broader range of projects, allowing businesses to leverage the best of both worlds.

In my next article, I will share my journey while building a complex parking platform using no-code.

The post Is No-Code Right for Your Startup? first appeared on wizzdi.

introduction

As someone who enjoys developing software as a hobby, I have been particularly interested in VueJS and have worked on various front-end projects. Recently, a family friend who owns a rapidly expanding local pizza chain asked me for help. He was dissatisfied with the current delivery apps and wanted one that could better reflect his brand – something modern, user-friendly, and adaptable to his business’s requirements.

Using a no-code backend platform was a strategic decision to bypass the complexities of backend development, allowing me to concentrate on what I do best: crafting a seamless and attractive user interface. With a no-code solution, I could effortlessly integrate essential features such as payment processing, order tracking, and real-time communication, which are typically time-consuming to implement. This approach significantly expedited the development process, enabling me to focus on enhancing the front end with VueJS, ensuring the app was functional, aesthetically pleasing, and intuitive.

The process of creating this pizza delivery app was both thrilling and challenging. It required me to integrate technical skills with creative design in order to offer a complete solution that would be attractive to both management, customers, and delivery staff. The choice to use a no-code backend was essential as it allowed me the flexibility to focus on the user interface and guarantee that the app could be easily scaled and adapted for use on various devices, from desktops to mobile phones.

Objectives

The post will delve into the main reasons for selecting a no-code backend platform, the steps involved in defining the app’s vision for various user groups, the careful design of the domain model, the integration and automation of business processes, and the challenges encountered and how they were resolved during the development process.

Why a No-Code Backend Platform?

Opting for a no-code platform, especially for the backend, was strategic due to several key factors:

• Multiple User Interfaces: The application must support various user interfaces to provide a consistent user experience across different devices.
• Rapid Development: The no-code approach accelerated the development process, enabling me to focus more on functionality and user experience.
• Ease of Integration: The platform simplified complex processes by providing built-in support for integrations like payment gateways and real-time communication.
• Scalability and Flexibility: It provided the infrastructure to adapt to changing business requirements and user needs.
• Cost Efficiency: The platform provided a cost-effective solution for building and maintaining the backend by reducing the need for extensive coding.

However, the decision to use a no-code platform was challenging. One of the initial hurdles was ensuring that the platform could seamlessly integrate with the various user interfaces required for the app. This was overcome by carefully researching and evaluating the platform’s integration capabilities and thoroughly testing the integration process.

The Vision

Before starting the development process, I carefully outlined the app’s objectives for each user group to ensure that the solution effectively met all their needs. I aimed to create a valuable tool for management, customers, and delivery personnel.

For Management:

• Branch Management: Tools for managers to add, update, and organize branches to track various locations efficiently.
• Topping Management: A system for managing menu items ensures that offerings are current and reflect inventory and customer preferences.

For Customers:

• Order Creation and Customization: A seamless process for creating and customizing orders, including a smooth checkout experience with PayPal.
• Real-Time Tracking: With WebSocket technology, customers can track their delivery from preparation to arrival.

For Delivery Personnel:

• Efficient Communication: The server automatically receives the location of delivery personnel, enabling better customer service and management tools.

During the vision-defining stage, one of the challenges we faced was ensuring that the app’s features and functionality met the needs of all user groups without becoming overly complex. We addressed this by carefully prioritizing the most critical requirements and iterating on the design to balance comprehensiveness and usability.

The Domain Model

The design of the domain model was crucial for building the entire pizza delivery app. It was a key step in determining the app’s functionality and ensuring smooth data management. Instead of just listing entities and their relationships, I aimed to bring this process to life and highlight the thought and creativity behind it.

Laying the Groundwork: Basic and SecuredBasic

At the very core of the domain model, I established the Basic and SecuredBasic entities. These served as the building blocks, providing a standardized structure for all records in the system. The Basic entity encapsulated essential fields like id, name, creationDate, and updateDate – a common thread that ran through the entire database.

Extending this foundation, the SecuredBasic entity introduced an additional creator field, allowing me to link each record to a specific user. This enhanced the app’s security and paved the way for personalized experiences and user-specific data management.

Mapping the Pizza Ecosystem

After laying the groundwork, I created the components to bring the pizza delivery app to life. One of the main components captured the information of each pizza store, such as its location coordinates. This was crucial as it enabled the system to monitor orders for each store, making delivery routes and times more efficient.

Closely tied to the Branch was the PizzaOrder entity, which extended the SecuredBasic structure. This entity was responsible for meticulously tracking the status of each order, guiding it through the various stages – from DRAFT to STARTED, PREPARE, BAKING, DELIVERY, and finally, COMPLETE. This level of granularity ensured that both customers and management could stay informed every step of the way.

Customizing the Perfect Pizza

At the heart of the app’s functionality was the ability for customers to create and customize their pizzas. The Pizza entity captured the details of each pie, with a direct relationship to the PizzaTopping entity. This allowed for an endless combination of toppings, each with its price, to be added to the order.

The Topping entity served as the master repository of available toppings, providing a centralized and easily manageable system for the pizza business to maintain its menu. With this domain model in place, the app could not only handle the standard pizza orders but also cater to each customer’s unique preferences.

Bringing it All Together

By meticulously designing this domain model, I created a robust and flexible system that could adapt to the dynamic needs of the pizza delivery business. Each entity and relationship was carefully considered, balancing comprehensiveness and ease of use. This foundational work paved the way for the seamless integration and automation of the app’s core business processes.

Payment and Real-Time Location

Interested in learning more about the app?

• Code Repository: [Link to code]
• App: [Link to App]

The post Building My Pizza Delivery App: A Developer’s Journey first appeared on wizzdi.

The post Wizzdi in Action 1 min Video first appeared on wizzdi.

this Section’s purpose is to take you through the process of building a Pizza Delivery App.

the backend will serve multiple clients:

1. the management – used by management
   1. managing branches
   2. managing toppings
2. the user app – used by customer to order pizza
   1. allows creating a new order
   2. adding multiple pizzas
   3. adding toppings for a pizza
   4. pay via PayPal
   5. track delivery location live using WebSocket
3. the delivery app – used by delivery to report location
   1. push GPS location

the example is available on wizzdi cloud public marketplace

App Overview

Domain Model

in this part we will create the domain model to describe the normal data that is handled in a typical Pizza Restaurant: Basic,SecuredBasic,Branch,Topping,PizzaOrder,OrderStatus,Pizza,PizzaToTopping

the Domain Model Editor is a powerful tool that allows creating connection between entities ,setting indexes , creating inheritance relationship and much more.

for a more extensive view of the Domain Model Editor check its documentation.

The Basic Entity

The Basic Entity will be used as a Mapped Super Class for all other Entities , a Mapped Super Class is kind of a Mold for SecuredBasic, Branch and  Topping, this allows us to have the name ,id , creationDate, updateDate of Basic in all the other Entities.

The SecuredBasic Entity

The SecuredBasic Entity will be used as a Mapped Super Class for all other Entities  , this allows us to have the all the fields of Basic Entity as well as the creator field which will hold the creator of the things the customers create , this will automatically filter the data so users only see their own data (except admin users).

The Branch Entity

The Branch Entity defines a Branch of our Pizza Restaurant chain, a pizza order will be made at a specific branch

The Topping Entity

The Topping Entity defines the possible toppings our Pizza Restaurant chain provides and their price.

The PizzaOrder Entity

The PizzaOrder Entity will be used to represent a new Pizza Order

The OrderStatus Enum

the OrderStatus Enum is a list of predefined values that will represent the possible Status values a Pizza Order Goes through

The Pizza Entity

The Pizza Entity will be used to represent a Pizza in a Pizza Order , we can have many pizzas in a single pizza order

The PizzaToTopping Entity

The PizzaToTopping Entity will be used to represent a Topping on a Pizza , the user will be able to select the toppingCoverage , a pizza may have many toppings.

Exposed APIs

In this section we can see the automatically CRUD (create, read, update and Delete) APIs.

more options available here such as adding a new custom endpoint , defining if the project is a contract-first of domain-first and much more.

check the Exposed API Documentation for an extensive view of it.

Custom APIs

we have added three APIs in addition to the automatically created CRUD apis;

1. getPizzaOrerSummary – given a PizzaOrder id will return a summary of the order , we will use this to display a summary of the order before paying , it is connected to the OrderSummayFlow(more on flows later)
2. prepareCheckout – given a pizza order id we will start the checkout process with PayPal , it is connected to the PrepareCheckoutFlow
3. completeOrder – this will be called by PayPal when the order is paid for , providing a PayPal order id we will mark the order as paid and change the PizzaOrder Status , it is connected to the CheckoutValidationWebhookFlow

Flows

business flows are used to express a custom business logic connected to custom APIs  or other type of triggers (schedule ,event and more) ,

check the Flows Documentation for an extensive view of it.

OrderSummaryFlow

the order summary flow is using a Method Definition activity which is written in Java

PrepareCheckoutFlow

the PrepareCheckoutFlow will be called when the user tries to pay for an Order , it :

1. fetches the order based on the incoming id
2. gets the order summary by calling the getSummary method definition (which calls the logic from OrderSummaryFlow)
3. if a PayPal order id is not set on this order
4. calls PayPal api with the total that should be paid and the order id
5. takes PayPal order id from the response and sets it on the order
6. returns the order

CheckoutValidationWebhookFlow

the CheckoutValidationWebhookFlow will be called by PayPal (the url of this API should be set as a webhook in PayPal) when the user successfully paid for an Order , it :

1. calls the PayPal api to verify the webhook call ( this prevents anyone from simply calling this webhook and impersonate payapl)
2. if it was not validated – return failure
3. fetches the order
4. updates the order status to STARTED
5. return success

UpdatePizzaOrderFlow

the UpdatePizzaOrderFlow will be trigger when a PizzaOrder is updated (it is triggered by an event), it will push update message of the order status to WebSocket (more on Websocket integration later), this will allow us to update the customer without constantly calling an api to refresh the data , it :

1. fetches all the websocket sessions that listen to the changed pizza order id
2. creates an update message that will be sent to all of them
3. for every session it sends the message

Integrations

Integrations allow adding additional services to our deployed app , it also adds relevant integration code to the app and adds additional activities to the activities toolbar .

check the Integration Documentation for an extensive view of it.

in this application we will be using only one integration – the websocket integration.

Web Socket Integration

we are using the websocket integration in our UpdatePizzaOrderFlow, here we define the url of the websocket endpoint (we can have multiple endpoints) , and the message structure that will be used in our websocket endpoint.

Security

since we have multiple users for our backend it is important that we allow each user to execute only the actions it allowed to do.

additionally we also like to support SSO login and registration.

SSO Login

in the sso login area we can define support for sso login /registration , wizzdi cloud support many of the known providers as well as the option to add a custom provider.

check the SSO Login Documentation for an extensive view of it.

Permissions

in the permissions area we set which roles are allowed to which permissions (this can be done from this screen or from the exposed apis screen by pressing the lock icon next to the api endpoint).

since Branch and Toppings should not be added by normal app users we will allow only admin to manage them.

check the Permissions Documentation for an extensive view of it.

Properties

finally we need to set some properties to make PayPal SSO Clients work :

1. SSO Clients details , this will require PayPal client and secret
2. SSO Clients scope – https://api.paypal.com/v1/payments/.*
3. SSO Clients token URI – https://api-m.sandbox.paypal.com/v1/oauth2/token
4. SSO Clients authorization URI – https://api-m.sandbox.paypal.com/signin/authorize

Review

Review The Code.

now the code is available , this example code can be found here.

Review The App’s API Docs

The swagger docs for the app is available here.

The post Pizza Delivery App first appeared on wizzdi.

This is the single public marketplace provided by the Wizzdi software system containing full projects, samples, and projects you can build upon. Cloning from the Marketplace is identical to cloning from any of your Marketplaces.

Repositories

Binary code repositories are essential tools in software development. They serve as storage and management systems for binary files, including compiled software versions, libraries, and dependencies. Maven Central is one of the most well-known public repositories, primarily serving the Java community. It hosts a vast array of Java libraries and components, allowing developers to integrate and manage dependencies in their Java projects easily.

However, in many scenarios, particularly in corporate environments, there’s a need for private repositories. These private repositories store proprietary code, customized libraries, or binaries not meant for public release. They offer several advantages:

1. Security and Control: Private repositories ensure that sensitive code is not exposed to the public, reducing the risk of security breaches. Companies have full control over who can access and contribute to these repositories.
2. Customization: Organizations can host specialized libraries or binaries tailored to their specific requirements, which may not be relevant or available in public repositories.
3. Integration with Internal Systems: Private repositories can be integrated with internal development, build, and deployment tools, creating a seamless workflow.
4. Compliance and Governance: In industries with strict compliance requirements, private repositories help maintain the necessary standards by controlling the versions and origins of the software components used.

Setting up a private repository can be achieved using various tools and products. JFrog, for instance, offers a range of solutions in this space. Some of their products, like Artifactory, can be used to set up private repositories. These free and paid versions cater to different scales and requirements.

Artifactory is a universal repository manager that supports various package formats, not limited to Java. It can manage NPM for Node.js, NuGet for .NET, Docker images, and many more, making it a versatile choice for multi-technology environments.

The process of setting up a private repository typically involves:

• Installation and Configuration: Installing the repository management software on a server or in the cloud and configuring it according to the organization’s requirements.
• User Management: Setting up user accounts and access controls to manage who can access the repository.
• Integration: Integrating the repository with tools such as continuous integration/continuous deployment (CI/CD) pipelines, source control systems, and build tools.
• Maintenance: Regularly update the repository to ensure it runs smoothly and securely.

In summary, while public repositories like Maven Central are invaluable for open-source components, private repositories are crucial for managing proprietary, sensitive, or custom software components. Tools like JFrog Artifactory offer flexible solutions to set up and manage these repositories, ensuring security, compliance, and efficiency in software development processes.

Add a repository

 Repository Details.

Name: The repository name

Description: A description of the repository.

URL: the URL for the repository on the public Internet.

Username: the defined username on the repository.

Password: the password to access the repository.

Keys: Search for the private keys needed to access the repository in case the repository is accessed with private keys.

Manage Keys

Keys for your repositories are managed on the keys tab.

Add keys

If you’re not using the contract first approach, then this step is the very first and mandatory one. Once your domain model is ready, you can commit and deploy your app. After deployment, the back end of your app will include the exposed API endpoints that allow you to manage the entities in the domain model.If you’re not using the contract first approach, then this step is the very first and mandatory one. Once your domain model is ready, you can commit and deploy your app. After deployment, the back end of your app will include the exposed API endpoints that allow you to manage the entities in the domain model.If you’re not using the contract first approach, then this step is the very first and mandatory one. Once your domain model is ready, you can commit and deploy your app. After deployment, the back end of your app will include the exposed API endpoints that allow you to manage the entities in the domain model.If you’re not using the contract first approach, then this step is the very first and mandatory one. Once your domain model is ready, you can commit and deploy your app. After deployment, the back end of your app will include the exposed API endpoints that allow you to manage the entities in the domain model.

The post Marketplace first appeared on wizzdi.

The post My Marketplaces first appeared on wizzdi.

Reusability in Wizzdi Cloud focuses on maximizing the efficiency and utility of applications (Apps) within its ecosystem. This concept is implemented through several key features.

Main Concepts

Publishing Apps 

Wizzdi Cloud allows developers to publish their apps in marketplaces, opening up broader usage and collaboration opportunities. Other users can be invited to these marketplaces to discover their apps, use them, or extend their functionalities. This fosters a community of sharing and collaboration and encourages the development of versatile and robust applications.

Cloning 

When an App is available in a marketplace, other users can clone it to their workspaces. This cloning process allows users to take a pre-existing App and adapt or modify it according to their specific needs. This ability to customize and build upon existing Apps significantly reduces development time and effort, promoting a more efficient development process. Cloning is always into a workspace and creates a new App cloned from the previous one.
A new version cannot be re-cloned into the same app.

Importing

Rather than cloning, you can import an app directly from a marketplace into your existing application. Unlike simply adding a code dependency, importing enables you to modify the imported app inside your App while maintaining your current App structure. Your App can have an unlimited number of imported apps.
Note: In Wizzdi Clud’s current version, once an app is imported into another app, it cannot be re-imported as a new version.

Public Code Repositories

Wizzdi Cloud supports the integration of code dependencies from repositories like Maven Central. This allows developers to easily incorporate existing libraries and frameworks into their Apps, leveraging a vast ecosystem of pre-built code. Furthermore, business flows within Wizzdi can include Call Method Activities, which enable Apps to call services or methods from these referenced libraries.

Code added to the app’s dependencies doesn’t have to conform to any Wizzdi-dictated structure or interface; you can call any public method of a depend-on library, passing any required parameters to it.

In summary, reusability in Wizzdi Cloud is achieved through the ability to publish, clone, and import Apps via marketplaces and integrate external code dependencies and service calls. This approach streamlines the app development process and fosters a collaborative environment where resources and expertise are shared across the Wizzdi community.

Wizzdi Public Marketplace

The Wizzdi public marketplace functions similarly, enabling users to access a wide range of Apps developed by others. This marketplace acts as a central hub where users can find Apps that suit their needs, contributing to the culture of reusability and collaboration.

Any user of Wizzdi Cloud can now publish, clone, and import apps from the public marketplace.

Private Marketplaces

Users can create unlimited private marketplaces and completely control other users’ access. These marketplaces appear as Workspaces in the workspace list.

How To

Reuse an App

To reuse an existing app, it must be published in a private or a public marketplace.

Commit First

First, an app must be committed to be published. More information about how to Commit is available here.

To check if an application has been committed if an app has been committed, it should appear in the app overview with install or uninstall.

If an app was also deployed to the Wizzdi Cloud customer cluster, the label marked with [1] above may be changed to uninstall.

Once a change is applied to an App, the label designated [1] changes again to commit.

Publish

To Publish an App to A Market Place, click the Publish to Marketplace button [2].

Create a new Marketplace

If you have not yet created a marketplace, exit your app, go to the first screen, select My Marketplaces [3], then hit [4] and provide the marketplace with a name [5].

Note: Creating a new marketplace takes time; please be patient.

Once the marketplace has been created, it can be found in the list of workspaces. New apps cannot be created in this marketplace.

Note: A new marketplace can only be shown after sign-out and sign-in again. This is a limitation in the current Wizzdi Cloud version.

Once you see the marketplace in your list of workspaces, you can invite users to use the Apps in the marketplace.

Publish into an existing marketplace

From the overview screen, select publish to the marketplace [2 in the App overview picture above].

The dialog below appears:

Details about the published App appear [7] , including its name, runtime type, and current uncommitted version [6].

Select an existing marketplace [8] and one of the committed versions of the App[9]. Click on Publish now [10].

Once publishing is completed, a toast is presented for a few seconds.

Go to my marketplaces and click on view of the marketplace selected for publishing.

Click on view to see all published apps in this marketplace.

Import

On the same marketplace view, search and select the published app and click on details [12] to access more actions; you can see the dialog below with the marketplace on top [11]

The following screen is displayed once the details button is clicked [12 above].

• The name of the published app is displayed [13]
• Additional information on the marketplace is displayed [14], and on the version and publishing timestamp [19]
• Data visualization of the published app statistics is provided [15].
• A full App menu is available; you can view the app components before using them. A published app cannot be changed, even if you are the publisher.
• The Clone [17] and Import [18] appear on the top left part of the dialog.

To import, click on import. The dialog below appears:

• Select the published App version to import [20].
• Select the target workspace [21].
• Select the target App [22]; importing is always into an existing app.

The post Reusability in Wizzdi Cloud first appeared on wizzdi.

In Wizzdi Cloud, “Workspaces” are a key organizational feature. Think of a workspace as a virtual room or office space on the cloud where you can gather different applications that serve a common purpose or are used by a specific team. This arrangement helps keep related apps together, making them easier to manage and access.

The workspace concept is very beneficial for teamwork and collaboration. You can invite others, such as team members, clients, or stakeholders, to work together within a Workspace. Each person you invite can access the apps within that Workspace.

A critical aspect of this system is controlling who gets to see or do what within the Workspace. This is managed through “access rights” or permissions. For instance, you might allow team members to edit and update Apps while clients can only view the information. This ensures that sensitive data or functionalities are only accessible to those who need them, maintaining security and efficiency in collaboration.

In summary, Workspaces in Wizzdi Cloud help organize your applications, foster collaboration among different users, and provide a controlled environment where access rights ensure security and proper management of resource

Default workspace

The first workspace is created when you sign up for Wizzdi Cloud. Once you are signed in, you can see this workspace here:

Every new app you create is placed in the current workspace; if you have not created new workspaces, they will be in the first workspace created for you.

Creation

Selection

You can switch to a different workspace by clicking on it, and the small checkmark on the right designates the current workspace.

Management

To manage A workspace, click the ‘manage’ button next to it. You can only manage the current workspace.

Legend

1. Edit the name and the description of the workspace
2. Return to overview; ‘edit-details’ becomes available.
3. Manage users.
4. Manage User groups.

Edit Workspace Details

Edit Workspace name and description

Manage users

When inside the workspace management, click ‘users’ to see a list of the workspace users. You can use the search area to search for a user by name.

Add a user

Adding users is carried out by inviting them.

Click ‘Invite user’ to open the invitation dialog.

While inviting the user, click on the ‘+’ sign at the right of a user group to add the user to that group.

The invited user receives an email in the following format:

If the user has never signed in to Wizzdi Cloud, he or she can do it once the invitation is accepted, using the same email used to invite them.

Once logged in, they should see the following dialog inside Wizzdi Cloud.

Once the invitee accepts the invitation, the workspace is listed inside the invitee’s own workspaces list.

User groups

By default, each Workspace has three built-in groups.

Viewers, administrators, editors.

The post Workspaces first appeared on wizzdi.

OAuth 2.0

The app you build in Wizzdi Cloud may allow the deployed app’s users to sign up using their account for other services such as Google or Apple.

Supported OAuth 2.0 providers

• Google
• Apple
• Facebook
• LinkedIn
• Github
• Custom

Set OAuth 2.0 support in the Google Cloud Console

The following section depicts SSO settings for Google accounts. Other SSO providers are not detailed here. More information is available in their respective guides.

Setting up a client on Google OAuth 2.0 when the service is a server (where a secret is required) involves several steps. Here’s a general outline of the process for Google OAuth 2.0 using Google tools.

Note: The following is executed outside Wizzdi Cloud.

For a backend created with Wizzdi Cloud to support Google SSO sign-up, the build backend, that is, the App must register with Google services.

1. Google Cloud Console:
   • Go to the Google Cloud Console.
   • Create a new project or select an existing one.
2. Enable APIs:
   • In your project dashboard, navigate to the “APIs & Services” > “Dashboard” section.
   • Click on “+ ENABLE APIS AND SERVICES” to enable the necessary APIs for your application (e.g., Google Drive API, Google Sheets API, etc.).
3. Create Credentials:
   • Go to the “Credentials” page.
   • Click on “Create credentials” and select “OAuth client ID”.
4. Configure OAuth consent screen:
   • Before creating credentials, you need to configure the OAuth consent screen.
   • Provide the necessary information like the application name, user support email, and developer contact information.
5. Creating OAuth Client ID:
   • Choose the application type (e.g., Web application, Android, iOS, etc.).
   • Set up the name for the OAuth 2.0 client.
   • Specify the authorized JavaScript origins and redirect URIs for web applications.
6. Obtain Client ID and Client Secret:
   • Once the OAuth client is created, you will receive a client ID and client secret. These will be used in the App.
   • These are important and should be kept secure and confidential.

For the specific URLs to set up OAuth clients on other platforms like Facebook, GitHub, Apple, and LinkedIn, you can refer to their respective developer documentation:

• Google: Google Cloud Console
• Facebook: Facebook for Developers
• GitHub: GitHub Developer Settings
• Apple: Apple Developer Program
• LinkedIn: LinkedIn Developer Portal

Setting up an SSO provider in your app

Create SSO provider

Select SSO Provider

Select SSO provider

Select one of the available providers.

You may repeat the process and support multiple providers on your backend.

Fill in the OAuth2.0 fields:

Open the provider for edit:

Fill in the data obtained from the provider management console in the Client ID and Secret fields.

Scopes

In OAuth 2.0, scopes are permissions that define the access level your application has to a user’s data. By specifying scopes, you request authorization to interact with specific types of user information, such as emails or calendars. These scopes are provided as comma-separated values during the authentication process, dictating what data your application can retrieve or actions it can perform on behalf of the user.

Add comma-separated Scope values. In Google OAuth 2.0, these can be any of the scopes here.

For example, if you want to use the user’s email in the App to send emails to the user through SendGrid-consumed API support, you will add email to Google SSO scopes.

For other SSO  providers, use the respective documentation to get the scope list they support.

Use the values obtained from the Auth 2.0 provider for Client ID and Client Secret, and add comma-separated scopes to the Scopes field.

SSO In Deployment

SSO providers’ usage at deployment.

Regardless of where the App is deployed, the client-side user interface should provide the required access buttons for each OAuth 2.0 provider.When building the client user interface without using Wizzdi Cloud User Interface builder, The URL associated with such a button should be constructed as follows:

https://[server URL] oauth2/authorization/[provider name].

where the provider names are Google, Apple, GitHub, LinkedIn, or Facebook. A single one should be selected.

If the App was deployed on Wizdi Customer’s cloud, the URL for Google will be:
https://[app-name].[workspace-name].cluster.wizzdi.com/oauth2/authorization/google

When deploying on Wizzdi Cloud customers’ cloud, you can copy the Swagger URL from the App overview if it was deployed and replace the suffix as follows:

Replace swagger-ui.html with  oauth2/authorization/google 

Once this URL is activated, the process is pretty automatic; if this is the first time this provider is used, the user is prompted to approve access to Wizzdi Cloud, and subsequent accesses are transparent.

Note that switching among providers, for example, between Google and Apple, is equivalent to having two different users. Likewise, Do not use any of your emails for standard email password sign-up if this email is associated with any SSO provider.

Permissions

Wizzdi Cloud supports defining role configurations inside permission configurations on all three current runtimes (Spring, Flexicore, Flexiocore Boot). This provides Role-based access control to API endpoints.

In addition, the FlexiCore and Flexicore Boot runtimes have a robust security framework emphasizing multi-tenancy and role-based access control (RBAC) for API endpoints and data objects. This security framework is crucial for applications that require stringent data isolation and access control mechanisms, especially in environments serving multiple user groups or tenants. Here’s an expanded view of how this is implemented and managed:

Tenant and Role-Based Access Control

• Tenant Support: Multi-tenancy is a software architecture principle in which a single instance of the software serves multiple customers or tenants. FlexiCore achieves this through predefined database objects that segregate data by the tenant. This ensures that data is isolated between tenants and that access controls can be enforced at the tenant level.
• Role-Based Access Control (RBAC): RBAC is a method of restricting system access to authorized users. In FlexiCore, roles are defined to define permissions or access rights. These roles are then assigned to users within a tenant, determining what actions they can perform and what data they can access within the system.

Predefined Database Objects

• At the initialization of a backend built by Wizzdi Cloud and using any of the two FlexiCore runtimes, a set of predefined database objects related to security (like roles, permissions, and tenant information) are optionally created if so defined in Wizzdi Cloud while developing the App. These objects serve as the foundational elements of the security model, ensuring that the application starts with a basic level of access control and data isolation. For Spring runtime, defined roles and access to API endpoints affect the generated code.

API Endpoints for Security Management:

• FlexiCore provides multiple API endpoints dedicated to managing these security-related database objects. Administrators can dynamically modify and expand the roles, permissions, and tenant configurations when the app is deployed through these endpoints as the application evolves. This allows for a flexible and responsive security model that can adapt to new requirements or changes in the operational environment.

Web-Based User Interface for Security Objects.

• When deploying a FelxiCore-based backend, an optional user interface can be added, providing an easy-to-use security objects management console. This user interface makes use of the security-related API endpoints.

Adding and managing permissions

Accessing permissions

The Wizzdi Cloud user interface’s Permissions menu option is the entry point for configuring and managing these foundational security objects.

The Permission Configuration fields.

Permission Configuration

In the context of Wizzdi Cloud, permission configuration is a critical aspect that dictates access to various components, such as API endpoints and data. This configuration process differs between Spring and FlexiCore runtimes.

In Spring Boot runtime:

• Permission Configurations are more integrated with the codebase itself. The configurations directly influence the code that is created and executed.
• There is no API at runtime to manage Roles and permissions.
• This implies that changes in permission configurations necessitate modifications in Wizzdi Cloud, committing and deploying the App again.

In FlexiCore, both runtimes:

• Permission configurations define access at two levels: operations (API endpoints) and data.
• Once the server starts running, any missing configured permissions are instantiated within the database, making them active and enforceable.
• FlexiCore also provides  API endpoints specifically for managing these permissions. This API allows permissions to be created, modified, or deleted, allowing for dynamic control over access to data and operations.

 Permission Configuration  options

• Tenant Configurations (Flexicore runtimes Only) create predefined and missing Tenants when the App is deployed.
• Role Configurations create predefined and missing Roles when the App is deployed.
  Roles are always defined per tenant and present in the database.
  With Spring Boot runtime, as there is no multi-tenancy support, roles are app-wide and present in the generated code, not in the database.
• Permissions on API endpoints: Access control for each endpoint is delineated by the tenant or role specifications, encompassing three primary modes: Execute Without Security, Anonymous Execution, and Secured Access. The latter, serving as the default mode, permits all authenticated users endpoint access, barring the existence of explicit Permission Configuration.
  Within a Spring framework, such configurations may specify one or multiple roles authorized for endpoint access, denying access to users not associated with these roles.
  In Flexicore runtimes, access control mechanisms are augmented by providing default Tenant behavior and dynamic management through a security API at runtime. This default Tenant behavior introduces tenant-specific access control policies, which are subject to being overridden by role-based permissions.
  In Flexicore run times, as with all other permissions configurations, API access is stored in the database and can be modified on a deployed App through the provided APIs or permission management app.

You may define multiple Permission Configurations. The final behavior at runtime is a combination of all configurations. In most cases, a single configuration is sufficient.

Once the permission configuration is created, the following view is available.

Tenant Configurations (Flexicore Runtimes only)

To create and manage Tenant Configurations, click on Tenants.

The above dialog also appears when managing the existing Permission Configuration.

Create Tenant configuration.

To create a Tenant Configuration, add a name. The tenant is created when the App runs on the server.

Europe Tenant

The view of Tenant Configurations is similar to this one:

Role Configurations (all runtimes)

When using Flexicore runtimes, roles and permissions are configured per tenant, allowing tenant administrators to define roles.

Role Configurations are created within Tenant Configurations. This setup defines the permissions and access levels assignable to users within a tenant’s domain on Wizzdi Cloud.

When FlexiCore runtimes are utilized, role management extends to the server level through API endpoints. This enables the creation or adjustment of roles directly on the application’s target server. The roles available at any given time are predefined through Role Configurations within the Tenant Configurations and those created or modified using the API endpoints. This design allows for managing roles based on immediate needs or changes.

When running a Spring runtime, Tenants are unsupported, and Roles are App-wide.

Create a Role Configuration

Role Configurations, empty view.

Filled Role Configuration.

Access Rules priority

In systems where permission configurations might conflict, the hierarchy prioritizes permissions assigned to a Role over those set at the Tenant level, allowing role-specific permissions to override tenant-wide defaults.

FlexiCore-runtime-based applications utilize Security API endpoints that allow for precise permission control at the AppUser level. This means permissions or denials assigned to an individual user will override those assigned to the Roles and Tenants with which this user is associated.

This hierarchical approach to permission control ensures that when conflicts arise, the system resolves them by prioritizing user-specific permissions over role-based permissions and role-based permissions over tenant-wide settings.

FlexiCore-based runtimes using the standard API are the only runtimes that can have AppUsers permissions applied at runtime.

Operation Permissions Configuration.

This section applies to pure Spring runtime, Flexicore runtime, and Flexicore Boot runtime.

Create a Permission Configuration for API endpoints (operations).

When creating a permission configuration, we define two components. The permission target includes a list of tenants and roles associated with one or more operations.

When a tenant is associated with permission, it defines the default behavior for the included operations for that tenant on a running system.  Tenant administrators may want different system behavior for their users. Some may wish a loose system, while others prefer restricted access by default. When the access is limited at the tenant level, associating with roles is required to open it for some of the tenants‘ users.

It should be noted that this flexibility of changes on a running system is available only with Flexicore runtimes. Changing the permissions on a pure Spring runtime requires changing the App in Wizzdi Cloud and redeploying the App.

In the above image, the targets selected are one Role from a Tenant and one Tenant, the America Tenant.

The permission pertains to all users of the Europe Tenant (marked in blue) and only to the Administrator Role (marked in yellow) in the America Tenant.

In the above image, two endpoints have been selected when selecting an endpoint. Either allow or deny may be chosen.

Security On Exposed APIs

Available in all runtimes.

The exposed API endpoints have additional settings defining their behavior and the permissions related to them.

Accessing the security settings on an Exposed API endpoint.

When setting security directly on the Endpoint, The following options are available:

• Execute without Security: At runtime, the user must be signed in to access the endpoint, and no other security restrictions are applied.
• Anonymous Execution: Anyone can execute this endpoint at runtime. For example, a sign-in/sign-up endpoint must be accessible to all.
• Restricted execution: when none of the above two options is selected, the following section applies.

Select Security Options on an API endpoint.

When configuring the access to an endpoint, we first need to select Tenants or Roles. 

Then click on the ‘+’ sign to add a Tenant Permission Configuration or a Roles Permission Configuration.

When Adding a Role/Tenant Configuration, you can select an existing Permission configuration or create a new one.

Selecting a Tenant Configuration for the endpoint.

Adding a Role Permission Configuration or Tenant Permission Configuration may be repeated. A summary of all such configurations created so far is available.

Permissions on Data

Important Note:

Support for data access control in Wizddi Cloud is available for FlexiCore and FlexiCore Boot runtimes only. Furthermore, all entities must directly or indirectly extend the Flexicore-defined entity SecuredBasic.

As in this domain model, Book and Author both extend the SecuredBasic entity.

Entities extend SecuredBasic.

Model-Level Permissions

• Design Phase on Wizzdi Cloud: Model-level permissions can be established during the application’s design phase. These permissions define access controls for entities within the application’s model, setting broad access rights for Roles or Tenants to all records of a particular entity.
• Runtime: Model-level permissions can be modified and created at runtime using the provided API.

Instance-Level Permissions

• Runtime only: Instance-level permissions are specific to the runtime environment and are applied to individual data records within the application. These permissions allow for granular control over access to particular data instances.
• Instances Groups: The run time instance-level access control includes the concept of Instance Group, where a heterogenous collection of instances can be subject to permissions as a whole.
• Supported by API endpoints: Instance-level permission management is available only at runtime using the provided API endpoints and only for Flexicore and Flexicore Boot.

Model-level permissions, the details.

Data permissions, no permissions yet.

Click on Create Data Permissions.

In the above dialog, you must set the Target, a list of Roles and/or Tenants, the Subject, the entities for this permission, and the operation. The API endpoint you want to associate the permission with.

Multiple targets, Entities, and Operations can be included in a single Data Permission Configuration.

In the above screenshot, targets, Tenants, and Roles are marked yellow, Entities from the data model are marked blue, and operations and API endpoints are marked green.

When Add Permissions is clicked, a list of permissions generated from the above is displayed.

Applying Data Model Security From Domain Model Editor.

Note: When an app is developed using Wizzdi Cloud, the structure and properties of its entities (such as data models or object types) are predefined. However, the actual data instances (or records) corresponding to these entities are generated only when the app is deployed and used in a live environment. Consequently, security measures related to the entities can be implemented during the app’s design phase within Wizzdi Cloud.

In addition to these design-time security configurations, Flexicore runtimes also support applying dynamic access control measures at runtime through its system APIs. These APIs can be used to apply both Entity-level and instance-level access rules.

When an Entity is selected in a domain model diagram, and the runtime is one of Flexicore’s runtimes, the ‘Manage Security‘ button is available.

Manage the Security of an Entity.

When managing an Entity’s security, Derived Security or direct Security settings can be selected. In derived security, the Entity’s security becomes the same as that of a related Entity; see below.

Entity Security Settings (direct)

The Entity Security setting is defined for this Entity, for example, if a Role can operate on all Entity instances. Finer-grained access control on specific instances or a group of instances (Permission Groups) is available only at runtime.

To add an Entity Security permission, click the ‘+’ sign after you select Tenants or Roles.

When ‘Tenants‘ is selected, the entity permission created defines the default behavior in this tenant.

Data-model permissions

You have the option to create a new Permission Configuration or to use an existing one.

Define the default Tenant-wide permission on an Entity.

Derived Security

Derived security means that the access permissions assigned to a particular entity automatically affect the access permissions of other entities linked to it through a derived security relationship. This relationship is defined based on the data model’s structure, where entities are associated through a one-to-many relationship.

How Derived Security Works

• Defining Access Rights on a Primary Entity: When access rights are granted or denied to an entity (the primary entity), these permissions are considered when determining access to other entities associated with the primary entity in the context of derived security.
• Associated Entities’ Access Rights: Entities with the primary entity associated with derived security inherit the access rights from that primary entity. If an entity is configured to derive its security from another entity, any access rights defined for the primary entity will similarly affect the derived entity. Data model security can be configured on Wizzdi Cloud and managed through the provided APIs.
• Influence on Associated instances: Entity instances of an Entity defined with a derived security get access rights from the associated instances of the Primary Entity defined in the derived security. Instance-level access control can only be managed through the provided API endpoints in runtime. A web app for managing access rights is available.

Example Scenario: Entity Association

Consider a scenario with three entities: Project, Task, and User. If the Task entity is associated with the Project entity in such a way that its access rights are derived from the Project, and a user has restricted access to a specific Project, then by the principle of derived security, the user will also have restricted access to the Tasks associated with that Project. Similarly, if a User entity’s access to projects is defined through derived security, the user’s permissions on the Project entity would affect their access to related entities.

Configuration and Implementation

• Data-Model Configuration: In the data model, entities must be explicitly configured to utilize derived security, specifying which fields or relationships govern the derived permissions. This setup involves identifying the paths through which security settings are inherited.
• Runtime Behavior: At runtime, the application evaluates the derived security configurations to dynamically apply the appropriate access permissions across entities based on the established relationships and inherited rights. This evaluation ensures that the access control logic remains consistent with the data model’s structure and the intended security policies.

Registration

Users registering to your backend may be associated with a default Role. To set the default role, select one of the predefined Role Configurations.

Admin User

Define the user having full rights on permissions in the system. When using Spring runtime, this user can access all the exposed endpoints.

Permissions Web App

In Flexicore Runtime, in addition to having open access to all exposed endpoints, this user can manage permissions, tenants, roles, and users via the available web app.

Below are some screenshots of the Web App. Solution providers can use the Web App or create a user interface based on the exposed API.

Tenants management.

Roles management.

Users management. Tenant and Role associations are displayed.

Permissions management for both operations and data.

An instance-group management.

The above screenshot depicts a single instance-group management. An instance group groups multiple instances so that permissions to the entire group can be easily managed.

Not shown here is the Operation-Group management, which allows concise permission management on multiple operations.

The above screenshots are not full and are presented here just to help you understand the permissions management web app.

The post Security first appeared on wizzdi.