DEV Community: Filipi Youssef

I built a pay-per-use video transcription tool with Next.js and Whisper — here's the full breakdown

Filipi Youssef — Thu, 26 Mar 2026 23:22:58 +0000

Why I built this

I kept running into the same frustration: I had a video file and I needed the text inside it.

The available options were either too manual (typing it yourself), too unreliable (YouTube auto-captions), or too expensive for occasional use (most transcription SaaS tools charge a flat monthly fee regardless of how much you actually transcribe).

So I built Tonivox — a web app that accepts a video file, extracts the audio, runs it through a transcription model, and returns the full text. Pay per transcription, no subscription.

This post covers the technical decisions, the problems I ran into, and what I'd do differently.

The stack

Next.js 15 (App Router) — frontend and API routes
Prisma + PostgreSQL — data layer
Better Auth — authentication (email/password + email verification)
Stripe — credit purchases via Checkout Sessions
OpenAI Whisper — transcription model
FFmpeg — audio extraction from video files
Tailwind CSS — styling

How it works

The flow is straightforward:

User uploads a video file (MP4, MOV, AVI, WebM — up to 60 min / 25 MB)
The server extracts the audio track using FFmpeg
The audio is sent to Whisper via the OpenAI API
The transcription is returned and stored
One credit is deducted atomically from the user's balance

The credit model: users buy credits upfront (three tiers, $0.99 to $6.99). Each transcription costs one credit. No monthly commitment.

The problems

FFmpeg on serverless

Running FFmpeg in a serverless environment is not as simple as npm install ffmpeg. You need a static binary compatible with the runtime's OS. I ended up using @ffmpeg-installer/ffmpeg and validating that the binary path was actually accessible at runtime — something that failed silently in a few deployment configurations before I caught it.

File size and timeouts

Serverless functions have timeout limits. A 60-minute video file takes time to process, and the default limits on most platforms are not built for that. I moved the heavy processing (audio extraction + Whisper API call) to a dedicated background worker. The API route just enqueues the job and the client polls for status.

This also meant I had to handle the "queued" and "processing" states in the UI, which added complexity but made the experience significantly more reliable.

Atomic credit deduction

I wanted to make sure credits were never deducted if the transcription failed, and never skipped if it succeeded. I handled this with a database transaction that wraps the Whisper API call result — if the API throws, the transaction rolls back and the credit is preserved.

Portuguese accuracy

Most transcription tools are tuned for English. Whisper handles Portuguese well out of the box, but the language detection needs to be explicit — if you don't specify the language, it can misidentify short clips and produce garbage output. I pass language: "pt" or language: "en" based on a user preference stored at account level.

What I deliberately left out

I made a list of features I wanted but decided not to ship in v1:

Speaker diarization (who said what)
Word-level timestamps
SRT/VTT subtitle export
Audio-only file support (MP3, WAV)
Live recording

Each of these is buildable. I left them out because I wanted to test whether the core loop — upload a video, get text — was something people actually paid for before investing more time.

What I'd do differently

Start with the worker architecture from day one. I initially built the transcription as a synchronous API call. Refactoring to async/poll later was more work than just building it right the first time would have been.

Set up error observability earlier. For the first few weeks I was flying blind on server-side failures. Adding structured logging and an alerting channel earlier would have saved me from discovering bugs through confused users instead of dashboards.

Spend less time on the landing page, more time talking to potential users. I polished the UI for longer than I should have before showing it to anyone. The feedback I got in the first 48 hours after launch pointed to things I never would have caught by looking at my own code.

Where it stands now

The app is live at tonivox.com. It supports English and Portuguese. The codebase is a few thousand lines, built and maintained solo.

If you're working on something similar — pay-per-use SaaS, file processing on serverless, or Whisper integration — happy to answer questions in the comments.

And if you work with video or audio professionally and want to try it, I'm actively looking for feedback on what's missing or broken.

How to Debug Webhooks Without Headaches: The Webhook Monitor Every Developer Needs

Filipi Youssef — Sat, 21 Jun 2025 12:41:04 +0000

If you've ever worked with webhooks, you know that debugging these requests can be a real nightmare. Between setting up ngrok, analyzing server logs, and trying to understand why that integration isn't working, we lose precious hours that could be invested in actual code.

