Forem: Alertpix

Why we chose Bun

Christopher Ribeiro — Thu, 08 Feb 2024 12:39:31 +0000

At Alertpix we allow streamers to receive donations from their audience via Pix Instant Payment and show an alert on the live stream.

I was eyecatching Bun for a long time. And while developing the initial version of the platform the excitement to use it when it was more stable was really high.
And when 1.0 reached, I knew it, our real time system should be written in Bun.

No common js or esmodules madness

Our API is in node. And God, how I suffered to import nanoid in an esmodule project. I had to vendor it, since using a previous version was not ideal.
With bun, we can no longer worry about that. Just import what you need and done.

import fs from "node:fs"
const path = require("node:path")

TypeScript ou of the box

We all know that TS is just a linter, so we need it as the project grows right?
That feeling when the auto complete works, hits different.
But the struggle to setup TypeScript in nodejs is a pain.

Well, with Bun, its no longer an issue anymore. It just works.

Fast startup times

Oh boy, while developing Alertpix, I was relying solely on using cloud environments since my laptop was in repair.
I can count how many hours I wasted waiting node to sync the changes (I'm talking about you Next, you are slow even on high end machines) in these cloud enviroments. When switched to Bun, everything felt fast.

Buildless deployment

Our realtime service needs to be deployed as fast as possible.
It means that, the time to identify a bug in production, fix the issue, commit and run de CI deployment should be small.
And we know that, even cached, deployments are slow because of the build step. The bigger the project, the more time it takes.

Since bun runs TypeScript without a build step.
In summary, our container pulls Bun, install the packages, copies the needed files and runs the code with Bun:

FROM oven/bun

WORKDIR /app

COPY package.json .
COPY bun.lockb .

RUN bun install --production

COPY src src
COPY tsconfig.json .

ENV NODE_ENV production
CMD ["bun", "src/index.ts"]

EXPOSE 3000

Pub Sub is easier

Our real time system is a pub sub on top of websockets.
And it is so easy to do, that we already covered it in this post

Alertpix

Emoji Glitch Boosts Streamer's Earnings: Alertpix Bug Post-Mortem Analysis

Christopher Ribeiro — Sat, 20 Jan 2024 22:24:16 +0000

At Alertpix we allow streamers to receive donations from their audience via Pix Instant Payment and show an alert on the live stream.

Being an early-stage startup, we can easily stay close to our streamers. As usual, I was present when our first incident occurred. A donation with a single emoji made a streamer richer, and chaos erupted in our backend.

The live stream

RBQK, one of our initial streamers, had just started their livestream. After a few minutes, the first donation alert appeared.

While everything seemed fine, and the donation goals updated correctly after the first donation, a Discord message and a Rollbar email gave me chills.

An error 500 occurred after the second donation. I waited a few seconds to see if the alert would appear on the live stream.

Realizing it wouldn't show up, I started to feel anxious, and so did the donor.

Logs and monitoring

Since day one, we were committed to having robust monitoring. However, as we never had any incidents in the payment process, we didn't realize that the logs in this flow were not as comprehensive as intended.

The error log was not helpful:

TypeError: Cannot read properties of null (reading '0')\n at Filter.clean (/app/node_modules/bad-words/lib/badwords.js:58:41)

Obviously, we had the stack trace, and it pointed to the part of the code that verifies if the message for the streamer has sensitive words and applies a filter to it before creating the transaction and dispatching the donation alert:

  const isSensitive = fastify.badWords.isProfane(charge.comment)
  const redactedComment = fastify.badWords.clean(charge.comment)

This code uses the bad-words library as a Fastify plugin.

However, this made no sense to me. I became nervous as I saw the error reporting messages and emails repeating every few minutes or so

Webhooks and no conditional updates

As I received more of these alerts, I realized the payment processor was retrying the route until it received a 200 response.

I checked the database and found that the charge was marked as paid, but no transaction was registered. This meant that the payment processing part was executing every time the route was called and we can't show alerts if no transaction is registered.

However, I calmed down because we can't process a transaction if the charge has already been processed, right?

Actually, the biggest mistake was in this part of the code:

export async function paymentReceived(data: Data, fastify: Fastify) {
  const charge = await ChargeModel.findById(data.id)
  if (!charge) {
    return { error: 'Could not find related Charge' }
  }
  // ...
}

I felt so dumb when I realized that the second check should prevent processing the payment if the charge status was paid, but it wasn't there. So I rushed and added the check:

export async function paymentReceived(data: Data, fastify: Fastify) {
  const charge = await ChargeModel.findById(data.id)
  if (!charge) {
    return { error: 'Could not find related Charge' }
  }
  if (charge.status === 'paid') {
    return {
      data: {}
    }
  }
  // ...
}

I commited into main branch and waited. Bingo! The errors stopped.

An 🥰 emoji and no more chaos

With no more chaos happening, I investigated the donation more in depth to understand why the check for bad words have failed.

It seemed perfect: it was paid, the payment provider showed the transaction on their side, and it had all the required info:

amount
user name
comment

However, the comment was a: 🥰.
Yes, the string was only an emoji.

So I rushed to my console and ran:

const BadWords = require('bad-words')

const filter = new BadWords()
filter.clean("🥰")

And there it was! The console screamed the same error as before:

As it was late at night, I sent a message to the streamer in their DM and on the Twitch chat, apologizing, and called it a day.

At 6 AM the next day, I found the issue. The clean method for bad-words was trying to join a string when it had nothing to join back in. It splits the string and replaces the word if it is profane. But when it joins the word back in, it fails miserably because the regex returned null, and we cannot access index 0 of null.

  clean(string) {
    return string.split(this.splitRegex).map((word) => {
      return this.isProfane(word) ? this.replaceWord(word) : word;
    }).join(this.splitRegex.exec(string)[0]);
  }

It was clear to me: copy the code, fix it myself, and open a PR. So I did my implementation of the library in 5 minutes and tested against all comments we had in the database and then compared the isProfane status with my implementation.
Looks like the code is simple:

const filter = {
    isProfane(text) {
      return Boolean(badWords.find((word) => {
        const wordExp = new RegExp(`\\b${word.replace(/(\W)/g, '\\$1')}\\b`, 'gi');
        return wordExp.test(text)
      }))
    },
    clean(text) {
      return text
        .split(' ')
        .map((word) => this.isProfane(word) ? this.replaceWord(word) : word)
        .join(' ')
    },
    replaceWord(string) {
      return '*'.repeat(string.length)
    }
  }

Now I can use it just like before. The clean method can be written in a single line of code. I even added isProfane and replaceWord, which are simple to code as well.

After calling it quits, I deployed to production and after a week later, I have not seen any problems with a single emoji again. Of course, we still had to normalize the database.

No longer rich

Right away I ran the script to get the streamer wallet balance based on the transaction history. The user had 100 bucks more because the wehbook was called many times in a timespan of an hour.

So I normalized the wallet balance. And created the transaction based on the processed charge and also added the charge amount to the wallet balance.

The future and lessons learned

The primary part of running an MVP is to do the best you can with only a few features in hand. However, I don't think about scaling until we need to. Otherwise, we lose the time to market and get a well-optimized server for a hundred thousand concurrent users when we can't get our first paying customer.

For sure, we can't scale until we need to, but dealing with other people's money is dangerous. We know that; we had only one active streamer. However, what if we had five? Would we lose 500 bucks? How would we be able to handle such issues? So from now on, we have implemented the following measures to prevent incidents like that:

Better logging: We log more information to Rollbar, providing us with a small payload that shows what happened and what we need to know.
Conditional writes: After more testing, we are now certain that we can't modify an entity if it can't be modified based on its status.
Event-based: We've shifted most of the payment receiving processes to use queues. This way, if something goes wrong, we can fix the issue and resume from where it stopped.

Alertpix

Ditch REST, go intent based

Christopher Ribeiro — Fri, 05 Jan 2024 11:56:01 +0000

At Alertpix we allow streamers to receive donations from their audience via Pix Instant Payment and show an alert on the live stream.

Our API exclusively utilizes the GET and POST HTTP methods. We think that we can use native features as much as we can. We bring this inspiration from the <form> element which does not support form submissions PUT, PATCH, or DELETE methods.

In this article, we explore the reasons why your API might not require more than two request methods: GET and POST.

REST APIs

APIs are designed for machines to communicate with each other, and there are various standards when using HTTP. The most commonly used standard is REST, which provides a great pattern for constructing APIs. If we adhere to it, we end up with a RESTful API.

However, adhering to REST often compels us to write object-oriented code and use a variety of HTTP methods. While this isn't inherently problematic, one significant drawback is that we need to structure each route for each entity in the same way:

POST /book
GET /book/:id
DELETE /book/:id
PUT /book/:id
PATCH /book/:id

If we want to add another domain we certainly will use the same route structure for it:

POST /author
GET /author/:id
DELETE /author/:id
PUT /author/:id
PATCH /author/:id

What if we need to get a book by an author? How should we do it?

GET /books/:id/author/:id

GET /author/:id/books/:id

In all honesty, it's not a matter of whether it's readable or understandable; it's about the need for such complexity in the first place.

APIs are for humans

While APIs are intended for machines to consume, they are designed and utilized by humans. Human developers read the documentation and test the integration, so there's no need for excessive complexity in HTTP endpoints. Instead, we can focus on making the API more intent-based.

Going Intent-Based

Now that we understand that most of the time the integration will be done by humans. We can make it as swift as possible.

The previous example to get a book by an author can be done this way:

GET /books/by-author/:id

If you literally remove the special characters, you can read it just like an English sentence:

GET books by author id

This shift towards an intent-based approach can make API usage more intuitive and user-friendly.

Going beyond

If we want to create, edit or delete an entity, we can easily have different endpoints for that just like this:

POST /books/create {...}
POST /books/edit/:id {...}
POST /books/delete/:id

If we where in REST, editing and deleting whould be a mess. And we all know that, we often forget the difference between PATCH and PUT.

By going intent based we make our APIs more human readable.
This pattern is presented in our APIs and micro services so integration is always a breeze.

Alertpix

Going real time with donation alerts

Christopher Ribeiro — Fri, 20 Oct 2023 19:34:44 +0000

At Alertpix we allow streamers to receive donations from their audience via Pix Instant Payment and show an alert on the live stream.

This post shows how donation alerts feature was coded in just a day.

Notification widget

Our users can use their Streamlabs account to use their own alert box in the live stream.
However, we also have users that don't use Streamlabs, that's where the Notification widget comes in.

The PubSub

The ideia was simple: each widget listens into a topic and receives a new alert to show when its not showing any alerts.

This new service was bootstrapped with Elysia, the fastest Bun framework.

Now, to create a new http server is just as simple as:



const app = new Elysia()

Now we need to allow for widget to connect via WebSockets:



app
  .use(ws())
  .ws('/ws', {
    body: t.Object({ ... }),
    query: t.Object({ ... }),
    open(ws) {},
    close(ws) {},
    message(ws, message) {},
  })

Here is where the tech stack shines. We can allow WebSocket connections, add schema validation to their messages and request params.
We can also create a pub sub mechanism with a built-in API in bun.

This can be done in a line of code when the socket connects:



open(ws) {
  // ...
  ws.subscribe(id)
  free[id] = true
}

We also stored the widget in a free list. Meaning that the widget is not currently showing any alerts.

When the peer disconnects, we remove it from the list:



close(ws) {
  // ...
  delete free[id]
}

The widget can send a message telling that its free, so we handle that as well.
We check if the topic has items so we send the next alert, if any. Tagging it as free or not:



message(ws) {
  // ...
  const value = await redis.lRange(id, 0, 0);
  if (!value[0]) {
    free[id] = true
    return
  }

  await redis.lPop(id);

  free[id] = false
  app.server.publish(id, value[0])
}

Posting a donation

We updated our API to store the notification in the queue and publish to the notifying service via an API call:



export function donationReceived(context: Context, donation: Donation) {
  // ...

  context.redis.rPush(context.receiver, donation)
  notifyWidget({ topic: context.receiver, donation })

  // ...
}

API call that we defined with the same logic to notify the connected peers if they are free:



post("/publish", async ({ body }) => {
  if (free[body.receiver] === false) {
    return
  }

  const value = await client.lRange(body.receiver, 0, 0);
  await client.lPop(body.receiver);

  free[body.receiver] = false
  app.server!.publish(body.receiver, value[0])
})

What we learned:

Choosing the right tech stack helps a lot. But knowing about the topic and understanding what is needed to build the feature, we can build things pretty fast. In this post we show how at Alertpix we code each feature in one hour.

Since we launched we improve every day a little bit. Of course, today the implementation is pretty much different than this. But this blog aims to illustrate how you can write a pub sub without fighting against the code.

Take a look in the code exampls if it where a complete code so you can try it yourself:



import { Elysia } from "elysia"
import { cors } from '@elysiajs/cors'
import { createClient } from 'redis'

const free: Record<string, boolean> = {}

const client = await createClient({
  url: process.env.REDIS_URL,
  password: process.env.REDIS_PASSWORD,
})
  .on('error', err => console.log('Redis Client Error', err))
  .connect();

const app = new Elysia()
  .use(cors())
  .ws('/ws', {
    open(ws) {
      const id = ws.data.query.id

      ws.subscribe(id)
      free[id] = true
    },
    close(ws) {
      const id = ws.data.query.id

      delete free[id]
    },
    async message(ws, message) {
      const id = ws.data.query.id

      const value = await client.lRange(id, 0, 0);
      if (!value[0]) {
        free[id] = message.free
      }

      await client.lPop(id);

      free[id] = false
      app.server!.publish(id, value[0])
    },
  })
  .post("/publish", async ({ body }) => {
    if (free[body.receiver] === false) {
      return
    }

    const value = await client.lRange(body.receiver, 0, 0);
    await client.lPop(body.receiver);

    free[body.receiver] = false
    app.server!.publish(body.receiver, value[0])
  })
  .listen(process.env.PORT || "8080");

console.log(
  `🦊 Elysia is running at ${app.server?.hostname}:${app.server?.port}`
)

Alertpix

1 hour features

Christopher Ribeiro — Mon, 16 Oct 2023 12:28:57 +0000

At Alertpix we allow streamers to receive donations from their audience via Pix Instant Payment and show an alert on the live stream.

The whole product deals with real time, which means we need to ship features as fast as possible.

1 hour max

As engineers we are used to long development and deployment processes:

create feature branch
code
write tests
push code
open PR
wait for automated tests
wait for review
wait deploy to beta/stating env
wait validation
create PR to prod
wait for automated tests
wait for review
wait deploy to production

We are used to something like this. Having a separate development environment and a production one (some companies has more environments than this). Also needing to follow git flow and wait for peers and CI to do their job.

But I think all these can be not only reduced but take 1 hour max.
Anything after that, means you are stuck into a problem or your feature is too big.

Research First: 20 minutes

The first 20 minutes should be dedicated solely for research. But if you already have some knowledge of what you're building, you can do it in less time.

The ideia here is to give some time to understand what you need to build, how to do it and the most important: how to code it in the next 40 minutes.

This step can't be skipped, even if you know the concepts. Because we should understand things before doing.

Now Code: 20 minutes

After the research process, its time to code the solution.

Don't over engineer.

Your solution should be simple and each piece of code should do one thing and one thing only.

Don't write tests or docs, just code the first version. It won't be perfect the first time, so do what works and move on to the next step.

Now Test: 20 minutes

Finally, you've reached the test phase. If you are a startup in the MVP or pre PMF phase you can skip this step and earn more 20 mins to code another feature.

But if you want to write tests, now is the time to do it.
We know that TDD tells us to write the tests before we write the code. But lets be real:

You only know what you will code while you are coding.

Tests come in last because you can test while you code. This phase is more if you need to have them to pass CI or a code review.
Also if you add tests, you garantee that you coded something that works.

At Alertpix this framework has been applied since day one, and every day we improve the product without having to wait.

Alertpix