FAQ

This FAQ covers the core Configuration concepts, reusable logic model, and when to use queries, rules, and dynamic handlers

Frequently asked questions

What is the Configuration app responsible for?

Show answer

Configuration is where you define reusable logic as managed records.

Instead of hardcoding behavior into services, you store queries, rules, and dynamic handlers so runners and sagas can load them at runtime.

See Overview.

What kinds of logic belong in Configuration?

Show answer

Configuration is best for logic that should stay editable, reusable, and portable.

The main categories are:

• Queries for data retrieval and filtering

• Business Rules for decision logic and policy evaluation

• Dynamic Handlers for specialized runtime logic that extends built-in handlers

See Overview.

How is Configuration different from Devops?

Show answer

Configuration stores reusable runtime logic.

Devops defines the services, flows, runners, and deployments that execute that logic.

A simple mental model is:

• Configuration defines what reusable logic exists

• Devops decides where and how that logic runs

See Devops FAQ.

Why keep logic in Configuration instead of hardcoding it?

Show answer

Because it makes behavior easier to change, review, and migrate.

It also reduces redeploys for common logic changes and keeps reusable definitions in one place instead of spreading them across services.

What is a query in Rierino?

Show answer

A query is a stored, parameterized definition for reading data from a target platform.

It is usually executed by a query manager or invoked from a handler or saga step.

Queries are useful when you want reusable listing, filtering, search, or reporting logic without embedding platform-specific syntax everywhere.

See Queries.

When should I use a query instead of a state manager read?

Show answer

Use a state manager read for direct record access.

Use a query when you need custom filtering, search, pagination, joins, aggregations, or platform-specific read behavior.

Queries are especially useful for list endpoints and read-heavy screens.

Are queries tied to one database technology?

Show answer

No.

Queries are designed as standardized definitions that target a specific platform at execution time.

That makes them easier to manage and migrate than scattering raw query syntax across services.

See Query Platforms.

What are business rules in Configuration?

Show answer

Business rules are stored decision definitions.

They let you manage conditions and actions as data, so rule behavior can evolve without rewriting service code for every policy change.

Rules are usually grouped into domains and executed together.

See Business Rules.

What is a rule domain?

Show answer

A rule domain is a grouped ruleset.

It defines a logical area where related rules, shared functions, and execution settings live together.

Examples could include pricing rules, validation policies, or promotion logic.

When should I use business rules instead of a saga?

Show answer

Use a saga for orchestration.

Use business rules for decision evaluation.

If you need step flow, routing, retries, or cross-service coordination, use a saga. If you need policy logic such as qualification, scoring, matching, or action selection, rules are often the better fit.

What is a dynamic handler?

Show answer

A dynamic handler is runtime-loaded custom logic.

It lets you add or customize handler behavior without going through the normal service build path for every change.

This is useful when built-in handlers are close, but not enough for the use case.

See Dynamic Handlers.

What is the difference between handler codes and handler packages?

Show answer

Handler codes are runtime-loaded code blocks.

Handler packages are runtime-loaded JAR packages containing handler implementations.

Use codes for smaller or more direct extensions. Use packages when you need bundled classes, dependencies, or a more structured custom extension.

When should I use a dynamic handler instead of a built-in handler?

Show answer

Use a built-in handler first whenever it fits.

Use a dynamic handler when the use case is too specialized for the standard handler set, but you still want the logic managed as a runtime asset instead of packaging it into a normal service release.

What is the relationship between Configuration and runtime safety?

Show answer

Configuration defines the reusable logic.

Runners and handlers still control what systems, states, and operations are allowed at execution time.

That separation helps teams iterate faster without giving every configuration record unlimited runtime access.

Can Configuration changes be reused across multiple services?

Show answer

Yes.

That is one of the main reasons to keep logic here.

A stored query, ruleset, or dynamic handler can be used by multiple runners, flows, or screens instead of being duplicated in each service.

How does Configuration relate to Design?

Show answer

Configuration often provides the reusable logic behind screens.

For example, a Design source may call an endpoint that runs a stored query, or a UI workflow may depend on rule evaluation defined here.

Design handles the screen. Configuration helps supply the runtime logic behind it.

See Design FAQ.

What should I understand first if I am new to Configuration?

Show answer

Start with these concepts:

• Query for reusable data retrieval

• Rule domain for grouped decision logic

• Dynamic handler for specialized runtime extension

• Runtime reuse as the main reason this app exists

Once these are clear, the rest of the section becomes much easier to navigate.

Where should I go next for deeper Configuration FAQs?

Show answer

Start with the subsection that matches your goal:

• Need data retrieval logic → Queries

• Need policy or decision logic → Business Rules

• Need runtime custom extensions → Dynamic Handlers

Subsection-specific FAQs can then go deeper into query types, platforms, rule patterns, and custom handler strategies.