DEV Community: Ricardo Morato

Why I rewrote aside

Ricardo Morato — Sun, 04 Oct 2026 00:00:00 +0000

I've rebuilt aside more than once, and the last rewrite is the one that changed the most. Before I say what I changed, the first thing: I tried to sell aside and I couldn't. I'm not saying it with drama, it's what happened.

What I tried first

Between March and May I was posting about aside on LinkedIn. I saw no results and I stopped.

How it was before

The first version "saw" the screen and decided on the spot where to click or what to highlight. It failed too much. When something fails because of how it's set up, tuning doesn't fix it.

What changed

Now it's your app that tells aside what it can do: create an invoice, change a setting, open a screen. aside chooses what to do and with what data, and your own code runs it.

You tell it "invoice Orbit Labs €2,400 for the month of September" and it leaves the invoice filled in, ready for you to send. What changes is who decides what is possible: your app, not aside guessing.

What I removed

Before, you could also talk to it by voice. I realised it caused problems, it was very expensive and it wasn't essential. I removed it to focus on making what it does work well every time.

The price

Before, it started at €249, too much for solo founders and small startups. Now it starts at €49.

Before and now

	Before	Now
How it decides what to do	It saw the screen and decided where to click	The app tells it what it can do, aside picks and the SaaS's own code runs it
Voice	You could talk to it	I removed it
Price	From €249	From €49

What it does today

Two things. The first is onboarding: it takes your users through setup step by step, in a guided and natural way, and fills in each field while they talk. The second is support: it answers with your documentation and, when that isn't enough, it acts.

aside's own dashboard runs on aside: you tell it in one sentence how you want your agent and it sets it up for you.

All of this came from talking to customers and seeing where it failed. I don't know if it's the final version, but it is the most polished one.

So far, three conversations

I've talked to three leads. That's few, and I'm not going to draw market conclusions from three people. What I'm telling you is what happened.

One told me the price was expensive. The other two never replied.

About the one who said it was expensive I know something concrete: for that person, the price is an objection. It's a data point, even if it's only one.

About the two who disappeared I know nothing. A silence is not a no, and it's not a yes either. It doesn't tell me whether they weren't interested in the product, whether the timing was bad or whether my message didn't manage to say anything to them.

With three conversations there is no pattern yet.

Why your webhooks arrive duplicated and how to stop them costing an invoice

Ricardo Morato — Sun, 27 Sep 2026 00:00:00 +0000

In an ERP, a duplicated webhook is not a technical bug. It's a wrongly issued invoice.

I work on the ecommerce integrations of a SaaS ERP: Shopify, WooCommerce, PrestaShop. Each store sends us events about its orders, and the expensive mistake is always the same: the system does the same thing twice, or does today what was already corrected yesterday. In this post I explain the layers I use to avoid it and why each one exists.

What you can't assume about a webhook

A webhook does not guarantee that an event arrives only once or in order. Shopify, for example, does not guarantee ordering within a topic or across topics for the same resource and recommends ignoring duplicates with the X-Shopify-Webhook-Id header.

With one store it's rare. With thousands of integrations, rare stops being rare: any combination of duplicate, concurrency and disorder happens every day. That's why there is no single solution. There are layers, and each one covers a gap the others don't see.

Before the layers there is a base rule: the endpoint only verifies the signature, stores the event exactly as it arrives and responds 200. Everything else happens in a worker, so the response does not depend on how long processing takes. Storing the raw event also lets you reprocess and audit it when there is a bug.

And a webhook is a notification, not the truth. For a critical decision, like issuing an invoice, it's better to request the order again from the store's API instead of trusting the payload you received.

Layer 1: discard the identical before processing it

The cheapest one. You compute a hash of the payload and store it in Redis with an expiry. If it already exists, the event is a repeat and you discard it without touching the database.

// Illustrative example, not the real code
$key = "webhook:{$shopDomain}:" . hash('sha256', $payload);

// SET NX EX: check and mark in a single atomic operation
if (!$redis->set($key, '1', ['NX', 'EX' => 300])) {
    return; // already received, discard
}

try {
    $this->inbox->store($rawEvent); // durable, unique per event id
} catch (\Throwable $e) {
    $redis->del($key); // if it wasn't stored, the provider's retry must be able to get through
    throw $e;
}

What matters is that checking and marking is a single operation, which is exactly what SET with NX and EX does. If you do a GET and then a SET, two copies of the same event that arrive at the same time both get through. The key includes the store because the same id can repeat across different stores.

Even so, this layer is an optimisation: Redis can lose or expire the key, so the deduplication that guarantees anything is the durable one, with a unique constraint on the event id. What Redis does do is take work off your plate: in my case it discards about a quarter of the events before they use up resources.

Layer 2: a lock per order

