List - Best Practices

Be aware of size of data to be loaded into List

Description:

Joget does not restrict the amount of data that can be loaded into the List, regardless if data is loaded via form data, custom DB query, JSON API, etc.

Although Joget has mechanisms to perform pagination for data loaded via form data, it is out of Joget's control for loading via custom query or external resources.

For example, if you have a JSON API that does not have pagination support from the external service, Joget is forced to load the entire JSON response payload before 'truncating' to the selected page size.
This may add significant processing overhead to what seemingly is only displaying 10 rows of data on page 1 out of 1000.

Solution: 

• If it is necessary to display lots of rows, it may not be necessary to load all data all in one go.
  Do consider Lazy Load mechanisms, such as the Lazy Load Datalist Template.
• Pay attention to performance of custom query or external resources. Optimize if able to. Use paging mechanism if available.
• Consider the business requirements.
  More than often, it is not logical for end users to want to see 10000 rows of data all in one go. In such cases, end users will use List Filters to narrow the search results in order to find the exact record(s) to interact with.
  The best solution is to simply enable Only Show Data When Filters Are Submitted? option under List Settings.
  Also, ensure that there are sufficient list filters available to end users to allow precise searching.

Optimize custom queries used to load List data

Description:

In most cases, list data is populated by forms that you've created in Joget. Joget automatically curates the query behind the scenes to retrieve data.
But in typical reporting use cases, custom queries are often used to perform necessary value manipulations, aggregation, case expressions, and many more.

When using custom queries, the app developer is in full control of the data retrieval, and must ensure such queries have been optimized to the best extent possible in order to prevent performance bottlenecks on Joget and its datasource.

Solution: 

• Ensure you have evaluated your custom query's performance. Ideally, test it against a larger dataset in order to test for performance.
• Example for MySQL, you can utilize the MySQL Workbench in order to evaluate query processing time and processing breakdown.
• Alternatively for MySQL, run EXPLAIN ANALYZE to understand the time/complexity of the custom query. This will provide info on which portion of the query requires optimization.

Pay attention to quality of external resources

Description:

Anywhere in the List that uses external resources to load data (e.g.: JSON API), do keep in mind the reliability of such resources.

External integrations, such as querying external databases or making JSON API calls within a list, are common sources of performance and stability issues. Since these external resources are outside of Joget's control, the Joget server relies on the external service to return responses reliably on-time and with expected data format.

Solution: 

• For any external DB queries or JSON APIs used, do be aware of performance of external resources.
  Unreliable performance will impact List loading times, and subsequently forces end users to wait for List to load finish.

Optimize any custom logic used in list formatter

Description:

List formatters are executed on a per-row basis.
The current built-in formatters are already optimized by the Joget team.

However, when using custom logic like bean shell script or even your own custom list formatter plugin, do take into account of the per-row processing behaviour.

If the custom logic involves complex processing or depends on external resources, do ensure logic is well optimized.
Otherwise, performance issues may arise as end users are populating data into the Joget platform over time, as this will increase the number of iterations of formatter logic executions.

Solution: 

• For complex bean shell logic, do consider converting into its own dedicated plugin. This eliminates bean shell real-time compilation overheads, allows developers to debug via IDE, and many more benefits.
• If logic contains custom query or API calls, do consider caching mechanisms where possible to reduce redundant executions.

Don't put too many columns in a List

Description:

Too many columns in a list can affect end user readability.
Wide lists also forces the list to overflow horizontally, which requires the end user to scroll the web page in a horizontal direction, rather than the typical vertical direction via mouse scroll wheel or mousepad gesture.

In severe cases (e.g.: 50 columns), it may even cause end user browser performance to degrade due to the large rendering time needed.

Solution: 

• For rows with large amount of columns, do consider other list templates that specialize in vertical spaces (e.g.: card view).
• Is it necessary for all columns to be visible at all times? If it is not required to be visible but still has functional purposes to be present within the browser DOM, consider setting the column type as "Hidden" instead.

Remove unnecessary list permissions

Description:

Although permission control can be applied in many different components of a Joget app, it is not necessary to apply again in a duplicate manner.

For example, if the related UI is already configured for Logged In Users only, it is not needed to reapply this same permission on the list layer, as this adds unnecessary processing overhead & is prone to configuration error.

Solution: 

• If the "outer layers" already have adequate permissions, it is not required to add permissions to the list layer. Remove redundant permission rules.
• Apply permission rules conservatively. Only if the UI is unable to granularly control permission to your requirement, only then apply permission rules on the list layer.