Forem: Víctor Villalobos

Why we rebuilt our own messaging stack for AI apps

Víctor Villalobos — Wed, 24 Dec 2025 02:30:27 +0000

Why we rebuilt our messaging stack for AI apps

Earlier this year, while building Nely.ai, other developers started asking to use our internal messaging API. What we had built to support our own product was solving problems they were also facing, especially around WhatsApp, pricing, and operational complexity.

At first, exposing the API seemed like the obvious next step. But very quickly, it became clear that the problem was not access. The problem was the CPaaS model itself.

AI apps changed how messaging is used

Traditional messaging platforms were designed for human-driven communication. One user sends one message at a time. Pricing, APIs, and tooling evolved around that assumption.

AI apps do not work this way.

Conversations are generated, routed, retried, and managed automatically by agents and workflows. A single user interaction can trigger multiple background messages, retries, classifications, or follow ups. Messaging becomes part of an execution graph, not a single action.

Most CPaaS stacks were not designed for this model, especially when pricing is tied to per message usage and fragmented providers.

Pricing breaks first

When AI agents are involved, per message pricing becomes unpredictable very quickly. Messages are no longer a proxy for value. Many of them are internal, transient, or part of automation logic.

What actually matters is how many users your system is actively serving and the underlying carrier costs required to deliver those messages.

This is why we moved away from raw message counting and rebuilt pricing around MAU combined with transparent carrier pass through. This model aligns much better with how AI apps scale and makes costs easier to understand and forecast.

Automation needs fast access to channels

When you automate communication with AI, you usually do not care about providers or setup steps. You just want access to the channels your users already use.

In many cases, that means WhatsApp or SMS, and that requires a phone number. Getting that number should be fast, simple, and predictable. Waiting days, dealing with external vendors, or navigating fragmented dashboards breaks development flow and slows down experimentation.

We made phone number provisioning a first class part of the platform. Developers can get an API key, provision a number, and start sending messages in minutes. Everything works together by default, so teams can focus on building AI workflows instead of wiring infrastructure.

Rebuilding the developer experience

Modern developer workflows expect clean abstractions, strong typing, and predictable behavior. Messaging APIs, especially WhatsApp, are often fragmented, inconsistent, and hard to reason about.

We rebuilt the developer experience from scratch with modern SDKs and simpler primitives. The goal was to abstract away provider specific quirks and expose a consistent interface that fits naturally into AI driven systems.

Instead of adapting AI workflows to legacy CPaaS constraints, we designed the messaging layer around how AI apps are actually built today.

What this enables

Rebuilding the stack enabled faster iteration, cleaner architectures, and messaging that no longer feels like a bottleneck. Teams can focus on agents, workflows, and product logic instead of pricing surprises and provider management.

This work became Zavu, a unified messaging API designed for AI apps and modern communication SaaS.

You can learn more at https://zavu.dev and explore the documentation at https://docs.zavu.dev.

If you are building AI driven products and have struggled with CPaaS complexity, pricing, or developer experience, we would love to hear what has broken for you.

Testing Django Rest Framework, la forma correcta

Víctor Villalobos — Wed, 07 Aug 2019 00:16:51 +0000

Post originalmente publicado en:

https://pythonist.dev/articles/testing-django-drf-manera-correcta/

Como desarrolladores django es común tener que testear DRF, pero no siempre lo hacemos de manera correcta, terminamos por crear tests unitarios lentos, no aislados, que nos dificulta encontrar errores y mantener un coverage alto, en este post tratare de explicar de manera fácil

como testear utilizando pytest como reemplazo a la librería por defecto
de django. Durante todo el proceso, usare las siguiente premisas:

Usare la librería pytest para los test unitarios.
Los tests unitarios no tendrán acceso a la BD.
Utilizaremos pytest-mock para "Mockear" los métodos que no nos interese testear, como las cosas propias del framework que vienen ya testeadas por los desarrolladores del framework.

¿Porque los test unitarios no deberían tener acceso a la BD?

Muchos autores han discutido, acerca de esto a través de los años, en este momento, dare
mi opinión personal, basada es mi experiencia como desarrollador web.

Mientras tu proyecto crece, la creación de fixtures, para la gran cantidad de modelos, se volverá increíblemente molesta, la gran cantidad de migraciones migraciones incrementará el problema, por supuesto, hacer squash de las migraciones cada cierto tiempo puede aminorar esta carga,
pero aun así muchas veces es complicado, todo esto en conjunto tiene un ineludible final, el tiempo de ejecución de los tests crecerá vertiginosamente, por lo que sera un problema para el CI/CD de tu proyecto, y una perdida de tiempo para el equipo en general.

Por otro lado los test sin acceso a BD nos permite testear de manera aislada.

¿Porque deberían tus tests unitarios ser aislados?

Aislar tus test unitarios es una de las muestras de que tu código esta desacoplado por lo
que estas siguiendo el principio de Unix, has que cada pieza de tu código hace una sola cosa y la hace bien, lo que
por supuesto ayuda a tener un código mas mantenible. Acá te dejo algunas de las ventajas de aislar tus test
unitarios:

Sera fácil encontrar nuestros errores.
No dependeremos de la BD, por lo que nuestros tests serán muy rápidos.
Facilitaremos el despliegue de la aplicación.-
Comprenderemos como funciona el framework mas a profundidad.
Al empezar a testear de esta manera, nos obligaremos a crear código más "testeable", por lo que sera mas legible, organizado y limpio.