The Problem Every Developer Knows

Picture this scenario: you're integrating with an external API that sends webhooks to your system. Everything looks right in the code, but... nothing happens. The burning question:

"Is the data coming through? What's the format? Why isn't it working?"

Sound familiar? That's where Webhook Monitor comes in - a tool that changed my way of working with webhooks.

The Simple Solution That Works

Webhook Monitor solves this problem elegantly:

Access the website
Copy your unique URL (automatically generated)
Configure it in your webhooks
Watch the data arrive in real-time

That simple. No installation, no complicated configuration, no own server needed.

Real-World Use Cases

1. Testing Payment Integrations

// Example: Setting up Stripe webhook
const stripe = require("stripe")("sk_test_...");

// Your Webhook Monitor URL
const webhookUrl = "https://webhookmonitor.online/webhook/abc123...";

// Now you can see exactly what Stripe is sending

2. Debugging GitHub Webhooks

# .github/workflows/webhook-test.yml
name: Test Webhook
on:
  push:
    branches: [main]

jobs:
  notify:
    runs-on: ubuntu-latest
    steps:
      - name: Send webhook
        run: |
          curl -X POST https://webhookmonitor.online/webhook/your-id \
            -H "Content-Type: application/json" \
            -d '{"event": "push", "branch": "${{ github.ref }}"}'

3. Monitoring CRM Events

import requests
import json

# Simulating a webhook from your CRM
webhook_data = {
    "event": "lead_created",
    "lead": {
        "id": 12345,
        "email": "user@example.com",
        "source": "website"
    },
    "timestamp": "2024-01-15T10:30:00Z"
}

# Sending to Webhook Monitor
response = requests.post(
    "https://webhookmonitor.online/webhook/your-unique-id",
    json=webhook_data,
    headers={"Content-Type": "application/json"}
)

print(f"Status: {response.status_code}")

Advantages That Make the Difference

Real-Time

See data arrive instantly. No refresh, no delays.

Zero Configuration

No need to set up servers, ngrok, or any infrastructure.

Complete Analysis

See headers, body, HTTP method, timestamp - everything you need.

Free

Works without registration, no annoying limits for development.

Any Language

PHP, Python, Node.js, Go, Java - works with any stack.

Practical Usage Examples

Testing Webhook with cURL

# Basic test
curl -X POST https://webhookmonitor.online/webhook/your-id \
  -H "Content-Type: application/json" \
  -d '{"test": "hello world"}'

# Test with custom headers
curl -X POST https://webhookmonitor.online/webhook/your-id \
  -H "Content-Type: application/json" \
  -H "X-Custom-Header: my-value" \
  -d '{
    "event": "order_completed",
    "order_id": 12345,
    "total": 99.99
  }'

Integrating with Node.js

const express = require("express");
const axios = require("axios");
const app = express();

app.use(express.json());

// Webhook Monitor URL
const WEBHOOK_MONITOR = "https://webhookmonitor.online/webhook/your-id";

app.post("/api/orders", async (req, res) => {
  const order = req.body;

  // Process order...

  // Send webhook for monitoring
  try {
    await axios.post(WEBHOOK_MONITOR, {
      event: "new_order",
      order: order,
      timestamp: new Date().toISOString(),
    });

    console.log("Webhook sent to monitor");
  } catch (error) {
    console.error("Error sending webhook:", error.message);
  }

  res.json({ success: true });
});

app.listen(3000);

Testing with Python

import requests
import json
from datetime import datetime

class WebhookTester:
    def __init__(self, monitor_url):
        self.monitor_url = monitor_url

    def send_test_event(self, event_type, data):
        payload = {
            "event": event_type,
            "data": data,
            "timestamp": datetime.now().isoformat(),
            "source": "webhook_tester"
        }

        try:
            response = requests.post(
                self.monitor_url,
                json=payload,
                headers={
                    "Content-Type": "application/json",
                    "User-Agent": "WebhookTester/1.0"
                }
            )

            print(f"Webhook sent: {response.status_code}")
            return response.status_code == 200

        except Exception as e:
            print(f"Error: {e}")
            return False

