DEV Community: Ed Stephinson

[Boost]

Ed Stephinson — Fri, 28 Mar 2025 21:18:16 +0000

Dr Claire Knight for Sailhouse

Mar 28 '25

Building an Email Confirmation Flow with Sailhouse, Netlify, and Resend

Comments 1

7 min read

Don’t block your users! Why you should adopt event-driven architecture

Ed Stephinson — Wed, 20 Sep 2023 08:51:04 +0000

Building event-driven applications offers a flexible, but markedly different approach to building applications. Let’s take a look at how an event-driven architecture can benefit your users, developers, and your application code.

What does event-driven mean?

Instead of building out complex, nested function calls to handle your application logic, you move to a world where everything is triggered by an event.

Imagine a user applies for a job on your platform. Usually, this would involve a POST request, with a lot of steps (e.g. parsing the resume, notifying the job poster, sending a confirmation email, storing the application details, handling internal analytics, etc) before the user receives a response. This feels slow, and could lead to frustration with the wider platform.

With event-driven design, many of these steps happen in the background. The heavy lifting is done behind the scenes, making things faster for the user.

The benefits of event-driven applications

Let's consider a flow every application has to deal with — user sign-ups. When a user signs up to your service, you'll want to do a few things.

Create their details in the database;
Send a welcome email;
If they're a paid customer, activate any account features.

Let’s take a look at the benefits an event-driven architecture lends to this flow.

Built-in error handling

With event-driven applications, errors not only become less of a problem, but also something you no longer have to fear.

Taking the example of a user sign-up above, let's explore what that might look like in code.

// https://api.acme.dev/users/signup

const { email, password, type } = request.body;

// Create the new user in the database
const userRecord = await db.users.create({ email, password, type });

// Attempt to send a welcome email
await emails.send(email, 'Welcome.......');

// Activate customer payment account
if (type === 'pro') {
  const customer = await stripe.customers.create({ /* ... */ })

  await db.users.update(userRecord.id, { customer_id: customer.id })
}

return { status: 200 }

In this example, if the email provider is down, this whole flow stops. The only way to prevent that being a problem, is by carrying on regardless whether or not the email fails to send, meaning some users may never receive that important, friendly welcome email. You might put the email send method in a try catch block, for example, to prevent the email send from blocking the next action. But that doesn’t solve the problem entirely.


// https://api.acme.dev/users/signup

// ...

try {
  await emails.send(...)
} catch (e) {
  console.error(e);
  console.log('no email for you, sorry');
}

In an event-driven application, once the new user is safely stored in the database, you can hand the rest of the process off to your event platform (ahem, Sailhouse), and let that take care of the rest. What’s more, this means you write less application code.

// https://api.acme.dev/users/signup

const { email, password, type } = request.body;

// Create the new user in the database
const userRecord = await db.users.create({ email, password, type });

// Send an event to Sailhouse, where we'll take care of the rest
await sailhouse.publish('user-created', userRecord);

return { status: 200 }

When you send the event, if the user-created topic doesn’t exist, Sailhouse will create it for you. When you come to create subscriptions for topics in the future (i.e. things that happen after Sailhouse processes an event), you also have the option to process historical events in the topic, so no data is lost. Sweet!

With our user-created topic created in Sailhouse, let's focus on sending that pesky welcome email, by setting up a push send-welcome-email subscription which points to a handler sending the email, which might look like the code below.

// https://api.acme.dev/emails/welcome

const { email } = request.body;

await emails.send(email, 'Welcome to ACME dev!');

return { status: 200 }

If your email provider is down, Sailhouse will retry up to five times over the next 30 minutes and then eventually dead-letters the event (dead letters are events that are on-hold as they couldn’t be delivered as normal). You can then re-queue the event when the provider is back up again, or if you've implemented an alternative.

By decoupling your application logic in this way, your customers benefit from a more reliable experience, while you have an almost self-healing application that minimises data-loss and prioritises as strong UX for your users.

Faster applications for users

Focusing again on the idea of decoupling, event-driven applications can also really speed things up for your users.

Using a traditional architectural approach, when a new user signs up to your product, they must wait until every action has been completed until they can start using your application. Why should they have to wait until the welcome email has been sent?

When you use event-driven architecture, you massively reduce the time it takes for a user to start exploring your product after sign up. Sure, some logic needs to be blocking, but now, not all of it has to be.

Performance is key to a happy customer base, and this is an effective way to ensure they always have a snappy experience.

Complex applications with simple code

Complex code isn’t necessarily a bad thing. When building a product, you have to make sacrifices in order to ship fast and deliver value. This applies to both the early stages when you’re establishing product market fit, and also to a more mature product which might have thousands of successfully onboarded customers.

But complex code can make it more difficult to add new features, or rework existing ones. And that’s where an event-driven architecture shines.

Let’s return to our user-created topic, and say you want to start checking emails in case they’re flagged for spam, and flag them internally for manual review. You can do this in Sailhouse by setting up another push subscription, and start processing events straight away.

This extra functionality is fully isolated, with no modifications to your sign-up code, and everything can be processed in the background without disrupting the flow of your users.

This is one of the huge perks of going event-driven, it makes it way too easy to add new features.

Sound good?

