Column

📌 TL;DR

Flatend is a concept I’m proposing — a way to move beyond the traditional frontend/backend split by running functions, views, and jobs within a single module graph. I believe this approach, especially when combined with AI, could open up new possibilities for how we build software.

🤔 Do We Really Need the Frontend/Backend Divide?

For years, the pattern was simple:

Frontend → UI and interaction
Backend → APIs and databases

But lately, this division has started to feel more like a burden than a benefit:

Cloud and edge computing are everywhere
Serverless is becoming the norm
Small teams need to experiment quickly
Data permissions are getting more complex

Which made me ask:

👉 “Do we really still need to separate frontend and backend?”

🏗️ Introducing the Flatend Concept

This is where Flatend comes in — a concept I’d like to put forward.

In Flatend, applications are built around Functions, Views, and Jobs as the fundamental units. Execution is declared via place() and capability, and the runtime decides where things actually run.

The core principles I’m envisioning are:

Capability First → no permission, no build
Schema as Contract → schema-driven data agreements
Data at the Edge → expose only what’s necessary, with minimum privileges
Observability Built-in → monitoring embedded at every unit of execution

It doesn’t exist today, but I believe this approach could open a path toward a new way of thinking about full-stack development.

⚙️ Runtime Model and Data Access

In my proposal, Flatend assumes four runtime layers:

Browser
Edge
Server
Worker

And data access isn’t just “query anything” — it’s policy-driven:

RLS (Row-Level Security)
safeView (read-only views)
Command (explicit commands for mutations)

Most importantly, if a capability isn’t declared, the code won’t even build.
This enforces trust and avoids the all-too-familiar “full-stack spaghetti” problem.

🤖 Flatend Meets AI

Flatend and AI feel like a natural match.

Small function units + declarative permissions are ideal for AI orchestration
Schema-based contracts help reduce hallucinations and keep automation safe
place() allows AI to optimize execution (browser for privacy, server for performance, edge for cost, etc.)

For example, if a user says:
“Add Tesla to my watchlist”

LLM → addWatch() function call → DB update → worker job trigger

That’s the kind of flow Flatend could enable.

👩‍💻 How It Could Change Developer and Team Experience

If Flatend became real, I think it would change the way we work:

DX: Handle UI, domain logic, jobs, and AI all from a single repo
Collaboration: Less “Frontend vs Backend,” more Use Case Owners
Ops: Deploy at the function/job level → faster rollbacks, built-in observability

For small teams building SaaS, this could be a real productivity booster.

⚠️ Where It Fits — and Where It Doesn’t

Since this is just a proposal, I also see clear limits.

Where Flatend could shine

Startups and SaaS
Internal tools, dashboards
Collaboration platforms, rapid prototypes

Where to be cautious

Risk of data overexposure
Long-running jobs won’t work well at the edge
Lock-in to specific models/platforms
Bundle management complexity

So it’s not a silver bullet — but in the right context, it could be very powerful.

🚀 Looking Ahead: Why This Proposal Matters

The vision of Flatend + AI looks something like this:

👉 “Developers only define functions and policies. The runtime and AI take care of orchestration.”

Right now, this is just my idea — but I believe this kind of paradigm could become reality in the near future.

So let me leave you with two questions:

In your team, is the FE/BE boundary still meaningful?
If AI could automatically choose the best execution environment for your code, how would you use it?

👉 Call to Action: Try experimenting with Flatend-style thinking in one of your smaller projects.

Flatend: A New Proposal to Break Down the Frontend/Backend Divide