# Usage
tester = WebhookTester("https://webhookmonitor.online/webhook/your-id")

# Test different scenarios
tester.send_test_event("user_signup", {"user_id": 123, "email": "test@example.com"})
tester.send_test_event("payment_success", {"amount": 50.00, "currency": "USD"})
tester.send_test_event("error_occurred", {"error": "Database connection failed"})

Advanced Use Cases

1. Testing Rate Limiting

#!/bin/bash
# Script to test behavior with multiple requests

WEBHOOK_URL="https://webhookmonitor.online/webhook/your-id"

for i in {1..10}; do
  curl -X POST $WEBHOOK_URL \
    -H "Content-Type: application/json" \
    -d "{\"request_number\": $i, \"timestamp\": \"$(date -u +%Y-%m-%dT%H:%M:%SZ)\"}" &
done

wait
echo "All requests sent!"

2. Simulating E-commerce Webhooks

// E-commerce event simulator
const events = [
  { type: "cart_abandoned", data: { cart_id: "cart_123", items: 3 } },
  { type: "order_placed", data: { order_id: "ord_456", total: 199.99 } },
  {
    type: "payment_processed",
    data: { payment_id: "pay_789", status: "success" },
  },
  {
    type: "order_shipped",
    data: { tracking: "US123456789", carrier: "FedEx" },
  },
];

async function simulateEcommerceFlow() {
  const webhookUrl = "https://webhookmonitor.online/webhook/your-id";

  for (const event of events) {
    await fetch(webhookUrl, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        ...event,
        timestamp: new Date().toISOString(),
        user_id: "user_123",
      }),
    });

    // Wait 2 seconds between events
    await new Promise((resolve) => setTimeout(resolve, 2000));
  }
}

simulateEcommerceFlow();

Pro Tips for Using Webhook Monitor

Tip 1: Organize Your Tests

{
  "test_id": "integration_test_001",
  "environment": "development",
  "service": "payment_gateway",
  "event": "payment_completed",
  "data": {
    "amount": 100.0,
    "currency": "USD"
  }
}

Tip 2: Use Headers for Context

curl -X POST https://webhookmonitor.online/webhook/your-id \
  -H "X-Test-Case: user-registration" \
  -H "X-Environment: staging" \
  -H "X-Version: v2.1" \
  -d '{"user_id": 123}'

Tip 3: Test Different Content-Types

# JSON
curl -X POST https://webhookmonitor.online/webhook/your-id \
  -H "Content-Type: application/json" \
  -d '{"key": "value"}'

# Form data
curl -X POST https://webhookmonitor.online/webhook/your-id \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d 'key=value&another=data'

# XML
curl -X POST https://webhookmonitor.online/webhook/your-id \
  -H "Content-Type: application/xml" \
  -d '<payload><key>value</key></payload>'

Comparison with Other Tools

Tool	Setup	Real-Time	Free	Limits
Webhook Monitor	✅ Zero config	✅ Yes	✅ Yes	✅ No dev limits
ngrok	❌ Install + config	✅ Yes	⚠️ Limited	❌ Temporary URLs
RequestBin	✅ Simple	⚠️ No	✅ Yes	❌ Expires in 48h
Webhook.site	✅ Simple	✅ Yes	⚠️ Limited	❌ Public

Conclusion

Webhook Monitor dramatically simplifies the webhook development and debugging process. No complex configuration, no installation, no headaches.

For developers who want to:

Test integrations quickly
Debug webhooks in real-time
Validate payloads without infrastructure
Focus on code, not configuration

Try It Now

Visit: webhookmonitor.online
Copy your unique URL
Make your first request
Watch the magic happen

Loved the tool? Share it with your team and help other devs save time!

Have any feature requests? Leave them in the comments - I love community feedback!

🚀 Aprendendo na Prática: Criando uma API com NestJS, Docker e Observabilidade

Filipi Youssef — Wed, 28 May 2025 00:05:22 +0000

Olá, comunidade tech! 👋
Compartilho um projeto que desenvolvi para dominar conceitos avançados como escalabilidade, observabilidade e DevOps — habilidades críticas para ambientes de alto volume. O objetivo era criar uma estrutura pronta para produção, mesmo em cenários simples, usando ferramentas adotadas por grande grande parte da comunidade.

