Services, Web Apps, and APIs
Why This Is the Leap From Toy to Tool
A project becomes much more useful when you can interact with it from another device, expose a dashboard, or let other services consume its data.
Common Software Shapes on Raspberry Pi
| Shape | Best for |
|---|---|
| Background service | Sensor loops, automation, scheduled jobs |
| REST API | Integrating with apps, dashboards, mobile tools |
| Web dashboard | Human-friendly controls and status |
| Kiosk app | Dedicated local display |
| Message-driven worker | MQTT, queues, home automation events |
Simple API Pattern
A Raspberry Pi API often has these responsibilities:
- read from sensors or devices
- expose current state
- accept safe commands
- log events for diagnosis
Example stack:
GPIO/Sensors -> Python service -> SQLite/PostgreSQL(optional) -> FastAPI -> browser or automation client
Dashboard Ideas That Work Well
- greenhouse or room conditions dashboard
- local network status board
- personal productivity wall display
- workshop machine status panel
- camera timeline or timelapse controller
Kiosk Mode Pattern
Pi is excellent for dedicated single-purpose screens.
Typical setup:
- boot to desktop or lightweight window manager
- auto-launch Chromium in kiosk mode
- load your local dashboard URL
- hide distractions and auto-recover on reboot
Example launch command:
chromium-browser --kiosk --app=http://localhost:8000
Reverse Proxy and Static Assets
For more serious setups, put a reverse proxy in front of your app.
| Tool | Why use it |
|---|---|
| Nginx | static files, TLS termination, reverse proxy |
| Caddy | simple automatic HTTPS in many setups |
| Traefik | useful when you have multiple containers |
Example Service Split
camera-node/
├── collector/ # talks to hardware
├── api/ # exposes status and commands
├── dashboard/ # static UI or SPA
└── systemd/ # units for production
This split keeps hardware logic from leaking everywhere.
SQLite Is Often Enough
For a lot of Pi projects, SQLite is the right database.
Use it when you want:
- event history
- sensor readings
- a simple queue
- configuration storage
Choose a heavier database only when there is a clear need.
Example Endpoints Worth Building
| Endpoint | Purpose |
|---|---|
GET /health | Is the service alive? |
GET /metrics | Current readings or counters |
GET /events | Recent history |
POST /actions/fan/on | Controlled state change |
POST /actions/capture | Trigger camera or recording |
Message-Driven Systems
MQTT is a natural fit if you have many small devices or home automation.
Good uses:
- sensor event distribution
- command fan-out
- bridging Pi apps into Home Assistant or Node-RED
- decoupling UI from collectors
Example Mini-Architecture
sensor-reader -> MQTT publish -> dashboard subscriber -> alert worker -> notification service
Next Step
Move to 07-containers-automation-and-remote-management.md when you want better deployment habits and easier multi-service setups.