Forem: Horda

Stateful Serverless - Cloud Functions without Amnesia

Horda — Tue, 18 Nov 2025 01:10:57 +0000

In our previous post, we explored how Horda entities work like Flutter's stateful widgets, but on the backend. We also mentioned that Horda is a stateful serverless platform. But what does that mean exactly?

If you are a Flutter developer, whenever someone mentions the word "serverless", there's a high chance that Firebase Cloud Functions would come to mind. Except unlike Horda, they are stateless.

So in this post let's explore what's the difference between stateful and stateless serverless, and how stateful serverless replaces traditional databases with a much faster, simpler, and more cost-efficient approach.

The Problem with Stateless Functions

When we say Firebase Cloud Functions are stateless, we mean they have complete amnesia. Every time a function is invoked, it starts from scratch with no memory of previous calls. It's like having a conversation where the other person forgets everything the moment you stop talking.

Let's look at a practical example to see how this plays out. Imagine you need to implement a bank account withdrawal: check if there's sufficient balance and update it atomically to prevent race conditions.

Here's how you'd implement this with Firebase Cloud Functions:

exports.withdrawFunc = onCall(async (request) => {
  const { accountId, amount } = request.data;
  const db = admin.firestore()

  // Validate request data
  if (!accountId || typeof accountId !== 'string') {
    throw new HttpsError('invalid-argument', 'Invalid accountId');
  }
  if (typeof amount !== 'number' || amount <= 0) {
    throw new HttpsError('invalid-argument', 'Invalid amount');
  }

  const accountRef = db.collection('accounts').doc(accountId);

  // Use transaction to handle race conditions
  return await admin.firestore().runTransaction(async (transaction) => {
    // Read account document from Firestore
    const accountDoc = await transaction.get(accountRef);

    // Check if account exists
    if (!accountDoc.exists) {
      throw new HttpsError('ACCOUNT_NOT_FOUND');
    }

    // Check if balance is sufficient
    const currentBalance = accountDoc.data().balance;
    if (currentBalance < amount) {
      throw new HttpsError('INSUFFICIENT_FUNDS');
    }

    // Calculate new balance
    const newBalance = currentBalance - amount;

    // Write back to Firestore
    transaction.set(accountRef, {
      balance: newBalance,
    });

    return { newBalance: newBalance };
  });
});

Now, here's the same operation with Horda:

class BankAccount extends Entity<BankAccountState> {
  Future<RemoteEvent> withdraw(
    WithdrawAccount command,
    BankAccountState state,
    EntityContext ctx,
  ) async {
    if (state.balance < command.amount) {
      throw AccountException('INSUFFICIENT_FUNDS');
    }

    return AccountBalanceUpdated(
      newBalance: state.balance - command.amount,
    );
  }
}

@JsonSerializable()
class BankAccountState extends EntityState {
  double balance = 0;

  void balanceUpdated(AccountBalanceUpdated event) {
    balance = event.newBalance;
  }
}

Look at the difference! The Firebase version is 40+ lines, while Horda is just 20. But it's not just about line count. Let's see what's really happening here.

Breaking Down the Differences

Database Roundtrips vs State Ready to Use

Firebase Cloud Functions:

// Read account document from Firestore
const accountDoc = await transaction.get(accountRef);

// Check if account exists
if (!accountDoc.exists) {
  throw new HttpsError('ACCOUNT_NOT_FOUND');
}

// Check if balance is sufficient
const currentBalance = accountDoc.data().balance;

Every single time your function runs, it has to fetch the account data from Firestore. The function remembers nothing. Even if the same account was accessed milliseconds ago, it starts from scratch with a database roundtrip. And each of these roundtrips costs you money, so you have to remember that Firestore charges per document read, write, and delete.

Horda:

Future<RemoteEvent> withdraw(
  WithdrawAccount command,
  BankAccountState state,  // Current state is right here!
  EntityContext ctx,
) async {
  // You can easily access state to check the balance
  if (state.balance < command.amount) {
    throw AccountException('INSUFFICIENT_FUNDS');
  }

  return AccountBalanceUpdated(
    // And calculate the new balance
    newBalance: state.balance - command.amount,
  );
}

