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 include splent_feature_auth (login, signup, user model) and 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 include splent_feature_profile (edit profile form, reads from auth’s User model) and 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 include splent_feature_redis (Redis connection URL), splent_feature_nginx (reverse proxy), and 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 include splent_feature_mail (SMTP sending) and splent_feature_confirmemail (email verification tokens).