DEV Community: Mr. Stone

Stone.js: your app exists in every runtime, until you run it

Mr. Stone — Wed, 22 Jul 2026 22:59:17 +0000

The rewrite tax

Count the versions of your last real-world app. There is the Express or Nest version for the server. The handler you extracted and mangled for Lambda. The API routes you re-declared when the frontend moved to Next. And now someone is asking for an MCP server so agents can use it.

Same domain logic. Four incarnations. Every framework you picked made you pay this tax, because every framework has a home runtime and your code belongs to it.

Stone.js starts from the opposite premise: an application is not an object, it is an act. Application = Domain x Context. You write the domain once; the context (server, function, browser, agent) applies itself to your domain at runtime, not the other way around.

Show me

A domain is just classes or functions. No base class, no framework import in your business logic:

import { Service } from '@stone-js/core'
import { IncomingHttpEvent } from '@stone-js/http-core'
import { Get, Post, EventHandler } from '@stone-js/router'

@Service({ alias: 'tasks' })
export class TaskService {
  private readonly items: Task[] = []

  list (): Task[] { return this.items }
  add (title: string): Task { /* ... */ }
}

@EventHandler('/tasks')
export class TaskController {
  private readonly tasks: TaskService
  constructor ({ tasks }: { tasks: TaskService }) { this.tasks = tasks }

  @Get('/')
  list (event: IncomingHttpEvent): Task[] {
    return this.tasks.list()
  }
}

Where does it run? That is not the domain's problem. It is declared once, at the edge of the app:

@NodeHttp()       // a Node HTTP server
@AwsLambdaHttp() // an API Gateway handler
@Routing()
@StoneApp({ name: 'tasks' })
export class Application {}

Each decorator is an adapter: it captures the platform's raw event (an IncomingMessage, a Lambda payload), normalizes it into one IncomingEvent, and turns your response back into whatever the platform expects. Your controller never learns which one ran. stone run collapses the superposition into the target you deploy.

Adapters today: Node HTTP, AWS Lambda, Azure Functions, GCP Cloud Functions, Tencent SCF, Alibaba FC, edge/fetch runtimes, browser, CLI, WebSockets. One domain, any of them.

Allergic to decorators? Same parity, no decorators

Every single feature exists in two first-class forms, decorators or plain functions. Not a fallback, a parity contract:

import { defineEventHandler, defineRoutes } from '@stone-js/router'

const TaskController = ({ tasks }) => ({
  list: (event) => tasks.list()
})

export const routes = defineRoutes([
  [defineEventHandler(TaskController, 'list'), { path: '/tasks', method: 'GET' }]
])

The decorators are TC39 2023-11 stage 3 (Symbol.metadata), not experimentalDecorators, and there is no reflect-metadata anywhere. ESM only.

Your domain, observable by machines

Your app can expose itself to AI agents. In development, stone mcp starts an MCP server that lets your coding agent introspect the app it is working on (routes, services, blueprint, framework knowledge). And the same adapter mechanism that serves HTTP can serve your domain to agents as tools. The fourth rewrite is the one you skip.

Is it real?

Numbers you can verify, not adjectives:

