DEV Community: Christopher Ribeiro

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

From zero to production with Fastify

Christopher Ribeiro — Tue, 12 Sep 2023 13:00:00 +0000

When developing an application we often ask ourselves

Which framework should I use?

We know this question actually comes a lot in the JavaScript ecosystem.

In this post I show why at Dymme we chose Fastify as our back-end framework and how we use it.

The why

1. Fast by default:
Fastify kills at every benchmark see

2. Express like:
We can write code just like in the ol' Express days if we want to.

fastify.get('/', async function handler (request, reply) {
  return { hello: 'world' }
})

3. Configurable:
Fastify offers a plugin system just like Express. Plugins can modify Fastify or act in certain moments (when the server closes or the request is sent for example).
The chosen approach makes us write decoupled code.

Each plugin is independent. Meaning that they can't talk to each other directly.
All plugins talk to the Fastify instance directly, which itself is a plugin. And if a plugin wants to communicate with another it communicates via the Fastify instance.

fastify.decorate('db', new DbConnection())

fastify.get('/', async function (request, reply) {
  return { hello: await this.db.query('world') }
})

See that, we make the db plugin available for the whole instance. This makes possible to use this plugin directly from anywhere that has access to the Fastify instance.
In this case, our route handler has the Fastify instance by default and we can access it to call our db plugin without direct access to it.

And if you followed along, you may note that a route is also a plugin 🤯 that's how it can talk to the Fastify instance and use the db plugin added to it.

Take a look in:

4. TypeScript:

Yes it supports TypeScript, so you can have autocomplete (and make some guy want to remove it from your codebase).

The how

By now I may have convinced you that Fastify is the best Express alternative than others. But what about how we do it at Dymme?

Glad you asked!

Dymme is a Startup that enables merchants to sell their products in one click and shoppers to pay also in one click, instantly. As we deal with real time payments, we need to have an API that handles heavy traffic and be able to move quickly.

Fastify allows all that but if you start from scratch you may not perceive the difference from Express.
That's why we recommend you to start your application with the CLI.
It will not only bootstrap you application but will configure it to have TypeScript if you want.

The CLI will also setup your API to use filesystem routing (Yes, you heard that).

Take a look in this base template we are using internally.
We will update it in the future with better patterns, so stay tuned and give it a star!

Dymme.

5 things I learned as a junior Front-End developer

Christopher Ribeiro — Sat, 15 May 2021 17:34:47 +0000

I've been a Front-End developer for almost 5 years, always as a Freelancer. Until 2019. When I decided to work for other companies.

But this change made me realize a few things.

The Search

After a few days looking for jobs, I was contacted by a startup.
They offered me a challenge. I ended up finishing it in time.

The hiring process was fast. First a video call, one week later I was travelling to another state to be interviewed in their office to a final interview process. And they hired me. The felling was awesome!
Finally, in exactly two weeks since the first contact with them I was moving to another state to work on my first (non freelance) job.

I worked for them for one year. And I know that I wasn't a junior dev at the time. But that's how it works. And these are the things I learned:

1: Git is much more powerful than you think

Git is a powerful tool for version control, used by most of tech companies around the world. It's a requirement.

I always worked alone, so I never studied Git in depth.
In my mind, I never needed to learn it, because I thought I knew it.
But I was completely wrong.

Had days where I was hours trying to put back code that I have already written. Just because of tons of merge conflicts and me not being aware that Git follows a timeline. If my code wasn't synced with the branch that I was merging, my code would be overwritten with newer commits.

2: Front-End = Full-Stack

Yes, I thought that I was hired as a Front-End developer. But months later I was dealing with micro services, lambda functions, API updates, database management, CI/CD… And the list wont stop.

Actually I don't think that's a problem.
You're in a small team and you be all in contact with each other and make decisions together. That's a plus if you want to work in your communication skills.

The thing that concerns me the most is that startups do this because they want to spend less money. And sometimes this isn't a good idea.
If a developer is doing multiple tasks, probably, the result isn't the best.

And the money saved is going to cost time in the future.

3: It's okay to say "no"

Sometimes when we want to be the best, to do our best, we tend to say "yes" to every question, to every task that comes in hand.

Sometimes, as a junior developer, you're afraid to show that you don't know how to do it. Or you don't know how to calculate how much time a task you take to be done. And you end up saying:

"Yeah, I can do this until this afternoon".

But the problem is, if you agree with everything, you have to do everything.
You end up working on multiple tasks at the same time. And in the end of the day, managers don't want to know if you had a problem.
They just want to see it done.

If you say that you can't, or give the task one more day to be done, it's okay. You'll have more time to finish it, and do your best.

4: You code, they get famous

If you think that you'll get recognized for what you do while working for a company. I'm sorry to say that you wont. Or at least, not most part of the time.

The thing is, a developer is used as a tool. Instead of being the product. We are used as tools to give the company what they want:

Money.

And developers will never be recognized as the product.
Have you ever seen an Apple launch where a developer speaks about the product they made? Or this brand new XYZ autonomous self-driving car where the presenter isn't the CEO or a marketing person?

You may think I'm wrong, that developers do receive the credit they deserve.
But try pushing a bug to production and see if the CEO/marketing speakers will be held accountable for it.

5: Code is your wife, side project is your mistress

Sorry for the bad (and non inclusive) title.
But after working for 8+ hours every day, you end up tired and bored of the code you write. If a task take too long to complete, you end up with less and less energy to complete it.

It may not happen to every developer, but certainly when it happens, It's because you're tired. Your brain is tired.
There are a few things to reverse this:

Walk / run
Meditate
Sleep more

However. A side project comes more in hand.
Because you can't take a walk or a run after 7/8 PM. You come home, after commute, take a shower (i guess), eat and then you're so tired to even think straight.

You could meditate. This works most of the time, but try coding anything different. Seriously, try coding anything.
Any code that's different from what you see everyday, will make that joy, the focus reappear.

And even more, maybe a side project can become your own business?