🛠️ O que você vai encontrar nesse projeto?

Esse projeto combina ferramentas que são muito usadas no mercado e ajudam tanto no desenvolvimento quanto na manutenção:

NestJS → Framework Node.js com padrão modular e testável
Knex.js → Para lidar com banco de dados de forma flexível
PostgreSQL → Banco de dados relacional
Redis → Usado como cache para performance
Docker + Docker Compose → Para rodar tudo localmente de forma padronizada
Traefik → Balanceamento de carga entre múltiplas instâncias
OpenTelemetry + Jaeger → Para rastrear o caminho de cada requisição na aplicação

🧠 Como o projeto funciona?

Essa aplicação permite cadastrar e listar heróis fictícios — algo simples. Mas o principal foco está em como toda a estrutura foi montada para ser observável, leve e pronta para escalar.

A aplicação roda em mais de uma instância ao mesmo tempo
O Traefik divide as requisições entre essas instâncias
Cada requisição é monitorada desde o início até a resposta final
Todos os dados do rastreamento podem ser vistos em uma interface chamada Jaeger

🧪 Ambiente de Desenvolvimento com Docker

Para facilitar o desenvolvimento local com hot reload e dependências controladas, usei um Dockerfile simples e direto, feito para rodar a aplicação NestJS dentro de um container com suporte ao modo de desenvolvimento:

# Etapa única: Ambiente de desenvolvimento
FROM node:20-alpine

# Define a pasta de trabalho dentro do container
WORKDIR /app

# Ativa o Corepack e configura o pnpm
RUN corepack enable && corepack prepare pnpm@latest --activate

# Copia os arquivos de dependências primeiro para aproveitar cache
COPY pnpm-lock.yaml* package.json* ./

# Instala as dependências do projeto
RUN pnpm install

# Copia o restante da aplicação
COPY . .

# Expõe a porta padrão da aplicação NestJS
EXPOSE 3000

# Inicia a aplicação em modo desenvolvimento com hot reload
CMD ["pnpm", "start:dev"]

Esse arquivo foi feito com foco em:

✅ Facilidade de uso: com apenas um comando (docker compose up), já é possível começar a desenvolver.
✅ Padronização do ambiente: todo o time trabalha com a mesma versão de Node, pnpm e dependências.
✅ Hot reload automático: ao salvar um arquivo, o servidor reinicia sozinho.
✅ Performance: base em Alpine Linux e uso de pnpm, que é leve e rápido.

Essa abordagem é ideal para quem quer começar a usar Docker no dia a dia sem complicação, mas ainda sim mantendo boas práticas como uso de cache e estrutura limpa.

🐳 Multi-Stage Builds

Usei um Dockerfile com duas etapas para garantir que o ambiente de produção só tenha o necessário. Isso deixa a imagem menor, mais rápida e segura:

# Etapa 1: Construção com todas as dependências de desenvolvimento
FROM node:20-alpine AS builder
WORKDIR /app
COPY pnpm-lock.yaml package.json ./
RUN corepack enable && corepack prepare pnpm@latest --activate && \
    pnpm install --frozen-lockfile
COPY . .
RUN pnpm build

# Etapa 2: Imagem final apenas com o necessário
FROM node:20-alpine AS production
WORKDIR /app
ENV NODE_ENV=production
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
EXPOSE 3000

Esse modelo separa a fase de desenvolvimento da produção e é muito usado em ambientes reais.

Claro! Aqui está uma seção do post que explica, de forma simples e objetiva, o que está sendo feito nesse trecho de código TypeScript relacionado à instrumentação e observabilidade com OpenTelemetry, mantendo o mesmo estilo do restante do post:

🔍 Instrumentação Automática com OpenTelemetry

Para rastrear as requisições de forma automática, configurei o OpenTelemetry diretamente na aplicação, permitindo capturar informações valiosas sem precisar instrumentar manualmente cada trecho do código.

Abaixo está a configuração feita no projeto:

import { FastifyOtelInstrumentation } from '@fastify/otel';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { HttpInstrumentation } from '@opentelemetry/instrumentation-http';
import { NodeSDK } from '@opentelemetry/sdk-node';

