Feature archetypes

Not every feature needs models, migrations, and a full UI. SPLENT recognizes four archetypes.

Table of contents

Overview
full
light
config
service
See also

Overview

Type	Purpose	Examples	Key files
full	Domain features with CRUD, UI, and database	auth, notes, reset	models, routes, services, repositories, hooks, signals, commands, seeders, templates, assets, migrations
light	UI features without their own database tables	profile, notes_tags	routes, hooks, templates
config	Infrastructure that only injects configuration	redis, session_redis, mailhog, nginx	config.py only
service	Backend services without UI	mail, confirmemail	services, config, commands, signals

Use feature:create --type <type> to scaffold. Default is full.

full

Your feature owns a database table and has a user-facing UI. It needs models, migrations, routes, templates, and the full test suite. This is the most common type for domain features.

Real examples: splent_feature_auth (login, signup, user model), splent_feature_notes (CRUD for notes with tags).

light

Your feature adds UI (routes, templates, hooks) but doesn’t own database tables. It might extend another feature’s UI or provide view-only pages.

Real examples: splent_feature_profile (edit profile form, reads from auth’s User model), splent_feature_notes_tags (adds tags column to Notes via mixin).

config

Your feature configures an external service. It only needs config.py with inject_config() to push env vars into app.config. May include a docker-compose.yml for the service.

Real examples: splent_feature_redis (Redis connection URL), splent_feature_nginx (reverse proxy), splent_feature_mailhog (SMTP trap).

service

Your feature provides backend logic without a user interface. Think email sending, queue processing, API integrations. It has services, config, signals, and CLI commands. No routes or templates.

Real examples: splent_feature_mail (SMTP sending), splent_feature_confirmemail (email verification tokens).