Feature archetypes

Table of contents

Introduction
Choosing an archetype
- full
- light
- config
- service
See also

Introduction

Not every feature needs models, migrations and a full UI. SPLENT recognises four archetypes, and feature:create scaffolds the one you ask for. The default is full.

splent feature:create splent-io/splent_feature_mailer --type service

feature:contract infers the archetype from the source and records it in the contract. Its own models or migrations make a feature full, routes alone make it light, implemented services make it service, and anything else is config.

Choosing an archetype

Type	Use it for	Examples	Key files
full	A domain feature with its own table and UI	notes, shop	models, routes, services, repositories, hooks, templates, migrations, seeders
light	UI without tables of its own	dashboard, landing	routes, hooks, templates
config	Infrastructure that only injects configuration	cache, proxy	`config.py`
service	Backend logic without UI	mailer, indexer	services, config, commands, signals

full

It owns a table and a user-facing UI, so it needs models, migrations, routes, templates and the full test suite. Most domain features are full, such as notes with its Notes model and the screens to write them.

light

It adds routes, templates and hooks without owning tables. It may show another feature’s data, like a dashboard of what other features count, or a landing page built from the slots others fill.

config

It configures an external service. It needs only config.py, whose inject_config() puts environment variables into app.config, and may ship a compose file for the service. cache with its Redis URL is one.

service

It provides backend logic without UI, such as sending mail, processing queues or calling APIs. It has services, config, signals and commands, and no routes or templates.