const sdk = new NodeSDK({
  serviceName: 'heroes-api',
  traceExporter: new OTLPTraceExporter({
    url: process.env.TRACE_EXPORTER_URL,
  }),
  instrumentations: [
    getNodeAutoInstrumentations(),
    new HttpInstrumentation(),
    new FastifyOtelInstrumentation({
      servername: 'fastify-heroes-api',
      registerOnInitialization: true,
    }),
  ],
});

🧠 O que está acontecendo aqui?

NodeSDK: Inicializa o SDK principal do OpenTelemetry no Node.js.
traceExporter: Define o destino dos dados de rastreamento. Neste caso, eles são enviados via HTTP para o coletor (Jaeger).
instrumentations: Aqui ativamos três instrumentações:
- Auto Instrumentations: Captura automaticamente métricas de bibliotecas populares como Express, pg, etc.
- HTTP Instrumentation: Foca especificamente em requisições HTTP.
- Fastify Instrumentation: Adiciona suporte específico para o framework Fastify usado pelo NestJS internamente.

🛑 Encerramento com segurança

process.on('SIGTERM', () => {
  sdk.shutdown().then(() => {
    console.log('SDK shut down successfully');
    process.exit(0);
  });
});

Esse trecho garante que, ao encerrar a aplicação, o SDK finalize corretamente as tarefas e envie todos os dados de tracing antes de desligar — prática importante em ambientes reais.

🧭 Inicialização do Tracing

export const initTrace = () => {
  sdk.start();
};

Por fim, exportamos a função initTrace para que o tracing possa ser iniciado assim que a aplicação subir, no caso dessa aplicação, sera iniciado dentro da função bootstrap() no arquivo main.js.

Com essa configuração, cada requisição que passa pela API é automaticamente monitorada, criando spans que podem ser visualizados na interface do Jaeger. Isso permite entender melhor o comportamento da aplicação, identificar gargalos e observar a relação entre os serviços.

Essa é uma das formas mais poderosas de trazer observabilidade para dentro da sua stack sem adicionar complexidade no código principal da aplicação.

⚙️ Orquestração Local com Docker Compose + Traefik

Para simular um ambiente de produção diretamente no seu ambiente de desenvolvimento, usei o Docker Compose com múltiplos serviços rodando em containers. Essa abordagem permite testar balanceamento de carga, limites de recursos e observabilidade de forma realista — tudo localmente.

Abaixo está uma parte do docker-compose.yml com os principais serviços:

🧱 `app` e `app2`: instâncias da aplicação

app: &app
  build:
    dockerfile: Dockerfile.dev
  container_name: app1
  volumes:
    - .:/app
    - /app/node_modules
  ports:
    - 3000:3000
  mem_limit: 1g
  cpus: 0.5
  depends_on:
    - db
    - redis
  environment:
    - NODE_ENV=development
    - DATABASE_URL=postgresql://root:root@db:5432/app?schema=fyoussef
    - REDIS_URL=redis://redis:6379
    - TRACE_EXPORTER_URL=http://otel-collector:4318/v1/traces
  networks:
    - fyoussef
  labels:
    - 'traefik.enable=true'
    - 'traefik.http.routers.app.rule=Host(`localhost`)'
    - 'traefik.http.routers.app.entrypoints=web'
    - 'traefik.http.services.app.loadbalancer.server.port=3000'

app2:
  <<: *app
  container_name: app2
  ports:
    - 3001:3000

O que está sendo feito aqui:

app e app2 são duas instâncias da mesma aplicação, permitindo testar escalabilidade horizontal e load balancing com o Traefik.
Volumes: o código local é montado no container (.:/app), garantindo atualizações em tempo real. O node_modules local é ignorado para evitar conflitos.
Recursos controlados: limitamos memória (1g) e CPU (0.5), permitindo estudar o comportamento sob diferentes condições de carga.
Variáveis de ambiente definem conexões com PostgreSQL, Redis e o coletor OpenTelemetry.
Traefik Labels configuram o roteamento: ele reconhece o container, escuta requisições para localhost, e encaminha para a porta interna 3000.