The hash doesn't help against two different events for the same order that arrive almost at once. If two workers process them in parallel, each one reads the order's state, modifies it and writes it, and the last one to write wins.

The solution is to serialise the work per order with a distributed lock: before processing, the worker takes that order's lock and, if another worker holds it, it retries a bounded number of times, with some randomness in the wait, or puts the event back on the queue. But the lock coordinates, it doesn't prove correctness. What really prevents losing a write is saving with a conditional write by version, which fails if someone got there first.

// Illustrative example, not the real code
$lockKey = "lock:{$tenantId}:order:{$orderId}";
$token = bin2hex(random_bytes(16)); // unique per acquisition

if (!$redis->set($lockKey, $token, ['NX', 'PX' => 30000])) {
    throw new RetryLater(); // another worker is on this order
}

try {
    $this->process($event); // the final save is a conditional write by version
} finally {
    // Lua script: if get(key) == token then del(key); never GET and then DEL
    $redis->eval(self::RELEASE_IF_OWNER, [$lockKey, $token], 1);
}

Three details that matter: the lock expires (it's a lease, with a duration longer than the measured time the work takes), the value is a unique token per acquisition and it's released by comparing that token atomically. Even so, if the worker takes longer than the lease, another one gets in while the first is still writing. That's why the lock doesn't replace the conditional write or business idempotency.

Layer 3: ignore what arrives late

Even if they don't overwrite each other, events can arrive out of order. An ordering guard compares the event's date with the date of the last state you have already applied, discards the one that is older and records that it discarded it.

// Illustrative example, not the real code
// The watermark lives in the order itself
if ($event->emittedAt() < $order->lastEmittedAt()) {
    $this->logger->info('webhook.stale_discarded', ['orderId' => $orderId]);
    return; // older than what has already been applied
}
// when saving, the same check goes inside the conditional write

You have to decide what you compare. The event's date at the provider, not the time it reached you, because delivery can be delayed. If the provider also gives a version or a sortable id, store it: two updates in the same second tie on date. And the check must travel in the conditional write, not only in a previous if, because between the if and the save another worker may have got ahead.

Layer 4: what a hash can't see

The same refund can arrive by two different routes, with different payloads. To the hash they are two unrelated events, so both get through.

Here I don't deduplicate messages, I apply business idempotency: the key comes from the identity of the refund (the store and the refund id), not from the content or the delivery. The question changes from "have I seen this message?" to "have I already applied this refund?". That key has to live in the database with a unique constraint and store the result, so a retry returns the same thing. In Redis, which expires, it's not enough.

Don't overwrite what the merchant edited by hand

A merchant can edit a document by hand after we have generated it. If another sync event arrives, you don't want to overwrite that edit.

For that I compare two hashes: one of the fiscal fields and one of the non-fiscal fields. That way I see what has really changed between what I have and what arrives, and I don't flatten a manual edit. So that the hash doesn't invent differences, you have to normalise the amounts to the same precision and sort the keys before computing it.

The exchange rate, fixed to the original document

A detail that causes false differences: if an order is in another currency and you recalculate with the exchange rate of each event, the volatility between one event and the next makes the amounts not add up even though nothing has changed.

I fix the exchange rate of the original document across the whole chain of events, so the amount only changes when the order changes.

Summary of the layers

Layer	What it prevents	Where the guarantee is
1. Hash in Redis	Processing an identical event twice	In durable deduplication by event id: Redis only saves work
2. Lock per order	Two workers processing the same order at once	In the conditional write by version
3. Ordering guard	An old event overwriting a new one	In the check inside the conditional write
4. Business idempotency	Applying the same refund twice	In a durable key with a unique constraint

What's left

None of these pieces is sophisticated on its own. What's hard is having all of them, and having every new incident come in with a test that stops it from happening again; how I automate that cycle is in From a Slack thread to a pull request. With the four layers and those two precautions, a repeated or out-of-order event should not change the order twice.

And since webhooks also get lost, the system has to converge even if none arrives: that takes a periodic reconciliation against the store, which Shopify also recommends.

From timeout to 10 seconds: finding the real bottleneck

Ricardo Morato — Sun, 20 Sep 2026 00:00:00 +0000

There was a screen that, on large accounts, would not open.

It was the listing of document items. On accounts with a lot of volume it hit the nginx timeout, 60 seconds, and for the customer it was simply unreachable. That module was already built. I rebuilt it on my own, frontend and backend.

The backend is PHP with Symfony and CQRS, and the frontend is React. I simplify the code in this post so the idea is clear.

Measure before touching

The temptation is to optimise the first thing that smells bad. Before that, I looked at where the time and the memory were going, and not only the total time: a high total time doesn't tell you whether the problem is the database, the ORM or the frontend. The bottleneck was the ORM's memory consumption.

When an ORM loads many records, it turns each one into objects, and those objects take up memory for as long as they stay alive. With tens of thousands of products, that memory shoots up and the listing never finishes in time.

First change: process in batches

Instead of loading all the items at once, I process them in batches and free memory between one and the next. This is the pattern in the Doctrine batch processing documentation, which calls clear() between batches to free memory.

foreach (array_chunk($ids, $batchSize) as $chunk) {
    $items = $repository->findByIds($chunk);

    yield from $this->present($items);

    $entityManager->clear(); // releases the objects from the previous batch
}

This step still hydrates full entities, but memory stops growing with the size of the account and depends mostly on the size of the batch. That size is a trade-off: bigger performs better, smaller uses less memory, and you choose it by measuring.

Second change: a view instead of the aggregate

Even when processing in batches, loading the full aggregate of each item is expensive. The aggregate exists to protect invariants when writing, and to render a list you don't need it. So I applied a view: the listing no longer goes through the aggregate and reads a read projection, a flat object with only the fields the screen renders.

In CQRS that is a query with its handler, and the handler loads nothing: it asks a read gateway for the data.

final readonly class ListDocumentItemsQuery
{
    public function __construct(
        public string $tenantId,
        public string $documentId,
    ) {}
}

final readonly class ListDocumentItemsQueryHandler
{
    public function __construct(private DocumentItemsReadGateway $items) {}

    /** @return iterable<DocumentItemView> */
    public function __invoke(ListDocumentItemsQuery $query): iterable
    {
        yield from $this->items->stream($query->tenantId, $query->documentId);
    }
}

The handler returns an iterable, not an array. That is the key to everything that comes next: with a generator, only one row is in memory at a time, the one being processed.

The read gateway is the one that talks to the database. It projects only the fields that are needed, sorts in a stable way and hands out rows with yield as the cursor brings them:

final class MongoDocumentItemsReadGateway implements DocumentItemsReadGateway
{
    /** @return \Generator<DocumentItemView> */
    public function stream(string $tenantId, string $documentId): \Generator
    {
        $cursor = $this->collection->find(
            ['tenantId' => $tenantId, 'documentId' => $documentId],
            [
                'projection' => ['sku' => 1, 'name' => 1, 'quantity' => 1, 'price' => 1],
                'sort' => ['_id' => 1], // stable order, with a unique tie-breaker
                'batchSize' => $this->batchSize,
            ],
        );

        foreach ($cursor as $row) {
            yield DocumentItemView::fromRow($row);
        }
    }
}

The heavy fields, the ones only needed on small accounts or when opening the detail, are loaded conditionally depending on the size of the account. Separating reads and writes this way doesn't require a second database or event sourcing: the separation is logical.

Third change: streaming from the controller

With an iterable in hand, the controller can start responding without waiting to have all the rows. In Symfony this is done with a StreamedResponse that writes one line of JSON per item (NDJSON) and flushes:

#[Route('/documents/{documentId}/items', methods: ['GET'])]
final class ListDocumentItemsController
{
    public function __construct(private QueryBus $queryBus) {}

    public function __invoke(string $documentId, TenantContext $tenant): StreamedResponse
    {
        $items = $this->queryBus->ask(
            new ListDocumentItemsQuery($tenant->id(), $documentId),
        );

        $response = new StreamedResponse(function () use ($items): void {
            foreach ($items as $i => $item) {
                echo json_encode($item, JSON_THROW_ON_ERROR) . "\n"; // one row per line

                if ($i % 100 === 0) {
                    flush(); // sent in batches, not row by row
                }

                if (connection_aborted()) {
                    return; // the client has gone, we stop reading
                }
            }
        });

        $response->headers->set('Content-Type', 'application/x-ndjson');
        $response->headers->set('X-Accel-Buffering', 'no'); // nginx must not buffer the response

        return $response;
    }
}

Two details matter. The first, X-Accel-Buffering: no: without it, nginx buffers the response and the client receives nothing until it finishes, and the streaming is pointless. The second, that nginx's read timeout is measured between two reads, not over the whole response: as long as rows keep arriving, it doesn't trigger. Symfony also ships StreamedJsonResponse, which accepts generators; here I use NDJSON because the frontend reads the stream line by line.

Fourth change: React renders with the first results

The other side is making the frontend not wait. To read the stream, an async generator that splits the lines as they arrive:

async function* streamItems(documentId: string, signal: AbortSignal) {
  // In the real frontend this sits behind a repository, with the whole DDD layer; here it goes straight to fetch to keep it simple
  const response = await fetch(`/api/documents/${documentId}/items`, { signal });
  if (!response.ok || !response.body) throw new Error(`HTTP ${response.status}`);

  const reader = response.body.pipeThrough(new TextDecoderStream()).getReader();
  let buffer = '';

  while (true) {
    const { done, value } = await reader.read();
    if (done) break;

    buffer += value;
    const lines = buffer.split('\n');
    buffer = lines.pop() ?? ''; // the last line may arrive half-finished

    for (const line of lines) {
      if (line) yield JSON.parse(line) as DocumentItem;
    }
  }
}

And to hook it up to useQuery, TanStack Query's streamedQuery: it accumulates the chunks that arrive into an array. The query is pending until the first one arrives, moves to success at that moment, and stays fetching until the stream closes.

import { queryOptions, useQuery, experimental_streamedQuery as streamedQuery } from '@tanstack/react-query';

const documentItemsQuery = (documentId: string) =>
  queryOptions({
    queryKey: ['document-items', documentId],
    queryFn: streamedQuery({
      streamFn: ({ signal }) => streamItems(documentId, signal),
    }),
  });

function DocumentItemsList({ documentId }: { documentId: string }) {
  const { data = [], isPending, isFetching } = useQuery(documentItemsQuery(documentId));

  if (isPending) return <ListSkeleton />;

  return (
    <>
      <ItemsTable rows={data} />
      {isFetching && <p>Loading more…</p>}
    </>
  );
}

streamedQuery is still marked as experimental in TanStack Query, so its API may change.

For the person using the screen, the difference is huge: they see the first item almost immediately, instead of having to wait 40 seconds to see it.

What to watch out for with streaming

While rows are arriving the total isn't known yet, so the screen shouldn't show an "of N" or an invented percentage. The order has to be stable, with a unique tie-breaker, or a row can appear twice or be skipped. And it's better to send the rows in batches, not one by one, because with tens of thousands of rows rendering each one separately eats the browser.

Summary of the changes

Change	What it removes
Batches	Memory growing with the size of the account
A view instead of the aggregate	Hydrating the full aggregate of every item
Streaming from the controller	Waiting for all the rows before responding
React with `streamedQuery`	Waiting for everything to arrive before rendering

Result

From timeout to about 10 seconds, with the screen filling up from the first results. With that you can get into accounts with more than 100,000 products.

Ten seconds is not fast, but before it didn't open.

The same thing, at another scale

In the webhook pipeline, which I cover in Why your webhooks arrive duplicated, I follow the same rule. I use Datadog's APM and traces to see which parts of the flow are really slow, and I aim the optimisation there, not where it seems. The traces are sampled and are useful for performance; it's also worth measuring how long each message waits in the queue, because sometimes the slow part is the wait and not the code.

Before optimising, measure.

From a Slack thread to a pull request: an agent that reproduces the incident

Ricardo Morato — Sun, 13 Sep 2026 00:00:00 +0000

A customer incident usually starts with a support message in Slack: this store had this happen with an order. And from there the path is almost always the same.

The manual path

Find the pipeline logs, reconstruct which webhooks arrived and in what order, understand what happened, write a test that reproduces it and, finally, fix it. Almost all of it is mechanical, and the only thing that changes from one incident to the next is the case. That's why I built an agent that walks that path.

What the agent does

Starting from the Slack thread:

It retrieves the pipeline logs.
It reconstructs the real sequence of webhooks we received from the store.
It generates a test that reproduces the case.
It proposes the fix in a pull request.

When reconstructing the sequence you have to look at two clocks: the order in which each webhook arrived and the date on which the provider emitted it. Many incidents are exactly the difference between the two; I cover the layers I use to prevent them in Why your webhooks arrive duplicated.

First the test, then the fix

The order matters. In my area, every incident comes in with a test that stops it from happening again, so the agent doesn't start by fixing: it starts by reproducing.

A test that fails for the right reason is the proof that you have reproduced the problem, and reproducing it is the first step to understanding it. If the agent can't reproduce the case, there is nothing to fix yet. Sometimes the cause is that a piece of data is missing: a webhook that never arrived or an external result that was left in doubt. That is also a useful result, and it's better to know it before it proposes a blind patch.

For a webhook incident, the test has to be deterministic: the events in the order in which they happened, a fixed clock and fakes that respect the same constraints as production, like uniqueness and versions, because a fake without them makes a concurrency test lie. The payloads come from real cases, but they have to be scrubbed before they are left in the repository.

The panel that already existed

Before this I had built another piece in the same direction: an operations panel for the webhook pipeline, so that Customer Support can diagnose a case without escalating it to engineering. You search by store, provider and event type, you see the processing state live, and each order has its timeline with all its events chained by correlation ID.

Logs explain what a process did, but they can be sampled or have expired. The current state and its history of transitions live in a durable entity, and that's where it's best to read what happened. Logs and traces point to that state, they don't replace it.

It's the same idea from two sides: making the path between "something has failed" and "I know exactly what happened" short.