How Bluetext makes following best practices easy
Following a best practice means declaring it, not building it. Giving a second consumer its own credential is a profile and a bundle — a few lines, rather than a pipeline nobody has time for. Putting a browser's session behind a token handler is a component and two routes, rather than a project of its own. That is the difference that decides whether a practice actually gets followed: teams do not skip these things because they disagree with them, but because each one costs more than the deadline allows.
A practice followed once is followed everywhere. The same declaration renders into development, staging and production, so the practice does not have to be re-established per environment — and the environments cannot quietly disagree about it, because there is only one statement of it to read.
And some practices arrive already implemented. The curated technology set is part of this: nobody writes the token exchange, nobody builds session introspection, nobody implements cross-datacenter replication. A best practice supplied by a product is one nobody on the team has to get right.
Some of what that covers, by the requirement it serves.
Cross-cutting
| Best practice | What it costs to follow in Bluetext |
|---|---|
| Everything in version control, nothing in a console | Nothing — the declaration is the configuration, so there is no console state to drift |
| Configuration separated from code | Declaring the values that differ between environments, once |
| No fact stated twice | Nothing — an address or a credential is declared once and projected wherever it is needed |
| An enumeration of everything that is running | Nothing — every artifact a deploy creates is recorded as owned by it, so what is running is a list to read rather than an estate to survey (§9) |
Compliance
| Best practice | What it costs to follow in Bluetext |
|---|---|
| Knowing which data the system owns | Declaring the fields that hold it |
| Knowing where each part runs, and in which region | Declaring the target |
| Every consumer and credential accounted for | Nothing beyond declaring the connection — the list is the declaration |
| Evidence produced on demand rather than assembled | Nothing — the inventory is the declaration, so an audit reads it instead of beginning with discovery |
| Every control change visible as a diff | Nothing — who may reach what, which credential each connection presents and what is published are all declarations |
| Data-flow evidence read rather than reconstructed | Nothing — every operation names the service it reaches by where it sits in the code |
Security
| Best practice | What it costs to follow in Bluetext |
|---|---|
| Least privilege between components | A profile and a credential bundle, plus the role you would have created anyway |
| Secrets held in a vault, never in the system | Declaring the bundle — the declaration references the material and never contains it, so nothing lands in source or in an image |
| Secrets delivered to a process as files | Nothing — material is written into the pod at deploy time and read by path, never through the environment |
| Rotation without redeployment | Nothing — material is replaced rather than baked into an artifact |
| One public entry point | Declaring the gateway's routes; a component is fronted or published, never both |
| No tokens in the browser | A component and two routes — the token handler itself is Curity's |
| One decision point for permission | Writing the gate; a check for that operation has nowhere else to go |
Reliability
| Best practice | What it costs to follow in Bluetext |
|---|---|
| Development that matches production, without slowing the inner loop | One flag on a deploy config — the workload stands in the cluster while the source and the build cache stay on the machine |
| Explicit error contracts | Naming the errors an operation may return, which every generated client then has to handle |
| Typed clients generated from the contract | Declaring the endpoints; a client per declared language follows |
| Setup that converges before its consumers start | Declaring it as configuration the product takes through its own API |
| The whole system deploys as one ordered operation | One command — the parts converge in dependency order, so there is no runbook to keep current and no step to run out of sequence |
| Immutable, reproducible deploys | Nothing — images resolve by content digest and the deployment objects render from the declaration |
| Data replicated across data centres | Enabling it on the store; the curated database provides replication rather than you building it |
| Backup and restore of application data | Configuring a schedule; the tooling comes with the store |
| The application survives a data node restarting | Nothing — data is spread across virtual buckets and the client library follows the topology, so a restart is not something application code handles |
Maintainability
| Best practice | What it costs to follow in Bluetext |
|---|---|
| Business logic in one layer | Nothing — controllers carry no decisions and drivers carry no logic, and the compiler keeps it that way |
| Least privilege inside the codebase | Nothing — a part reaches only what it holds |
| Change fan-out mechanical rather than manual | Nothing — change a contract and every caller is regenerated from it |
| A change whose blast radius is derivable | Nothing — what a change reaches follows from the declaration, so the answer is computed rather than remembered |
| Knowing which service a piece of code writes to | Nothing — every operation carries its component and its link by where it sits, so the answer is read rather than traced |
| Refactoring across components without a sweep | Nothing — a contract change re-renders the clients that depend on it, in every language declared for them |
Scalability
| Best practice | What it costs to follow in Bluetext |
|---|---|
| Deployment topology declared, not coded | Declaring a target |
| One store rather than several | Nothing — the curated technology set brought it |
| Scaling the data layer without a runbook | A setting on the store component |
Performance
| Best practice | What it costs to follow in Bluetext |
|---|---|
| A runtime with a low cost per request | Nothing — the workloads are Rust, so memory and CPU per request are low and there is no collector pausing them |
| Hot data served from memory | Nothing — the store is memory-first, so there is no cache tier in front of it to invalidate and no staleness to reason about |
| Static content served off the application path | Declaring the page a web-assets component |
Flexibility
| Best practice | What it costs to follow in Bluetext |
|---|---|
| Cloud provider independence | Nothing in the system changes — the deployment objects are provider-independent, so another cloud is another target (the cluster itself still needs preparing, §9) |
| The same system on-premises or in a cloud | Nothing — a cluster is a cluster; where a managed service was chosen over a self-hosted one, that choice is a variant and reversible |
| Depending on a contract rather than an implementation | Declaring the interface; the client is generated from it |
| Keeping a vendor choice reversible | A second variant |
| No provider assumptions in application code | Nothing — addresses and credentials arrive by projection |
Cost-effectiveness
| Best practice | What it costs to follow in Bluetext |
|---|---|
| Non-production sized differently from production | A variant per environment |
| Paying only for what cannot be generated | Nothing — the technology selection already made that trade |
Development velocity
| Best practice | What it costs to follow in Bluetext |
|---|---|
| No local installs to develop against the real stack | Nothing — every component runs as a container in a local cluster, so no database, gateway or identity server is installed on the machine |
| A working system from a clone | A clone and one deploy command brings the whole stack up, so a new developer is productive the same day |
| No hand-written integration code | Declaring the contract |