Glossary
The vocabulary used across the Webda framework. These terms appear throughout the documentation, the configuration schema, and the code itself.
Application
The compile-time view of a Webda project — the inventory of every Service, Modda, Model, deployer, and configuration file the framework discovers in your repo. The Application object is built by @webda/compiler (webdac build) and serialized to webda.module.json. At runtime, Core reads it to know what to instantiate. See Concepts/Application.
Core
The runtime engine. Owns the dependency-injection graph, the service lifecycle, the router, and the event bus. There is exactly one Core instance per process. It boots from an Application and a webda.config.json, instantiates services, calls resolve() then init() on each, and serves requests. See Modules/core/Architecture.
Bean
A class that should be auto-instantiated by Core and registered as a service, without an explicit entry in webda.config.json. Marked with the @Bean decorator. Beans are discovered by the compiler at build time and listed in webda.module.json under beans. Use a Bean for a singleton that doesn't need user-facing configuration; use a Service when configuration matters.
Deployment
A named overlay applied on top of the base webda.config.json to specialize the application for an environment. Deployments live under deployments/<name>.json and can override service types, parameters, and parameters blocks. They also describe how the app is shipped (Lambda, CloudFormation, Kubernetes, Docker). Activated with webda -d <name> serve|deploy. See Concepts/Deployments.
Configuration
The merged result of: the base webda.config.json, an optional deployment overlay, environment variables, and parameters defaults — resolved in that order. Drives which services exist, with what parameters, exposing what routes.
Static
Configuration baked into the application at build time: webda.config.json, deployment files, and the schemas generated by webdac build. Static configuration is what Core sees when it starts and is reflected in webda.module.json.
Dynamic
Configuration provided at runtime: environment variables (substituted via ${ENV_VAR} placeholders), values fetched from a secrets manager during init(), or parameters that change between requests via WebContext. Dynamic configuration is not part of the build artifacts.
Service
The base abstraction for a runtime component. Subclasses Service<P extends ServiceParameters>. Owns its parameters, exposes routes via @Route / auto-generated CRUD, emits events, and follows the lifecycle constructor → resolve() (sync) → init() (async) → running → stop() (async). Wired into the application by an entry in webda.config.json services. See Modules/core/Services.
Modda
The type of a Service — the metadata that describes one class so the framework and configuration UI can present it. A Modda has a unique id (e.g. Webda/MemoryStore), a label, a description, a default-parameter block, and a JSON schema. Moddas are discovered by the compiler and listed in webda.module.json under moddas. When you write "type": "MemoryStore" in webda.config.json, you're naming the Modda; the framework instantiates the matching Service class.
Model
A domain entity (a User, an Order, a Post). Subclasses CoreModel and is annotated with @Model. Models declare their fields, relations (@ModelRelated), validation, exposure rules (@Expose), and custom actions (@Action). The framework derives REST routes, GraphQL schema, gRPC services, and store mappings from the Model definition. See Modules/models/Defining-Models.
Behavior
A class — marked with @Behavior() — used as the type of a property on a Model. It groups together a set of @Action methods plus optional inline state that round-trips with the parent model on save and load. Each Behavior action is exposed as an Operation <Model>.<Attribute>.<Action> (REST: /<plural>/{uuid}/<attribute>.<action>). Authorisation is decided by the parent model's canAct(ctx, "<attribute>.<action>"). Use a Behavior for reusable, namespaced sets of methods plus a small chunk of state — MFA, audit summary, lock metadata, etc. See Concepts/Models/Behaviors.
Operation
A unit of business logic exposed via the framework's protocol layer — commonly an @Action on a Model, an @Action on a Behavior attached to a Model, or an @Operation method on a Bean. Operations are auto-mapped to REST endpoints, GraphQL mutations, and gRPC methods. The runtime tracks every operation in a registry so the same logic answers across protocols. See Concepts/Operations.
ModelDefinition
The compile-time descriptor of a Model class — the schema, the relation graph, the primary key shape (single or composite), the exposure rules, and the list of @Actions. Generated by webdac build and stored in webda.module.json under models. The runtime reads ModelDefinition to wire stores, generate routes, and emit GraphQL types.
ModelMetadata
The runtime-attached metadata on every model instance: its uuid, owner, creation/update timestamps, dirty-tracking state, and any custom @Metadata fields. Distinct from ModelDefinition (which describes the class). Accessed via model.getMetadata() or specific helpers like model.isDirty().