What isn't built in
Some features other frameworks offer aren't part of Jadpo, because the compiler gains little by knowing about them. You build them from your app's own data and packages, or they come later:
| Feature | Why not, or not yet |
|---|---|
| Realtime subscriptions | Policy on a live stream of changes is a large design, so it comes later. Until then, clients poll with the revision header (Write revisions) |
| Generated admin screens | Jadpo makes backends, not interfaces. Operators use jadpo commands (The jadpo command); a screen can come later on the same operations |
| Payments | Money moves at the provider, so an integration plus webhooks (External services) is the right shape, and the compiler gains nothing more |
| Content management | Content is application data |
| Product analytics | Events and metrics above feed whichever tool a team uses |
| Quotas and plan limits | A plan's limits are application data, checked by an action; counting uses counters |
| Background job dashboards | Already the operator commands (Commands for background work) |
Why each service is built in
This is why each is here and where you set it up. Built-in services says how much of each works today.
| Feature | Native? | Why | Where it lives |
|---|---|---|---|
| Feature flags | Yes | Misspelt flags are errors; both branches tested; expired flags reported; one-step removal | Root flags.jadpo; read as flags.name; state in the app's database, not a capability |
| Rate limits | Yes | The route knows the caller; 429 is already a failure kind; limits appear in OpenAPI | rate_limit: on an API or route; counted in each server's memory, or Cloudflare's binding on Workers |
| Files | Yes, through the files capability |
Size and type checked; policy and erasure reach the bytes | File fields; a files connection in app.jadpo: the disk driver, on native |
| Audit trail | Yes | The compiler sees every write and its caller | audit: section on an entity; AuditEntryRecorded when something listens |
| Telemetry | Yes, with one settings section | Every route, query, action, job and provider call is known | telemetry: in application { }; custom metrics in a domain's monitoring.jadpo |
| Path IDs and monitoring thresholds | Yes | Every path is known, so it can be named, sampled and given limits | Generated runtime; a monitoring file per domain |
| Caches | Yes (Caches) | What may be cached, and what never is, is the language's | Redis-compatible connections; Cache drivers and what a cache may hold |
Yes, through the email capability |
Templates typed against translations; delivered after commit; any provider without code changes | type X = EmailMessage in emails/; an email connection in app.jadpo |
|
| Documents | Yes, through the documents capability |
Templates typed and translated as email's; rendered in subscribers | type X = Document in documents/; a documents: connection in app.jadpo |
| Search | Yes, through the search capability |
Index, query and migration generated from one declaration; results always pass policy | search: section on an entity; PostgreSQL |
| Bot protection | Yes, through the bot_check capability |
Jadpo's own public endpoints need it; the token never enters a route's input | bot_check: in application { }, bot_check: true on a route or feature |
| Outgoing webhooks | Yes | Payloads typed from events; signing and retries generated; one guarded network exception | Later, through publishing |
| Field encryption | Yes | Encrypted fields kept out of logs, indexes and filters | Encrypted fields |
| Realtime, admin screens, payments, CMS, analytics, quotas, media transformations | No, or later | The compiler gains little, or the feature is not a backend's | Not built in; media services (Cloudinary, Uploadcare) are ordinary packages |
Markdown for agents: /docs/not-built-in.md.Built from Jadpo main at aee2e8f.