40+ packages under @stone-js/* (MIT), a micro-kernel that depends on exactly 3 of them
99% test coverage, enforced per package; public quality gate on SonarCloud
Zero known dependency vulnerabilities
118 documentation pages, a generated API reference, 14 starters
The docs site is itself a Stone.js app (SSG mode), dogfooding included

What beta means here

The API is settled enough that I document both paradigms for everything, and unstable enough that your feedback can still bend it. That is exactly the window where trying a framework is the most fun.

I am looking for a dozen pilots: developers, architects, QA. Build something small, break it, tell me everything that hurts. You get direct access to me and founding-tester credit.

Start here: https://stonejs.dev
Docs: https://stonejs.dev/docs
GitHub: https://github.com/stone-foundation/stone-js-framework
Feedback: GitHub Discussions

Your app exists in every runtime. Until you run it.

Happy Entanglement. 😎

Cloud-native or cloud-naive ?

Mr. Stone — Tue, 06 May 2025 18:50:57 +0000

Mr. Stone

May 6 '25

Cloud-Native: Are You Paying for What You Use… or for What You Provision?

#cloudnative #finops #architecture #microservices

4 min read

Cloud-Native: Are You Paying for What You Use… or for What You Provision?

Mr. Stone — Tue, 06 May 2025 18:49:27 +0000

Everyone’s in the cloud.

Stacks have migrated. Infrastructure is containerized. CI/CD pipelines are green.

But behind the wave of “cloudification”, one question lingers:

Have we really changed the way we think?

Because on the surface, everything looks modern. But underneath?

⏱️ Services running 24/7
💤 Containers sitting idle, waiting for traffic that never comes
💸 Bills growing, even when no one clicks “deploy”

And in every retro, every finance meeting, the same old line:

“The cloud is expensive.”

But is it really the cloud that’s expensive?

Or is it…

The quiet luxury of feeding CPUs that are just bored?

Cloud-Native is a Mindset, Not a Tech Stack

Let’s be honest.

Cloud-native isn’t Docker. It’s not Kubernetes. It’s not Terraform, or some magic mix of YAML, containers, and CI/CD.

Those are tools. Powerful ones. But tools.

Cloud-native is a mental shift.

It’s about aligning your architecture with reality, not just with best practices.

It means building systems that respond to demand, not to fear, habits, or legacy reflexes.

In a truly cloud-native system:

Nothing spins unless someone needs it
The context triggers the system, not a clock
You don’t run “just in case”, you run with intention

That’s the difference between moving fast… and just moving your old thinking into someone else’s datacenter.

The "Overprovisioning" Paradox

We’ve all heard it:

“In the cloud, you only pay for what you use.”

Except… that’s not how most systems are built.

In reality?

Containers run 24/7, even when no one is using them
Functions are deployed, but never invoked
Databases sit there "just in case"
Logs accumulate endlessly, never queried, never archived

Ask yourself:

Is that usage?

Or is it just a modern form of invisible technical debt?

The real problem isn’t the cloud. It’s how much we cling to our comfort zone, by provisioning for fears instead of designing for reality.

We don’t measure.
We don’t turn things off.
We just leave everything on… “just to be safe.”

Meanwhile, the meter runs.

Microservices ≠ Files: They're Units of Value

Somewhere along the way, “microservice” became synonymous with:

its own Git repo,
its own Dockerfile,
its own CI pipeline,
and… its own siloed confusion.

But that’s not what a microservice is.

A microservice is not a file structure. It’s not a DevOps checklist.

A microservice is a unit of responsibility that delivers clear value to a real actor.

It knows what it does.
It aligns with a specific domain concept.
It evolves independently because it has a distinct purpose.

In Domain-Driven Design, we’d call that a bounded context:

A functional boundary, aligned with business reality, not just code structure.

When we break systems apart without that clarity, we don’t gain agility, we multiply complexity.

We don’t build autonomy, we scatter responsibilities.

Cloud-native thinking isn’t about more microservices. It’s about just enough, well-aligned, and coherent responsibilities.

Because architecture isn’t about splitting things up. It’s about making sense of how they come together.

FinOps Is Not a Dashboard

FinOps isn't a spreadsheet.

It’s not a quarterly report from the finance team.

It’s not a postmortem when the cloud bill explodes.

FinOps is an architectural responsibility.

It starts at design time, not at invoice time.

In a truly cloud-native system:

Observability is built-in, you measure before you guess
Resources are intentional, you spin only what brings value
Waste is visible, and temporary, not permanent

You don’t leave zombie services alive “just in case.”

You don’t accumulate logs and metrics you'll never read.

You don't ignore your own cost structure because “S3 is cheap.”

Every byte stored, every container idling, every unused feature?

That’s not neutral.

That’s a real architectural debt, with a running tab.

Being cloud-native means thinking cost the same way you think latency, UX, or security:

→ As a design constraint.

→ As a quality signal.

→ As a source of clarity.

Final Thoughts: The Architecture That Thinks

An application only exists when it’s alive.

When it’s responding to a real demand.

When it has a purpose, and a pulse.

Yet so many systems are designed to exist, not to respond. 😄

They’re “always on.”
They’re provisioned in advance.
They consume power without context.

But what if we built systems differently?

Systems that activate when the user calls
Systems that rest when they’re not needed
Systems that adapt based on actual usage, not hopeful guesses

That’s not magic. That’s not just serverless.

That’s what it means to design for context, to make your architecture aware of:

its environment,
its triggers,
its lifecycle,
and its real value.

Because in the end:

The cloud charges you for what you consume.

But only you can decide what’s worth consuming.

Let’s Talk 👇

Have you ever caught yourself "overprovisioning" just to feel safe?

Have you worked on a system that looked modern… but under the hood, felt like legacy in a new wrapper?

What trade-offs did you make?

What worked, or didn’t?

I’d love to hear from engineers, architects, SREs, and cloud teams: How cloud-native is your stack, really?

Let’s compare notes. Let’s be honest.

The most valuable insights usually come from those weird edge cases we don’t put on slides.

Coding is execution. Thinking is creation.

Mr. Stone — Tue, 29 Apr 2025 05:19:07 +0000

Mr. Stone

Apr 29 '25

Coding faster is not building better: A reflection for developers in the AI era

#ai #softwaredevelopment #futureofwork #developers

1 min read

Coding faster is not building better: A reflection for developers in the AI era

Mr. Stone — Tue, 29 Apr 2025 01:40:39 +0000

The rise of AI coding assistants like Claude, GitHub Copilot and ChatGPT has transformed the way we produce code.
What once took hours can now be generated in seconds.

This incredible acceleration raises an important question:
Does generating code faster really mean we're building better solutions?

Writing code has always been an act of execution.
But real development goes far beyond producing lines of syntax.

It’s about understanding the domain, anticipating the needs, structuring the context, designing for evolution and change.

AI can assemble code snippets.
AI can replicate existing patterns.
But AI does not yet think.

It does not understand the causal link between a business need, a user expectation, and a software system designed to meet them.

Developers who focus only on code production will be outpaced.
Developers who can think, structure, and contextualize will stay essential.

In the AI era, true software craftsmanship is not about typing faster.
It's about thinking deeper.
As AI accelerates code generation, our true value as developers must evolve:

Think before you code.
Design before you execute.
Understand before you automate.

In the future, the real question won't be how fast you can ship code,
but how well you understand what you are building — and why?