Glossary

The basic building block of Snoty.

Encapsulates one specific action, and is therefore supposed to be connected to other Nodes in order to form a Flow.

Container consisting of Nodes to model your intended behavior.

Self-contained JAR files that can provide Nodes, Hooks, Services, Adapters, etc.

Used to hook into the Snoty system at pre-defined lifecycle states. Whilst relatively scarce at the moment, the ones available already cover all things needed by the modular application design.

You can learn more about them on the Hooks page.

Snoty follows the IaC Service - Implementation pattern. Most Services can be divided into generic business logic (Impl suffix) and technology-specific implementations (<Technology> prefix).

For example, the FlowRunner is an interface implemented by only FlowRunnerImpl. On the other hand, the FlowService is implemented by both SqlFlowService & MongoFlowService - two distinct implementations that both follow the same specifications, but use two totally different backing technologies.

Bundles Service implementations using a specific Technology or Strategy. This can be as major as providing a database implementation (e.g. SQL & MongoDB Adapters), or just a singular service implementation, such as a Message Bus for the Flow Event Streaming system.

Some Adapters may share a common configuration or connection. For example, the Redis Message Bus may use the same centralized Redis connection as another Redis-backed Adapter, but you can opt to only use one of them.

Most services are mainly business logic that isn't supposed to be overwritten. Therefore, Adapters only exist for services that make sense to be replaceable in a modular way. Should you want to replace those services anyway, // TODO