The entity provides its state in the handler, so you can read state.balance immediately. No database calls. No roundtrips. No per-read charges. This is what we mean by stateful serverless: your code has access to state without manually having to fetch it from a database every time.

Database Orchestration Overhead vs Pure Business Logic

Firebase Cloud Functions:

const { accountId, amount } = request.data;
const db = admin.firestore()

// Validate request data
if (!accountId || typeof accountId !== 'string') {
  throw new HttpsError('invalid-argument', 'Invalid accountId');
}
if (typeof amount !== 'number' || amount <= 0) {
  throw new HttpsError('invalid-argument', 'Invalid amount');
}

const accountRef = db.collection('accounts').doc(accountId);

return await admin.firestore().runTransaction(async (transaction) => {
  const accountDoc = await transaction.get(accountRef);

  // Check if account exists
  if (!accountDoc.exists) { /* ... */ }

  // Get balance from document
  const currentBalance = accountDoc.data().balance;

  // ...

  transaction.set(accountRef, {
    balance: newBalance,
  });

  return { newBalance: newBalance };
});

Look at how much code is dedicated to database operations: initializing Firestore, validating inputs, creating references, wrapping in transactions, reading, writing. Your actual business logic (checking balance and calculating the new amount) is buried somewhere in the middle. This is the 80/20 problem: 80% database orchestration, 20% actual logic.

Horda:

  if (state.balance < command.amount) {
    throw AccountException('INSUFFICIENT_FUNDS');
  }

  return AccountBalanceUpdated(
    newBalance: state.balance - command.amount,
  );

This is pure business logic. Check the balance. Calculate the new amount. Return what happened. No database code at all. Horda handles persistence behind the scenes: when your command handler returns an event, state is automatically updated and persisted to a state-of-the-art storage layer purpose-built for stateful serverless workloads. Horda also handles scaling and replication so your entities remain fast and available under any load.

Transaction Complexity vs Automatic Serialization

Firebase Cloud Functions:

// Use transaction to handle race conditions
return await admin.firestore().runTransaction(async (transaction) => {
  // Read account document from Firestore
  const accountDoc = await transaction.get(accountRef);

  // ... validation and logic

  // Write back to Firestore
  transaction.set(accountRef, {
    balance: newBalance,
  });

  return { newBalance: newBalance };
});

Without transactions, you'd have race conditions. Two simultaneous withdrawals could read the same balance, both think there's enough money, and both succeed, even if the account doesn't have enough for both. So you wrap everything in a Firestore transaction, which adds complexity and another layer of nesting.

Horda:

  // Entity receives commands
  WithdrawAccount command,

  // And produces events
  return AccountBalanceUpdated(
    newBalance: state.balance - command.amount,
  );

No transaction code needed. Horda entities work by executing business logic upon receiving commands and producing events which update the state. When multiple commands come in for the same entity, Horda automatically queues them and processes them one at a time, in order, with the correct state for each subsequent command. Your code runs with guaranteed consistency. Race conditions simply can't happen.

You also benefit cost-wise. A simple withdrawal operation requires at least one read (inside the transaction) and one write. If there's contention and the transaction retries, those costs multiply. High-traffic operations can quickly rack up significant database bills.

Learning Curve: JavaScript vs Dart

Firebase Cloud Functions:

exports.withdrawFunc = onCall(async (request) => {
  const { accountId, amount } = request.data;

  // Validate request data manually
  if (!accountId || typeof accountId !== 'string') {
    throw new HttpsError('invalid-argument', 'Invalid accountId');
  }
  if (typeof amount !== 'number' || amount <= 0) {
    throw new HttpsError('invalid-argument', 'Invalid amount');
  }

  // Other JavaScript code, Firestore API, HTTP errors...
});

As a Flutter developer, you're switching to JavaScript (or TypeScript), learning Firebase's API, understanding request/response patterns, and dealing with a completely different programming model. You also have to manually validate all incoming data because JavaScript doesn't have strong typing by default.

Horda:

// Command handler - just a Dart function, with well defined signature
Future<RemoteEvent> withdraw(
  WithdrawAccount command,
  BankAccountState state,
  EntityContext ctx,
) async { /* ... */ }

