DEV Community: fastcode-inc

Angular Material UI/Theme Builder

fastcode-inc — Sat, 12 Feb 2022 16:29:28 +0000

Over the past year, we have been developing a drag-and-drop Angular Material UI/Theme Builder. The target audience is angular developers who already have experience with Google's Angular and Angular Material Components.

The Angular Material UI/Theme builder is a What-You-See-Is-What-You-Get (WYSIWYG) drag-and-drop builder that allows angular developers to build reactive forms and views by dragging and dropping Google's Angular Material Components onto an Angular Flex layout. The properties, styles, and events of each component can be configured through panels and the builder generates all the code.

The code that is being generated can be viewed through three tabs: (i) Markup tab for the HTML, (ii) Script tab for TypeScript and (iii) Styles tab for the CSS.

The UI Builder also incorporates Angular Material Theme Builder that can be used to build a theme and apply the theme to the views you have built using the UI Builder.

You can also bind the views/forms to static data or ReST-API based data sources.

The Table UI Component in the Angular Material library is very basic and not sufficient for most applications. Therefore, in addition to the Angular Material Components, the builder also integrates ag-grid (https://www.ag-grid.com) for Grid Control.

The goal of this UI/Theme Builder is to reduce the time to develop a view by over 50%. Again, this UI/Theme Builder is targeted towards developers who already have experience with Angular and Angular Material.

I am looking for the community feedback on whether or not you would use such a UI/Theme Builder. Secondly, would you be interested in trying the UI/Theme Builder and providing us feedback?

Build a Spring Boot ReST API

fastcode-inc — Tue, 13 Apr 2021 20:30:59 +0000

Welcome back! In the first blog article, we developed a simple Spring Boot application that prints “Hello World” to the console. In this article, we will build a ReST API that can be called by the API clients.

In a typical Spring Boot application, you will have a relational database with a number of tables that are related to each other. In this article, to keep things simple, we will focus on an application with a single table. In the next article, we will extend this example to include multiple tables and their relationships.

Let’s imagine that we are building a simple Timesheet application.
This application allows employees to enter the hours they worked daily on different tasks and submit the timesheet every two weeks.

In this article, we will focus on building a ReST API for just the Customer table.

Let’s assume that the Customer table in the database includes the following fields:

*customerid
*name
*description
*isActive

Our goal is to develop a ReST API that can be called to perform the following operations:

*Create a new customer
*Get a list of all the customers
*Update an existing customer
*Delete an existing customer

The above operations are known as C.R.U.D (Create, Read, Update, Delete) operations.

Step-1:

First, we need to understand some basic concepts on how we can manipulate the data in a database from a Java/Spring Boot application. This can be done either through JDBC (Java Database Connectivity) API that is a part of the Java Standard Edition or through JPA (Java Persistence API; now renamed to Jakarta Persistence) that is a part of the Java Enterprise Edition.

The Spring framework provides further abstractions on these APIs to make it easier for developers to use these APIs. In this article, we will focus on using JPA.

JPA describes the management of relational data in enterprise Java applications. The Hibernate Object Relational Mapper (ORM) is one of the implementers of the Java Persistence API. In this application, we will be using Hibernate ORM and it’s JPA implementation.

In JPA, a database table is represented as a Java Class. JPA provides a mechanism to persist objects of this Java class to the database table and the rows of the database table back to objects of this Java class. There are a number of rules that are defined by JPA on how an entity needs to be defined. According to the JPA 2.0 specification, these rules are as follows:

The class must be annotated with the @Entity (javax.persistence.Entity) annotation.
Every entity class must have a primary key that uniquely identifies the entity. The primary key is annotated with @id annotation
The entity class must have a no-arg constructor. It may have other constructors as well. The no-arg constructor must be public or protected.
The entity class must be a top-level class. An enum or interface must not be designated as an entity.
The entity class must not be final. No methods or persistent instance variables of the entity class may be final.
Persistent instance variables must be declared private, protected, or package-private and can be accessed directly only by the entity class’s methods. Clients must access the entity’s state through accessor or business methods.
If an entity instance is to be passed by value as a detached object (e.g., through a remote interface), the entity class must implement the Serializable interface.
Both abstract and concrete classes can be entities. Entities may extend non-entity classes as well as entity classes, and non-entity classes may extend entity classes.

Using the rules above, let’s define our Customer entity as follows:

package com.example.demo;

import javax.persistence.*;
import java.io.Serializable;

@Entity
@Table(name = "customer")
public class CustomerEntity implements Serializable {

   public CustomerEntity() {}

 @Id
 @GeneratedValue(strategy = GenerationType.IDENTITY)
 @Column(name = "customerid", nullable = false)
 private Long customerid;

 @Basic
 @Column(name = "name", nullable = true)
 private String name;

 @Basic
 @Column(name = "description", nullable = true)
 private String description;

 @Basic
 @Column(name = "isactive", nullable = true)
 private Boolean isActive;

 public Long getCustomerid() {
   return customerid;
 }

 public void setCustomerid(Long customerid) {
   this.customerid = customerid;
 }

 public String getName() {
   return name;
 }

 public void setName(String name) {
   this.name = name;
 }

 public String getDescription() {
   return description;
 }

 public void setDescription(String description) {
   this.description = description;
 }

 public Boolean getIsActive() {
   return isactive;
 }

 public void setIsActive(Boolean isactive) {
   this.isActive = isActive;
 }
}

Points to note:

The @id annotation defines the primary key. We can generate the identifiers in different ways which are specified by the @GeneratedValue annotation. We can choose from the following Id generation strategies: AUTO, TABLE, SEQUENCE, or IDENTITY. If we don't specify a value explicitly, the generation type defaults to AUTO. When we use the IDENTITY generation type, the database auto-increments the Id values
It is also important to understand the different access types in JPA. This article provides more information on the access types. In the customer entity above, we are using Field access type because we are declaring the @id annotation on a field rather than on the get access method.
If we do not use the @Table annotation, the name of the entity will be considered the name of the table. In such cases, we can omit the @Table annotation. In most cases, the name of the table in the database and the name of the entity will not be the same. In these cases, we can specify the table name using the @Table annotation
The attributes of the @Column annotation include it’s name, length, nullable, and unique. The name attribute specifies the name of the table column. The length attribute specifies the column length. The nullable attribute specifies whether or not the column is nullable, and the unique attribute specifies whether or not the column is unique. If we don't specify this annotation, the name of the field will be considered the name of the column in the table.
JPA supports Java data types as persistable fields of an entity, often known as the basic types. A field or property can be marked with @basic annotation, which is optional. The @basic annotation has two attributes - optional (true, false) and fetch (EAGER, LAZY). By default, optional is set to true and fetch is set to EAGER loading. When optional is set to true, the field/property will accept null values. Lazy loading will only make sense when we have a large Serializable object mapped as a basic type. The JPA specification strictly limits the Java types that can be marked as basic to the following:

Java primitive types (boolean, int, etc)
wrappers for the primitive types (java.lang.Boolean, java.lang.Integer, etc)
java.lang.String
java.math.BigInteger
java.math.BigDecimal
java.util.Date
java.util.Calendar
java.sql.Date
java.sql.Time
java.sql.Timestamp
byte[]
Byte[]
char[]
Character[]
enums
any other type that implements Serializabl

N-layered Architecture

To build a CRUD API for the Customer database table, we will be using a n-layered architecture. This architecture is not necessary for an application with a single database table, but becomes necessary as the number of tables increase and more business logic is added to the application.

The diagram below shows the layers of this architecture:

Domain layer: The domain layer consists of domain classes. In our sample CRUD application, these domain classes are equivalent to the JPA entity classes, which is a single class named CustomerEntity.java that we previously described.

Repository layer: The repository layer in a Spring Boot application consists of Spring Data JPA repositories. Spring Boot makes it very simple to develop these repositories that can enable you to perform basic CRUD operations on an entity. Here’s the JPA repository for the customer entity:

@Repository("customerRepository")
public interface ICustomerRepository extends JpaRepository<CustomerEntity, Long>{}

All we need to do to create a repository is to define an interface that extends the JpaRepository interface, passing in the name of the entity and the data type for the primary key of the entity.

Spring Boot automatically provides an implementation class for this interface. All the methods specified in the JpaRepository interface at this link are therefore available for us to use. Also note that this interface is annotated with @Repository interface. More details on this and other commonly used annotations can be found in this article.

Application Services layer: This layer is used for two purposes: (a) provide transactional support and (b) convert from an entity to a Data Transfer Object (DTO) and vice-versa.

An application transaction is a sequence of application actions that are considered a single logical unit by the application. For a more detailed explanation of Spring transactions, please refer to these series of posts and this other post for an in-depth look at the pitfalls.

DTOs are important for separation of concerns - separating what’s stored in the database from what’s returned to the client of the API. An entity stores what’s stored in the database, whereas a DTO stores what is returned back to the API client. For a more detailed explanation on why DTOs are necessary, please refer to this post.

Again sticking with the separation of concerns principle, we define both an interface and an implementation class in the Application Services layer for the customer entity. This layer will call the JPA repository layer we previously defined.

ICustomerAppService.java

public interface ICustomerAppService {

//CRUD Operations
CreateCustomerOutput create(CreateCustomerInput customer);

void delete(Long id);

UpdateCustomerOutput update(Long id, UpdateCustomerInput input);

FindCustomerByIdOutput findById(Long id);

}

CustomerAppService.java

@Service("customerAppService")
public class CustomerAppService implements ICustomerAppService {

 @Qualifier("customerRepository")
 @NonNull
 protected final ICustomerRepository _customerRepository;

 @Qualifier("ICustomerMapperImpl")
 @NonNull
 protected final ICustomerMapper mapper;

 @NonNull
 protected final LoggingHelper logHelper;

 public CustomerAppService(@NonNull ICustomerRepository 
 _customerRepository, @NonNull ICustomerMapper mapper, 
 @NonNull LoggingHelper logHelper) {
 this._customerRepository = _customerRepository;
 this.mapper = mapper;
 this.logHelper = logHelper;
 }

 @Transactional(propagation = Propagation.REQUIRED)
 public CreateCustomerOutput create(CreateCustomerInput input) {

 CustomerEntity customer = mapper.createCustomerInputToCustomerEntity(input);
 CustomerEntity createdCustomer = _customerRepository.save(customer);
 return mapper.customerEntityToCreateCustomerOutput(createdCustomer);
 }

 @Transactional(propagation = Propagation.REQUIRED)
 public UpdateCustomerOutput update(Long customerId, 
 UpdateCustomerInput input) {

 CustomerEntity customer = mapper.updateCustomerInputToCustomerEntity(input);
 CustomerEntity updatedCustomer = _customerRepository.save(customer);
 return mapper.customerEntityToUpdateCustomerOutput(updatedCustomer);
 }

 @Transactional(propagation = Propagation.REQUIRED)
 public void delete(Long customerId) {

 CustomerEntity existing = _customerRepository.findById(customerId).orElse(null);
 _customerRepository.delete(existing);
 }

 @Transactional(propagation = Propagation.NOT_SUPPORTED)
 public FindCustomerByIdOutput findById(Long customerId) {

 CustomerEntity foundCustomer = _customerRepository.findById(customerId).orElse(null);
 if (foundCustomer == null) return null;
 return mapper.customerEntityToFindCustomerByIdOutput(foundCustomer);

Points to Note:

CRUD methods are defined in the application service class
The class is annotated with @Service annotation. To understand this annotation, please refer to this article.
The application service class depends on three other classes - Customer Repository, Customer Mapper, and Logging Helper. These dependencies are injected into the Application Service class using Spring Dependency Injection mechanism.

Spring allows us to inject dependencies using three methods - constructor-based injection, setter-based injection, or field-based injection. As explained in this article, Constructor-based injection is the preferred way of injecting dependencies.

In constructor-based injection, the dependencies required for the class are provided as arguments to the constructor as seen in the Application Service above.
@Transactional annotation is used at a method-level on public methods
We define and use the following DTOs. Every method, where appropriate, takes an input DTO and returns an output DTO

*CreateCustomerInput
*CreateCustomerOutput
*UpdateCustomerInput
*UpdateCustomerOutput
*FindCustomerByIdOutput

We use a mapping library, MapStruct, to automatically map an entity to a DTO and vice-versa.

ReST Controller layer: This layer is used to present an interface for clients that want to perform CRUD operations on the data on the database tables using http protocol. In our sample application, we have a single ReSTController because we have a single entity/table.

@RestController
@RequestMapping("/customer")
public class CustomerController {

 @Qualifier("customerAppService")
 @NonNull
 protected final ICustomerAppService _customerAppService;

 @Qualifier("projectAppService")
 @NonNull
 protected final IProjectAppService _projectAppService;

 @NonNull
 protected final LoggingHelper logHelper;

 @NonNull
 protected final Environment env;

 public CustomerController(@NonNull ICustomerAppService _customerAppService, @NonNull IProjectAppService 
 _projectAppService, @NonNull LoggingHelper logHelper, @NonNull Environment env) {
 this._customerAppService = _customerAppService;
 this._projectAppService = _projectAppService;
 this.logHelper = logHelper;
 this.env = env;
 }

 @RequestMapping(method = RequestMethod.POST, consumes = { "application/json" }, produces = { "application/json" })
 public ResponseEntity<CreateCustomerOutput> create(@RequestBody @Valid CreateCustomerInput customer) {
 CreateCustomerOutput output = _customerAppService.create(customer);
 return new ResponseEntity(output, HttpStatus.OK);
 }

 // ------------ Delete customer ------------
 @ResponseStatus(value = HttpStatus.NO_CONTENT)
 @RequestMapping(value = "/{id}", method = RequestMethod.DELETE, 
 consumes = { "application/json" })
 public void delete(@PathVariable String id) {
 FindCustomerByIdOutput output = _customerAppService.findById(Long.valueOf(id));
 Optional
 .ofNullable(output)
 .orElseThrow(
 () -> new EntityNotFoundException(String.format("There does not exist a customer with a id=%s", id))
 );

 _customerAppService.delete(Long.valueOf(id));
 }

 // ------------ Update customer ------------
 @RequestMapping(
 value = "/{id}",
 method = RequestMethod.PUT,
 consumes = { "application/json" },
 produces = { "application/json" }
 )

 public ResponseEntity<UpdateCustomerOutput> update(
 @PathVariable String id,
 @RequestBody @Valid UpdateCustomerInput customer
 ) {
 FindCustomerByIdOutput currentCustomer = _customerAppService.findById(Long.valueOf(id));
 Optional
 .ofNullable(currentCustomer)
 .orElseThrow(
 () -> new EntityNotFoundException(String.format("Unable to update. Customer with id=%s not found.", id))
 );

 customer.setVersiono(currentCustomer.getVersiono());
 UpdateCustomerOutput output = _customerAppService.update(Long.valueOf(id), customer);
 return new ResponseEntity(output, HttpStatus.OK);
 }

 @RequestMapping(
 value = "/{id}",
 method = RequestMethod.GET,
 consumes = { "application/json" },
 produces = { "application/json" }
 )
 public ResponseEntity<FindCustomerByIdOutput> findById(@PathVariable String id) {
 FindCustomerByIdOutput output = _customerAppService.findById(Long.valueOf(id));
 Optional.ofNullable(output).orElseThrow(() -> new EntityNotFoundException(String.format("Not found")));

 return new ResponseEntity(output, HttpStatus.OK);
 }
}

Points to Note:

We are passing in the dependencies using Spring Constructor dependency injection
Every ReST controller method has a @RequestMapping annotation, a method type, and the content-type the method consumes and produces.
Where we return back a response, we are using a ResponseEntity
Although it’s not apparent from the code above, the incoming JSON content is translated into a Java object using the Jackson Mapping library

In this blog article, we have seen how to build a Spring Boot ReST API for a single table. However, in the real-world, an API will be built using multiple tables that are related to each other. In the next (third) blog article, we will discuss how we can handle multiple tables.

Build a Spring Boot ReST API

fastcode-inc — Tue, 13 Apr 2021 20:30:43 +0000

In this blog article series, we will incrementally build a Spring Boot ReST API. We will start from scratch so that readers who are new to Spring Boot can easily follow along with us.

In this first article, we will develop a simple Spring Boot application that prints “Hello World” to the console.

Step-1:

Go to the Spring Initializr website (https://start.spring.io/) and create/download a Spring Boot project. Use the settings shown in the image below:

Step-2:

Unzip the zip file. The zip file will be unzipped into demo directory

Step-3:

Ensure that you have Maven and JDK 1.8 installed on your computer. Also ensure that you add them to your PATH so that you can access the commands java and mvn from your command window.

You can get them from the following location:

JDK 1.8: https://adoptopenjdk.net/variant=openjdk8&jvmVariant=hotspot

Maven: https://maven.apache.org/download.cgi

Step-4:

From a command window, go to the directory demo, and compile and package the application using the following command:

mvn clean package

You will see that the application is compiled and a jar file named demo-0.0.1-SNAPSHOT.jar is created in a new directory named target.

When you do a maven clean, this target directory (along with all the artifacts in this directory) is deleted. The maven package step both compiles the application and packages it in a jar file. To further understand the different maven lifecycle steps, please refer to this webpage.

To run this application, execute the following command from the command line:

java -jar target\demo-0.0.1-SNAPSHOT.jar (if you are using windows) or java -jar target/demo-0.0.1-SNAPSHOT.jar (if you are using Mac or Linux)

This will run the application. However, this application does not do anything and therefore runs and exits.

Step-5:

Now let’s look at the only source file (*.java) we have in this application - DemoApplication.java which is located at demo/src/main/java/com/example/demo/DemoApplication.java.

package com.example.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class DemoApplication {

 public static void main(String[] args) {
     SpringApplication.run(DemoApplication.class, args);
  }

}

First, notice that there is a main method. This method doesn’t do anything except to run the application. Also, notice the @SpringBootApplication annotation on the class. This annotation is equivalent to three separate Spring Boot annotations:

@SpringBootApplication = @Configuration + @ComponentScan + @EnableAutoConfiguration

You can learn what these annotations mean at the Spring website.

Step-6:

Now, let’s write a method that will print “Hello World!” to the console. Here we go:

package com.example.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class DemoApplication {

 public static void main(String[] args) {
     SpringApplication.run(DemoApplication.class, args);
 HelloWorld();
  }

 private static void HelloWorld() {
     System.out.println("Hello World!");
  }

}

Notice the method Hello() defined in the DemoApplication class. It’s defined as static - otherwise, you will get the error “Non-static method 'HelloWorld()' cannot be referenced from a static context”.

Now, you can re-run the maven command, mvn clean package, and then run the program using java -jar target\demo-0.0.1-SNAPSHOT.jar (if you are using windows) or java -jar target/demo-0.0.1-SNAPSHOT.jar (if you are using Mac or Linux).

You will see a message “Hello World!” printed to the console window.

That’s all for this article. In the next article, we will extend this application and build an API that can be called from external systems.

Angular Low-code platform

fastcode-inc — Sun, 16 Aug 2020 18:54:29 +0000

A platform to reduce the time to develop enterprise-grade Angular & Spring Boot web apps by more than 50% - https://www.getfastcode.com.

Spring Boot Low-code platform

fastcode-inc — Sun, 16 Aug 2020 18:24:36 +0000

A platform to reduce the time to develop Spring Boot & Angular web apps by more than 50% - https://www.getfastcode.com.

Low-code platform startup - Request for feedback

fastcode-inc — Sun, 16 Aug 2020 12:31:45 +0000

Hello friends,

We will be launching our startup https://getfastCode.com in a couple of months.

fastCode helps professional web app developers significantly reduce the time it takes to develop a web app. We are currently supporting Spring Boot on the back-end and Angular (and Angular Material) on the front-end. It's a free platform.

I would love to get your feedback on whether you think that fastCode will be useful to you and for what use cases.

Thank you very much for any feedback you can provide us.

Low-code platforms & Full-code developers - a match made in hell?

fastcode-inc — Sun, 16 Aug 2020 12:08:32 +0000

Developing enterprise-grade web apps from scratch using open-source front-end and backend frameworks takes a long time. Nowadays, customers are looking for quick and cost-effective solutions and are gravitating towards using no-code and low-code app development platforms. How can full-stack developers thrive in this new world of no-code and low-code platforms?

No-code and Low-code Platforms

One purpose of these platforms is to increase the pool of available web app developers by tapping into the broader workforce of non-technical and semi-technical employees. Vendors have developed no-code platforms to be used by non-technical employees to build simple applications, and low-code platforms to be used by employees with basic technical skills (ex: SQL, JavaScript) to develop more complex enterprise applications. Secondly, these platforms can reduce web app development time by over 50% compared to the traditional web app development approach.

Currently, there are a large number of vendors competing in the no-code and low-code market segments. No-code platform vendors include AppSheet (Google), Betty Blocks, QuickBase, Airtable, Bubble, and Microsoft PowerApps. Low-code platform vendors include Microsoft PowerApps, OutSystems, Mendix, Salesforce Lightning Platform, Nintex, Appian, and Pegasystems.

We won’t discuss no-code platforms because they cater to non-technical users for developing simple apps. It’s unlikely that you, as a professional web app developer, will be asked to work on a no-code platform.

Low-code platforms, on the other hand, are used to develop more complex apps. Building a web app using these low-code platforms has several disadvantages for a professional web developer who is used to developing apps using open-source front-end and back-end frameworks. Here is a blog post from a professional web app developer about his experiences working on one of these low-code platforms.

Problem-1: No control over source code

Low-code platforms provide a visual metaphor to develop web apps. Even the app’s business logic is implemented by dragging and dropping code control statements such as if/then/else. Therefore, developers working on these platforms have little control over source code. Not having control over source code creates at least two issues: (a) It’s challenging to develop domain-driven apps with complex business logic, (b) debugging problems can be very difficult and frustrating.

Problem-2: Limits career mobility

Working full-time on a low-code platform can limit the career mobility of professional web app developers. They would lose their current technical skills in open programming languages and frameworks and gain skills in a proprietary low-code platform. Suppose this proprietary low-code platform is not widely adopted across employers, which is currently the case for any specific low-code platform. In that case, the developer’s low-code platform skills can only be used at another employer who has also adopted the same low-code platform. This severely limits the career mobility of the developer.

Is there a better option? Yes. Why not build a low-code platform for professional web app developers that satisfies both the employers’ need for speed and developers’ needs for control and career mobility? We are calling such platforms as "open" low-code platforms. How do these platforms work? Read on …

Generate Boilerplate Code

When developing web applications, there is quite a bit of cut/paste/modify work.

Most of the applications use an N-layered architecture. In this architecture, to provide a ReST API for the CRUD operations on a database table (entity), we need to develop code for the entity, the DAO (Data Access Object) layer, the services layer, and the ReST controller layer. Similarly, to create UI screens to allow end-users to perform CRUD operations, we need to develop UI components and a front-end services layer that interacts with the back-end ReST API. Once this work is completed for a single database table (entity), similar work must be repeated for each table of the database schema.

Imagine having to do this for 50 database tables – this is tedious and error-prone work.

A better approach would be to automate the generation of this boilerplate code. To automate, we can develop an application generator that reads the database schema and generates the back-end and front-end code to allow end-users to perform CRUD operations on database tables (entities).

Provide Add-ons for Common App Functionality

Web applications have common functionality that repeats across applications. Examples of such common functionality include Authentication & Authorization, Document management, Transactional Emails, Jobs Scheduler, User Registration, and Embedded Reporting. Almost every web application I have been involved in developing required each of these capabilities. In each case, my development team reinvented the wheel and built these cross-cutting concerns from scratch because we never thought about building generic and customizable common functionality that can be used across web apps- what a waste of effort & time!

If the base code for such common functionality was already built and available, we can re-use it and customized it as needed for each web application.

Provide Visual Development Tools

Developing enterprise applications involves developing custom functionality such as designing a database schema or domain model, building custom screens for non-CRUD operations, building enterprise-specific themes (colors, fonts), and developing integrations with external systems.

Professional development teams can further reduce the application development time & cost by using visual development tools that accelerate the development of these custom functionality artifacts.

Support Development Team’s Preferred Stack

When developing enterprise applications, professional development teams have specific preferences over open technologies used, such as front-end and back-end frameworks, object-relational mapping tools, UI component frameworks, and dependency management systems. Specific technologies are preferred by teams either because they are the enterprise architecture standard or because most team members have experience using these technologies.

By supporting the specific technologies chosen by development teams, open low-code platforms for professional developers can help and not reduce the acceleration of application development.

Conclusion

The approach mentioned above allows development teams to reduce the time to develop a web app by over 50%, similar to proprietary low-code platforms. Additionally, developers have full control over the source code, eliminating their inability to easily debug problems and develop domain-driven apps with complex business. Finally, developers use open technologies when developing web apps, eliminating the problem of limited career mobility.

In summary, a low-code platform built for professional web app developers eliminates the disadvantages of proprietary low-code platforms while preserving their advantage of rapid app development.