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 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, 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 / Angular Material.
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 generated JPA entities generated, 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.
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:
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 /GitLab account. In order to allow the application generator to generate the application in a private repository your Git account, you must authorize it to access your Git account.
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.
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
In this step, we select optional add-on modules that we want to include in the generated application.
In the free 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.
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.
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.
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.
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.
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 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.
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.
In this screen, we select a code generation option for each entity. The back-end data access layer is generated for all entities because you require it for performing CRUD operations on the database tables in your data model.
Beyond the data access layer, for the lookup tables in your data model that contain pre-defined data that doesn't change often and doesn't change based on user interactions with the application, you may also want to generate the application (business logic) / ReST API layer and the front-end UI screens so that you can perform CRUD operations on the lookup tables in your data model.
For the transactional tables that may need to be updated based on the user interactions with the application, you may need to develop custom UI screens which then call custom ReST API methods which in turn call the custom business logic methods in the application layer. Therefore, you may not want to generate the application/ReST Controller methods and CRUD screens for these tables.
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.
This screen is also used to select the field used to sort the entity list.
Finally, click on the orange Generate button to generate the application. Once the application is generated, click on the "Go 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.
Alternatively, the application is generated into the directory that is listed on the last screen once the application generation is completed or if you have specified a Git account, a new repository is created in the Git account and the code is checked-in to this repository.
Updated over 1 year ago