🌐 `traefik`: proxy reverso e balanceador de carga

traefik:
  image: traefik:v3.0
  container_name: traefik
  command:
    - '--api.dashboard=true'
    - '--api.insecure=true'
    - '--providers.docker=true'
    - '--providers.docker.exposedbydefault=false'
    - '--entrypoints.web.address=:80'
    - '--log.level=DEBUG'
    - '--accesslog=true'
    - '--accesslog.fields.defaultmode=keep'
  ports:
    - '80:80'
    - '8080:8080'
  volumes:
    - /var/run/docker.sock:/var/run/docker.sock:ro
  networks:
    - fyoussef

O que está sendo feito aqui:

Traefik atua como proxy reverso e balanceador de carga, distribuindo requisições entre app1 e app2.
Painel de controle acessível em http://localhost:8080, mostra os serviços ativos e como o tráfego está sendo roteado.
Configuração dinâmica via Docker: o Traefik lê as labels definidas em cada container e se autoconfigura.
Logs ativados: tanto logs internos (log.level=DEBUG) quanto de acesso HTTP (accesslog=true) para facilitar a depuração.

🧪 Resultado prático

Esse setup cria uma simulação realista de ambiente de produção com múltiplas instâncias da API, proxy reverso, limites de recurso e observabilidade ativa — tudo pronto para testar localmente, sem precisar de Kubernetes.

👉 Testar esse cenário localmente permite entender como a aplicação se comporta em ambientes escaláveis, e também facilita a identificação de gargalos de performance.

🧩 O que você pode aprender com esse projeto?

Mesmo que você esteja começando, esse projeto pode te ensinar bastante:

Como usar Docker de forma eficiente
Como fazer uma API que já vem pronta para escalar
Como aplicar observabilidade desde o início
Como montar um ambiente local que imita produção

💡 Quer testar?

Clone o repositório e suba o ambiente com um único comando:

git clone https://github.com/fyoussef/heroes-api.git
cd heroes-api
docker compose up --build

# Teste de carga (requer Node):
npx autocannon -c 100 -d 20 http://localhost/api/heroes

Acesse:

API: http://localhost
Traefik Dashboard: http://localhost:8080
Jaeger (para ver os rastreamentos): http://localhost:16686

DEV Community: Filipi Youssef

I built a pay-per-use video transcription tool with Next.js and Whisper — here's the full breakdown

Why I built this

The stack

How it works

The problems

What I deliberately left out

What I'd do differently

Where it stands now

How to Debug Webhooks Without Headaches: The Webhook Monitor Every Developer Needs

The Problem Every Developer Knows

The Simple Solution That Works

Real-World Use Cases

1. Testing Payment Integrations

2. Debugging GitHub Webhooks

3. Monitoring CRM Events

Advantages That Make the Difference

Real-Time

Zero Configuration

Complete Analysis

Free

Any Language

Practical Usage Examples

Testing Webhook with cURL

Integrating with Node.js

Testing with Python

Advanced Use Cases

1. Testing Rate Limiting

2. Simulating E-commerce Webhooks

Pro Tips for Using Webhook Monitor

Tip 1: Organize Your Tests

Tip 2: Use Headers for Context

Tip 3: Test Different Content-Types

Comparison with Other Tools

Conclusion

Try It Now

🚀 Aprendendo na Prática: Criando uma API com NestJS, Docker e Observabilidade

🛠️ O que você vai encontrar nesse projeto?

🧠 Como o projeto funciona?

🧪 Ambiente de Desenvolvimento com Docker

🐳 Multi-Stage Builds

🔍 Instrumentação Automática com OpenTelemetry

🧠 O que está acontecendo aqui?

🛑 Encerramento com segurança

🧭 Inicialização do Tracing

⚙️ Orquestração Local com Docker Compose + Traefik

🧱 app e app2: instâncias da aplicação

O que está sendo feito aqui:

🌐 traefik: proxy reverso e balanceador de carga

O que está sendo feito aqui:

🧪 Resultado prático

🧩 O que você pode aprender com esse projeto?

💡 Quer testar?

🧱 `app` e `app2`: instâncias da aplicação

🌐 `traefik`: proxy reverso e balanceador de carga