Generate Your Own Application

Step-1: Design your database schema

The first step in using fastCode's application generator is to design your database. fastCode currently supports PostgreSQL and MySQL databases, with support for Oracle and Microsoft SQL server databases coming very soon.

A SQL database contains multiple objects such as tables, views, stored procedures, functions, indexes, sequences, and triggers. fastCode requires you to design only the tables and their relationships.

In the current version (version 0.5.0), we have developed fastCode as a database-first application generator that reverse engineers a database to generate the application. Therefore, fastCode can be used for both greenfield application development, where you first design your database tables and their relationships, and application modernization, where you have an existing database with tables and their relationships.

There are a number of free and commercial tools available in the market that can help you design your database tables and their relationships, including tools from database vendors.

The application generator reads the database table information and generates the application back-end in Java / Spring Boot using an N-Layered architecture and the front-end using Angular.

Step-2: Run the application generator

fastCode's application generator can generate an application's back-end and front-end by reading database table information.

The different components of the application generator are as follows:

Front-end Base Application Generator: This component uses Angular CLI to generate a base front-end application.

Back-end Base Application Generator: This component uses Spring Boot CLI to generate a base back-end application.

Entity Generator: This component takes a database schema as input and generates JPA entities.

Apache FreeMarker Templates: These templates are used to generate the front-end and back-end code based on the templates and the JPA entities that are generated by the entity generator.

Code Generator: This component is the orchestration engine. It (a) invokes the front-end and back-end base application generators and (b) uses the JPA entities generated by the reverse mapping tool, along with front-end and back-end FreeMarker templates to generate the front-end and back-end code.

Below, we describe the information that needs to be provided to the application generator on each screen.

Screen-1: Data source Information

The first screen requires you to provide information on the data source that will be used to generate the application. Currently, fastCode supports PostgreSQL and MySQL databases. Depending on the data source selected, the fields for the connection change. The specific fields for each database are specified below:


Database Name

Schema Name






Database Name





NOTE: If you are using the fastCode cloud application generator, the data source selected should be accessible online through a public IP address.

Screen-2: Application Information

In this screen, we need to provide the application information.

Application Name: The name of the application

Description: An optional application description

The next two fields, Group and Artifact, together constitute the Java package name that will be used when generating the application.

Group: The group name of the application
Artifact: The artifact name of the application

Generation Type: fastCode allows for the generation of both the back-end and front-end of the application or just the back-end of the application. The latter option is useful when you only want to generate a back-end ReST API.

The application generator can generate an application and make it available for download. Optionally, you can generate the application as a repository in your GitHub account. In order to allow the application generator to generate the application in a private repository your GitHub account, you must authorize it to access your GitHub account.

Screen-3: Authentication Information

Database Authentication

The first authentication method is database authentication where the user credentials are stored in the application database. When using this authentication method, we also need to specify whether the application's database consists of a User table. We need to specify this information because, by default, fastCode generates its own User, Role, and Permission tables and we don't want to generate a User table if the application's schema already has an existing User table.

LDAP Authentication

The next method of authentication is LDAP / Active Directory where the user credentials are stored in a directory server such as Microsoft Active Directory that supports the LDAP protocol. When this method of authentication is selected, the following information needs to be provided:

Information Stored: Whether only User information or both User & Group Information is stored in the directory server. If Group information is stored in LDAP, we map these LDAP groups to Spring roles for authorization purposes.

Context Source Url: The LDAP context source Url.

Manager DN: The Fully Distinguished name of the Manager that

Manager Uid: The userid of the manager used to login to LDAP

Manager Password: The password of the manager used to login to LDAP

User Search Base: The search base to be used for user search

User Search Filter: The search filter to be used for user search.

Group Search Base: The search base to be used for group search

Group Search Filter: The search filter to be used for group search

Screen-4: Add-on Modules

In this step, we select optional add-on modules that we want to include in the generated application. In the current community version of fastCode, the following add-on modules are supported:

Document Management API

The document management API can be used by the application development team to store, lock, and version documents (ex: Pdf, Word, images). Documents can be stored in the application’s database, a file system, AWS S3 buckets, and other locations, although only the File System store is supported in the current release.

Email API

The email API can be used by the application development team to send HTML emails with embedded attachments and inline images. The embedded attachments and inline images sent with emails will be stored using the Document Management API to the storage type configured for the application.

Entity Audit

The entity audit module can be used by the application development team for production debugging. This module displays any changes to the properties of application’s entities, displaying the previous property value, the current property value, the type of change, and the change author.

Internationalization & Localization

The internationalization (I18N) and localization (L10N) module can be used by the application development team to provide their application UI in languages other than the default U.S. English. For each additional language that needs to be supported, the application development team only needs to provide the translation strings for that language in a JSON file.


The ad-hoc reporting module can be used by the application’s end-users to generate reports and dashboards on an ad-hoc basis. Initially, the application’s reporting schema has to be set up by the application development team before end-users can generate reports and dashboards.