Sign up to Sailhouse — it’s free! (while in beta). You should also check out our growing Discord community, and swing by the GitHub discussions to talk through bugs, feature requests and all fun software things.

Happy sailing!

Handle Stripe events in 2 minutes with Sailhouse

Ed Stephinson — Wed, 30 Aug 2023 21:30:26 +0000

Building products is hard, before you even touch the business side and start taking payments.

There comes a point in every product's cycle when you need to start processing payments. Simple, right? Except what usually happens is you end up with a half-finished implementation that just about gets you by while you try to focus on shipping the product features people are paying for.

Here’s where Sailhouse makes things ridiculously easy. Let’s dive into using Sailhouse to seamlessly and effortlessly handle Stripe events in a way that scales as your product does.

The Stripe integration

Sailhouse is a platform built on pragmatic decisions, and with that useful features. As part of our beta offering, we're building out a fully-fledged Stripe integration to make it even easier for you to get your product and payments off the ground.

Building a webhook to receive Stripe events itself is pretty straightforward, but the proper distribution — while maintaining verification — is a job for an events platform. Here’s where Sailhouse comes in.

Enabling the integration

Create a topic to receive your events, for example, stripe-events
Enable the Stripe integration by navigating to Apps > your-app > Integrations, and select your new stripe-events topic
Copy the endpoint provided, navigate to Stripe, and create a new Webhook, selecting all available events
Take the secret from Stripe, and save it in the Sailhouse integration settings to activate the endpoint

Now, every single event on Stripe is sent to and handled on Sailhouse.

Wait a minute, that's noisy, surely?

Ah-ha! You fell into our pricing trap. (Just kidding, the beta is currently free to use under our fair use policy 😉.)

But if you’d like to reduce the amount of events received — or drill down into what’s most important, Sailhouse has got you covered with Subscription Filters.

Instead of building custom logic to handle Stripe events, verify webhooks, and distribute that information in your code, you can add a subscription filter on your Stripe events — as with any other event on Sailhouse.

For example, you can create an invoice-paid subscription, which filters on Stripe event type for invoice.paid. You can also set up Slack notifications for any invoice.payment_failed events thanks to the Sailhouse Slack integration!

Handling Stripe events

You can handle your Stripe events in Sailhouse just like any other event. Here are some examples.

You could configure a push subscription:

subscriptions:
  - slug: invoice-paid
    topic: stripe-events
    type: push
    endpoint: https://acme-inc.com/api/invoice-paid
    filter:
      path: type
      value: invoice.paid

Or handle the event in your code.

const { events } = await client.getEvents("stripe-events", "customer-created");

for (const event of events) {
    // Do useful thing

    await event.ack();
}

Let us know what you’re building!

This is just the start of a whole suite of awesome integrations, and we can't wait to see what you make with them.

Come show off what you're building in the official Sailhouse Discord, or tag us on Twitter.

Happy Sailing!

Introducing Sailhouse, the easiest way to send events ⛵️

Ed Stephinson — Thu, 24 Aug 2023 21:42:11 +0000

Yes it's out, yes people are using it, but now it's time for it to say hello! 👋

Introducing, Sailhouse ⛵️!

Our mission and objectives

Sailhouse is pub sub on easy mode. No infra, no clusters, no regions, no sizing. Just events, topics and subscriptions.

Event-driven applications are a proven winner, Sailhouse is about making it as simple as possible to build them. With an intuitive CLI, powerful dashboard and slick integrations — you focus on building apps, we handle the plumbing.

It's all quite simple really — making complex, reliable, and performant applications as easy to build as possible.

Yes yes, big dreams, whatever.

The Sailhouse team

Sailhouse is being built by people with experience, and passion, for developer tooling. With experience at industry/category-defining developer-focused companies such as Netlify, we know how to build a strong offering.

Ed Stephinson, founder, tech lead of composable tooling at Netlify
Salma Alam-Naylor, advisor, former DX at Netlify, soon to be somewhere exciting 👀

Where are we now?

It’s a feature packed launch, but we’re in a great place to innovate.

You can use the CLI or dashboard to manage your whole events system. From creating topics in a flash with sailhouse topics create or managing the Stripe integration from the dashboard, it’s tooling focused on usecases, not implementation detail.

We’re focusing on our free-to-use beta. This is capped at 200 events a month (soft limit, with increasingly snarky emails the more you go over), while we fine tune what we’ve got.

It can handle scale too, there was one 24 hour period processing over 40,000 events without us even noticing.

We’ve got native SDKs for both Go and TypeScript (plus JavaScript, fear not), with more on the way.

What’s in store for the next 12 months

At a high level, here are our objectives for the next 12 months.

Rollout Sailhouse from Beta -> Stable
Build useful features, grounded in real-world uses
- Integrations are a key part of this
Introduce more SDKs
Focus on stability and performance
Rollout to more edge locations
Most importantly, build a rich, diverse and engaged community

Is Sailhouse Open Source?

Yes, kinda.

It's probable the core will always remain closed. That's both a business and practical decision. However, much like how Sentry have some of their services open-source, we may follow that route.

Go get started, like now, go!

Our docs are open source! If you'd like to contribute, PRs and issues are actively welcomed. We're also building a community on discord for more real-time interaction. Otherwise, our trusty GitHub Discussions board is the place to raise feature requests and more.