General Search Interface

[rekt-hard]

Description
A streamlined approach for the search process, possibilities and configurations.
Possibility to pass possible config and filters to the front end for re-usability. Based on the config, the front end can build a UI with filter options and sort options. This will allow to have a common front end component for each search - reducing UI logic and code duplication.

Outcome of such an approach will provide the following benefits:

• De-duplication of logic
• Base shared logic (one place for common implementation. Changes here will be available everywhere)
• Easier integration for current implementations
• Easier integration for additional implementations
• Modular and re-usable components
• Single source of truth for configuration
• Convey configuration to front end and build UI based on this configuration

Proposed solution

Possible Architecture

In essence, a first possible architecture approach is to set it up as follows.

Layers

Resource Layer

Actions:

• Receive request
• Perform basic validation based on the specified attributes (query, path and body parameters - already done by quarkus)
• Pass everything to the service
• Get result from the service layer
• Return results and requests

Service Layer

Actions:

• Receive parameters and id (only for read) (i.e. search(parameters), read(id, parameters))
• Create a search from passed parameters
  • Pagination
  • Filter provided parameters (ignore pagination specific)
    • Allow list of parameters (for request search)
    • Deny list of parameters (for request search)
    • Could be extended to parameter permissions based on user or role (future work)
  • Set default values for not specified parameters
  • Validate sort option (set to default if invalid or not provided)
• Pass search to data layer
• Get result from data layer
• Update Pagination based on query result
  • Set total number of items, hasNext, hasPrevious
• Could filter certain fields based on permissions (future work)
• Return result

Data Layer

Actions:

• Create query based on filters
  • Combine separate parameter values with AND logic (language = "en" AND active = True)
  • Combine same parameters values with OR logic (language = "en" OR language = "de")
• Set off database query:
  • Set query
  • Set pagination
• Return result

Configurations

For this, additional configs have to be in place.

Service

• Parameter config
  • Filters
    • Allow (for request)
    • Deny (for request)
    • Default values
• Sort config
  • Possible sort options
  • Default sort

Relevant issues/PRs

First implementation #246

• Data Layer
  • Create query based on filters
  • Set off database query

Alternative solution
Hard code possible search methods and options per service (duplication of code and logic)