Last updated: 2024-06-24
Advanced settings - backgrounds
The Advanced settings section is available in the General tab when a project or account has been upgraded to the Professional plan. In addition, further functionalities such as the Controllers tab and the Security tab are unlocked.
Advanced settings available in the Professional plan
Test setup
Using the Test setup option, high-level integration tests can be enabled for all REST controllers in the project. This will result in the following changes in the source code in addition to the required setup:
BaseITclass for centralized initialization of the tests- a test class with the
contextLoads()method to ensure that the application context starts correctly - one test class per REST controller in the project
Depending on the selected database, Testcontainers will also be used in the BaseIT class to launch an image with the actual database during testing. In order for this to work, Docker must be available in the current environment. Using the abstract class BaseIT ensures that the containers are reused between tests.
Tests are generated for both custom and generated controllers. This includes a direct test of the endpoint expecting a valid response (e.g. updateOrder_success). If feasible, test cases are also added for validating correct responses when a field or entity is missing. If security has been enabled for the project, valid credentials are automatically provided via the BaseIT class. Also a test is added ensuring that invalid credentials will result in an UNAUTHORIZED response code.
The test data for testing the CRUD endpoints is loaded using SQL scripts. However if MongoDB is selected, the documents are loaded via source code instead. For this purpose, a class TestData provides methods to clear all documents (clearAll) and to create test documents (one method per entity).
More background on the testing approach can be found in this article.
Multi-module option
If the multi-module option is activated, the project is initialized with a base and a web module. For this the build file is extended (Gradle) or divided (Maven). The base module contains most of the code, while the web module primarily serves a wrapping function: the final executable jar is created from this module and contains all other modules and libraries.
Generated project with multiple options
If the multi-module option is active, any number of custom modules can be added. These initially contain a single class as a placeholder, but are already integrated into the build: they reference the base module using api project(':car-parts-base') and are themselves referenced by the web module, so they will be contained in the final jar. After the download, the modules can be filled further and the dependencies between them can be adjusted.
Check out the best practices for multi-module projects for more explainations.
Custom controllers
A custom REST interface can be created in the Controllers tab - a walkthrough is available here. With this the API of the new application can be reviewed in the team and is available together with the tests in the generated code.
A preview of the current OpenAPI schema is available in the Controllers tab as well. It shows the specification as a JSON and can be reviewed in an online Swagger client as well.
Open API Preview in the Controllers tab
After a frontend has been selected in the General tab, custom frontend controllers can be added as well. They allow to define the future pages (input type GET) and forms (Data Object as input type). The defined paths can be selected at your Security Configs. More details are explained in the frontend settings.
Further features
One of the options for Spring Session can be used if you plan to scale your application. With the Database option, either spring-session-jdbc or spring-session-data-mongodb is used depending on your selected database. The required schema is automatically created during application startup. If you select Redis or Hazelcast, the docker image is added to your docker compose file and the BaseIT class if the respective options are used. Don't forget that the cookie name changes from "JSESSIONID" to "SESSION" if you're using Spring Session.
The option for Actuator adds the spring-boot-starter-actuator dependency. The selected endpoints are exposed - if no endpoint is specified, all endpoints are included with the management.endpoints.web.exposure.include=* property. Please include critical actuator endpoints in a Security Config so they are not publicly accessible.
When enabling the option for HATEOAS, spring-boot-starter-hateoas is added to the project. All REST controllers will return a proper RepresentationModel, including the links, using an implementation of the SimpleRepresentationModelAssembler when added with the CRUD option. Integration tests are adjusted for the the new response format as well.
When MapStruct is activated, the necessary setup is provided and the mappers are generated for entities with the REST or frontend option enabled. More background on MapStruct is available in this article.
Pagination is available for generated as well as custom controllers. When the REST or frontend CRUD option is enabled for an entity, the additional option is visible right below in the Bootify Builder. For custom endpoints, Page can be selected directly as a response type. Backgrounds on the implementation are available here.
A Search Filter option can be activated at entities as well. It will add a new filter parameter which will be matched against the primary key. Extend your repository after the download to take more fields into consideration.
In the Security tab Spring Security can be configured. The backgrounds to this feature are explained on this page.
See Pricing
or read quickstart