¿ Que es Mocking ?

Es un "Doble de Prueba" nos permite Fakear objectos, funciones para que se retornen un valor predeterminados por nosotros, existen varios tipos de Mocking y normalmente los englobamos todos con el termino Mock, si quieres detallar mas los tipos, te recomiendo este articulo.

En este post usare la librería pytest-mock y django-mock-queries, para Fakear QuerySets de django, y omitir el acceso la BD, con lo que logramos test, que no dependan de la bd y que se ejecutan en micro segundos.

Sabiendo esto, ¿que testeamos?

Por lo regular al desarrollar una API Rest usando DRF se deben testear,
estos componentes:

Serializer.
View.

A esto debemos añadirle cosas comunes del framework, como:

Helpers, UseCase, Services (Como llamen en tu equipo a la capa de la lógica del negocio).
Métodos del manager del modelo.
Métodos del modelo.

Estos últimos debemos evitar usarlos, ya que el modelo debería ser usado solo como
capa de acceso a datos, no una capa de lógica del negocio, como muchos (y me incluyo) en nuestros
inicios, comentemos el error de usar.

El modelo.

Para este caso de estudio, crearemos una pequeña API REST, para gestión de mi garage personal,
en el cual solo tendremos un pequeño modelo llamado Car.

Managers

Los managers de Django nos permiten separar la lógica de negocio de los modelos y como bono extra nos ayudan a mantener el principio DRY(Don't repeat yourself).

Continuando con el ejemplo imaginemos que queremos obtener todos los autos cargados al sistema en una fecha especifica (Si, si tengo un
inmenso garage imaginario), para esto debemos usar el ORM de Django y ejecutar esta consulta:

Car.objects.filter(created=my_date).order_by('year')

Sabiendo esto y para no repetir código a lo largo de nuestra aplicación con el objetivo de facilitar el testing, creamos un manager, y agregamos un nuevo metodo get_cars_by_created

Test:

Serializer

Test:

Vista / ViewSet

Test:

Ahora podemos ver el coverage de nuestra aplicación:

Y eso es todo, con esto tendremos un coverage 100% en nuestra app, testeamos de manera separada, todo nuestro código e hicimos del mundo un lugar mejor, si quieren ver el repositorio completo aquí esta

¿Que es el PEP 8 y porque debería implementarlo?

Víctor Villalobos — Sun, 14 Apr 2019 05:28:23 +0000

Originalmente publicado en pythonist.dev

En el mundo del desarrollo es muy común conseguir distintas formas de hacer las cosas, puedes organizar el código como quieras, incluso escribirlo de forma abstracta, esto en muchos casos logra que nuestra profesión sea considerada muchas veces un arte y no una ingeniería, debido a la ausencia de una base solida de como y porque se deben hacer las cosas de una manera en especifico, por lo que es común que conseguimos software mal redactado y mal organizado que al final nadie quiere leer.

La diferencia mas tangible de python con otros lenguajes es que la comunidad tiene como emblema la legibilidad del código, el ZEN de python establece que "Debe haber una y preferiblemente solo una forma obvia de hacer las cosas", por lo que siguiendo este principio, se definio una guiá de estilo única descrita íntegramente en el Python Enhancement Proposal numero 8, abreviado como PEP 8. En esta se define al pie de la letra, como debería estar escrito nuestro código python.

Muchos sabemos que al común denominador de los desarrolladores de software no suele gustarle la obligación impuesta de una forma de hacer su trabajo, con el pasar del tiempo apreciamos que toda la comunidad use una guiá de estilo única, ya que al final del camino nos facilita nuestro trabajo, mejorando mucho nuestra productividad.

Puntos mas importantes del PEP8

Basicos:

Siempre preferir espacios en ves de tabs.
Usar 4 espacios en la indentación.
Las lineas deben tener menos de 80 caracteres.
Las lineas que pasen de esta longitud deben ser divididas en dos lineas, y la linea resultante de la división debe estar indentada.
En una fila, las funciones y las clases deben estar separadas por dos lineas en blanco.
No colocar espacios alrededor de indices de lista, llamadas de funciones o argumentos.

Nombres

Las funciones deben estar declaradas en minúscula y las palabras separadas por guiones bajos def funcion_cool()
Los metodos privados de una clase deben comenzar con doble guion bajo def __private_method().
Los métodos protegidos de una clase deben comenzar con guion bajo def _protected_method().
Las clases y excepciones deben ser capitalizadas por palabra class SuperClass.
Constantes del module deben estar en mayusculas separadas por guiones bajos NUMERO_MAXIMO = 10.
Los métodos de instancia de una clase deben usar el parametro self como primer parámetro.
Los métodos de clase deben usar cls como primer parámetro, para referirse a la misma clase.

Expresiones

Usar negación en linea (if a is not b) en vez de negar una expresion positiva (if not a is b).
No validar valores vacíos usando len if (len(lista) == 0), usar if not lista.
Siempre coloca los imports al inicio del archivo.
Siempre importa funciones y clases usando from my_module import MyClass en ves de importar el modulo completo import my_module
Si aun debes usar imports relativos, usa la sintaxis from . import my_module
Las importaciones siempre deben estar en el orden:

Módulos de la librería standar.
Módulos externos.
Módulos del proyecto.

Y cada sección debe estar en orden alfabético.

Siguiendo estos sencillos puntos, tu equipo de desarrollo y toda la comunidad python estará muy alegre de tenerte.