// Your command, event, and state - strongly typed Dart classes with serialization
@JsonSerializable()
class WithdrawAccount extends RemoteCommand { /* ... */ }

@JsonSerializable()
class AccountBalanceUpdated extends RemoteEvent { /* ... */ }

@JsonSerializable()
class BankAccountState extends EntityState { /* ... */ }

You're writing Dart, the same language you use for Flutter. Your command handler is just a regular Dart function. Your commands, events, and state are strongly typed classes with @JsonSerializable annotations, which means:

No manual validation needed - Dart's type system ensures amount is a double, not a string or null
Automatic serialization - The @JsonSerializable annotation generates all the serialization code for you
Familiar patterns - As described in the previous post, everything feels natural because it's the same language and patterns you already know

Try It Out!

Ready to experience stateful serverless for yourself? The Horda SDK includes a local development server, so you can start building on your own machine before deploying to production.

Check out these resources to get started:

Horda Website - Learn more about the stateful serverless platform
Quick Start - Build your first real-time counter app
Example Projects - Explore Counter and bank account examples

We'd love to hear your thoughts and feedback as you explore!

Flutter Stateful Widget on the Backend

Horda — Thu, 13 Nov 2025 22:11:17 +0000

If you're a Flutter developer who's ever tried to build a backend, you know how challenging the transition can be. You need to learn about databases, HTTP protocols, and often pick up an entirely new programming language. And if your app requires custom business logic with complex state management, things get even more complicated.

Perhaps you even worked with Firebase, so you know how cloud functions become difficult to work with, and maintaining state across serverless invocations feels like fighting against the platform.

This is where Horda comes in! Horda is a stateful serverless platform that lets you transition from writing frontend Flutter code to Dart backend with ease, using the same familiar patterns you already know.

Introducing Horda Entity - your stateful widget on the backend

As a Flutter developer you are most likely used to working with stateful widgets. When you think of a stateful widget, three key concepts come to mind:

Triggering state changes through user interactions or events
Updating the state based on those triggers
Rebuilding the widget to reflect state changes in the UI

Now imagine if this very familiar concept was used on the backend too. That's exactly what Horda does! Let's compare them:

Flutter StatefulWidget:

class CounterWidget extends StatefulWidget {
  const CounterWidget({super.key});

  @override
  State<CounterWidget> createState() =>
      _CounterWidgetState();
}

class _CounterWidgetState extends State<CounterWidget> {
  int _counter = 0;

  void _incrementCounter() {
    setState(() {
      _counter++;
    });
  }

  @override
  Widget build(BuildContext context) {
    return TextButton(
      onPressed: _incrementCounter,
      child: Text('$_counter'),
    );
  }
}

Horda Entity:

class CounterEntity extends Entity<CounterState> {
  Future<RemoteEvent> incrementCounter(
    IncrementCounter command,
    CounterState state,
    EntityContext context,
  ) async {
    return CounterIncremented(by: command.by);
  }

  // ...
}

@JsonSerializable()
class CounterState extends EntityState {
  int _counter;

  CounterState({this._counter = 0});

  void counterIncremented(CounterIncremented event) {
    _counter += event.by;
  }

 // ...
}

Just like a Flutter StatefulWidget, a Horda Entity has state and can handle actions. But instead of responding to user taps and gestures, it responds to commands sent from your client app. And instead of calling setState(), it emits events that update its state. The structure should feel immediately familiar if you've worked with stateful widgets!

Triggering state changes with commands

Let's begin breaking down our Counter Entity by looking at how it triggers state changes! In the Counter Horda Entity, the incrementCounter method is a command handler:

Future<RemoteEvent> incrementCounter(
  IncrementCounter command,
  CounterState state,
  EntityContext context,
) async {
  return CounterIncremented(by: command.by);
}

Command handlers work like this:

They receive a command object (like IncrementCounter) which contains the data needed to perform an action
They execute your business logic. In this case, it's simple, but this is where you'd add validation, calculations, or any custom logic
They return an event (like CounterIncremented) that describes what happened