A job is a Java method that will execute when triggered. Initially, the application development team develops jobs (Java methods) and these jobs can then be triggered by setting up trigger schedules through the Job Scheduler UI.

User Registration

The user registration module can be used to allow users to self-register to the application instead of manually being added either to the application’s database in case of database authentication or to your organization’s LDAP directory service (ex: Active Directory) in case of LDAP authentication. Note that this add-on module is not displayed and available in the case of LDAP Authentication.

NOTE: In case your application database does not have it's own User table, from this screen onwards, you can skip the rest of the screens and generate the application by clicking the Generate button. fastCode uses the defaults provided in each of the remaining screens and generates the application.

Screen - Authentication Table Mapping

If the application schema consists of a User table and you are using database authentication, you need to ensure that this table has NOT-NULL fields corresponding to the following variables:


Note-1: If your User table does not have fields corresponding to the above five fields, you need to create the missing fields in your application database User table prior to using the fastCode Application Generator. Similarly, you need to ensure that these five fields are NOT-NULL fields.

Note-2: The last field, the IsEmailConfirmed field is only necessary if you have selected the User Registration add-on module in the previous step.

We then need to map these five fields in the application database User table with the above fields.

In the case of the LDAP Authentication method, if the application has a User table, the only field that needs to be mapped from the User table is the user name which should be a NOT-NULL field. Also, all other fields in the User table, except the primary key, need to be nullable.

Screen-5: Descriptive Fields

For this step, for each entity, we need to select a field that will be used to describe the entity in the UI.

In a 1: many relationship, when creating/updating an entity on the many-side, we need to select the descriptive fields. For example, in our authorization model, we have Roles and Permissions. A Role can have one or more permissions and permission can belong to one or more Roles. Therefore, we represent this relationship in the database using a Join Table. There are 3 tables involved - Role table – RolePermission join table – Permission table. The Role table has a 1-to-many relationship with the RolePermission table. When we are creating a new RolePermission entity, we will be asked to specify a Permission and a Role. The drop-down for Permission and the Role displays the descriptive fields that are selected in this step for the Permission and Role entities.

The descriptive field is also used for navigation. For example, when we click on a specific role in the UI, it lists all the permissions that are associated with that role. In the breadcrumb of the UI, the role is displayed using the descriptive field for the Role we have selected in this step.

Screen-6: Default Sort Fields for Front-end

In this screen, we need to provide the default sort columns for each table. The default sort column will be used in the UI to display the list of records for the entity. By default, the primary key of the table is chosen as the default sort column.

Screen-7: Entity Selection for Front-end

An entity is a Java (Java persistence API) representation of a database table.

In this step, we need to select entities for which you want to generate both UI components and TypeScript services. If you don't select an entity, only TypeScript services will be generated for the entity.

If you generate UI components for an entity, the generated UI components can be used perform Create, Read, Update, and Delete (CRUD) operations on that entity. If you generate only TypeScript services for an entity, you can call these services from a custom developed UI screen for CRUID operations.

Typically, you want to generate both the UI components (and TypeScript services) for an entity if you need separate screens to perform CRUD operations on the entity. Typically, these entities will correspond to lookup database tables such as a list of countries.

As an example, if your database has 100 tables, around 20 of these tables could be look up tables. You need a way for your application users (perhaps in an admin role) to be able to update the data in these lookup table. Therefore, you would generate UI components for entities corresponding to these 20 tables.

The rest of the 80 tables don’t need CRUD screens. Instead, there could be, for example, 20 custom UI screens and each of these custom UI screens could be performing CRUD operations on more than one table simultaneously. As an example, consider a custom UI screen that has a form. Let’s assume that fields of the form correspond to fields from two different database tables. When the form is
submitted, the system needs to save the values of some fields into the first table and the values of the other remaining fields into the second table. To make this happen, you would custom develop this form, create a TypeScript service that would be called when the form is submitted, and within this
TypeScript service, call the Create TypeScript service for each of the two entities that have been pre-generated by fastCode Application generator.

Screen-8: Field Selection for Front-end

In this step, for each entity, we select the fields that we want to display (a) in the entity list grid UI screen (b) the create entity and update entity UI screens. For example, if we have a field named createDate, we may want to display this in the entity list grid UI but we don't want to include this field
in the entity creation and update UI screens as this field value is automatically populated on the back-end.

Therefore, in this step, for each entity, de-select the fields where we either don’t want to display in the entity list UI screen or don’t want to gather user input for the create/update screens.

Finally, click on the orange Generate button to generate the application. Once the application is generated, click on the "Got back Home" or the fastCode logo in the upper left corner of the screen to back to the Application Generator Portal screen.

The generated application will be displayed in the portal. In order to download the generated application, as shown below, click on the three dots that appear on the application card and select the Download Application menu item. Be patient - the application will be downloaded as a ZIP file to your local machine.