Built-in services
Jadpo gives your app some common backend features itself, so you don't install a library or write your own: feature flags, rate limits, files, an audit trail, telemetry, email, documents, search and…
Jadpo gives your app some common backend features itself, so you don't
install a library or write your own: feature flags, rate limits, files,
an audit trail, telemetry, email, documents, search and bot protection.
Each is part of Jadpo's runtime and runs inside your app's process, never
as a separate container. Some reach an outside service, such as a mail
provider, through a connection you declare in app.jadpo.
How packages, connections, capabilities and services fit together
says how the pieces relate.
A feature is built in only when the compiler gains something by knowing about it: a mistake becomes a compile error, a test or a report is generated, policy or erasure reaches it, or the runtime does the work with nothing for you to write. Saving a library install isn't enough. The table lists each feature, why it is built in, and where you set it up. What is built says which of them work 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 the cache store, or Cloudflare's binding on Workers |
| Files | Yes, through the files capability |
Size and type checked; policy and erasure reach the bytes; signed links generated | File fields; a files connection in app.jadpo: the S3 driver, or the disk driver on native |
| Audit trail | Yes | The compiler sees every write and its caller; personal fields hashed | 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; Caches: drivers and what they 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 unless it names an engine |
| 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/built-in-services.md.Built from Jadpo main at a707efb.