Sending commands from the client to your backend entity is very similar to dispatching notifications in Flutter:

Flutter Notifications:

context.dispatchNotification(
  IncrementCounter(by: 1),
);

Horda Commands:

context.sendEntity(
  name: 'CounterEntity',
  id: 'counter-1',
  cmd: IncrementCounter(by: 1),
);

The key difference? Unlike a Flutter widget notification which is sent and handled locally within your app, the command is sent to the server and handled there.

That's all it takes! No HTTP endpoints to set up, no request/response handling. Just send the command and let Horda handle the rest.

Business logic and updating state

Now let's look at how state updates work. Remember in the command handler, we had access to the current state:

Future<RemoteEvent> incrementCounter(
  IncrementCounter command,
  CounterState state,  // Current state is passed in
  EntityContext context,
) async {
  // You can read state here to make decisions
  if (state.counter > 10) {
    throw StateError('Counter value is too big!');
  }

  return CounterIncremented(by: command.by);
}

The current state is passed into every command handler, so you can read it to make decisions in your business logic, like checking if an operation is valid before proceeding.

But how does the state actually get updated?

Flutter State Updates:

You define state variables in your Dart class that extends State and update them with setState():

setState(() {
  _counter++;
});

Horda State Updates:

You define state in your Dart class that extends EntityState and update it with event handlers:

void counterIncremented(CounterIncremented event) {
  _counter += event.by;
}

When the CounterIncremented event is returned from the command handler, Horda automatically calls the counterIncremented method on your state. Inside this method, you update your state variables just like you would in a Flutter widget's setState() callback. The method name follows a simple convention: it matches the event name but in camelCase.

The Horda platform persists state and updates it every time you change it.

What about rebuilding the UI

Of course, when you think of a stateful widget, you think about rebuilding it to reflect state changes in the UI. With Flutter's StatefulWidget, it's straightforward. You call setState() and display the state value in your widget via build() method.

But now we're talking about backend state. You might be thinking: "Don't I need to write a ton of code to get this data into my UI?" With traditional backends or Firebase, you'd need to:

Create services to manage HTTP requests or set up change listeners
Wire up your widgets to these services
Handle loading states, errors, and data synchronization

With Horda, it's actually quite straightforward. You just query the data you need directly in your widget's build method!

First, define a query for your entity:

class CounterQuery extends EntityQuery {
  @override
  String get entityName => 'CounterEntity';

  final counterValue = EntityCounterView('counter');

  // ...
}

Then, set up the query in your widget's build method:

@override
Widget build(BuildContext context) {
  return context.entityQuery(
    entityId: 'counter-1',
    query: CounterQuery(),
    child: const CounterWidget(),
  );
}

Finally, in any descendant widget, you can query the values directly to display them, and the widget will automatically rebuild when those values change. Notice how similar the code looks:

Flutter Local State:

@override
Widget build(BuildContext context) {
  return TextButton(
    onPressed: _incrementCounter,
    child: Text('$_counter'),
  );
}

Horda Backend State:

@override
Widget build(BuildContext context) {
  final counterValue = context
      .query<CounterQuery>()
      .counter((q) => q.counterValue);

  return TextButton(
    onPressed: _incrementCounter,
    child: Text('$counterValue'),
  );
}

That's the magic! The context.query() method fetches the current value from your backend entity, and whenever that value changes on the backend, your widget automatically rebuilds to reflect the new state. No manual refresh needed!

The system is also quite optimized. Your widget will only rebuild when the specific data it depends on changes. If you're querying multiple properties, changes to unrelated data won't trigger unnecessary rebuilds.

Try it out and get to know more!

Ready to try it out? Horda SDK includes a local development server that lets you run your backend code directly on your machine. Just generate the code with dart run build_runner build, then run dart bin/main.dart to start your local server. Connect your Flutter app to ws://localhost:8080/client and you're up and running!

When you feel like your project is ready for deployment you can create an account and a project on Horda Console at console.horda.dev and publish your package with dart pub tool to a special URL.

More info and details:

Horda Website - Learn more about the stateful serverless platform
Quick Start - Build your first real-time counter app
Example Projects in GitHub - Explore Counter and Twitter example apps