DEV Community: Aristide Dongo

Building smpp-ts: Creating a Modern TypeScript Library for SMPP Messaging

Aristide Dongo — Thu, 12 Nov 2026 10:09:34 +0000

An open-source project born from real-world integration challenges with the SMPP protocol.

Working with SMS infrastructure is not always as straightforward as it seems.

Behind a simple SMS notification lies an entire communication chain involving applications, message brokers, SMPP connections, SMS gateways, operators, delivery receipts, and failure-handling mechanisms.

While working on SMS messaging systems, I encountered several challenges when integrating the SMPP protocol into Node.js applications.

Rather than repeatedly implementing workarounds in individual projects, I decided to build something reusable.

That is how smpp-ts was born.

GitHub: https://github.com/AristideDongo/smpp-ts

1. The problem: Working with SMPP in Node.js

SMPP (Short Message Peer-to-Peer) is a protocol widely used by telecommunications providers, SMS aggregators, and messaging platforms to exchange SMS messages.

It provides mechanisms for:

Establishing sessions between messaging applications and SMSCs.
Submitting SMS messages.
Receiving delivery receipts (DLRs).
Managing connection states.
Handling asynchronous communication.
Controlling message throughput.

Although SMPP is a well-established protocol, implementing it reliably in an application requires careful attention to several details.

Some of the challenges I encountered included:

Connection management

SMPP sessions need to remain healthy. Network interruptions, timeouts, and unexpected disconnections can affect message processing.

Delivery receipt tracking

Submitting a message does not necessarily mean that it has been delivered. Applications need to correlate asynchronous delivery receipts with the original message submissions.

Scalability

As message volumes increase, managing multiple SMPP connections, submission windows, and throughput limits becomes increasingly important.

Reusability

I wanted a reusable TypeScript implementation that could be integrated into different Node.js applications without duplicating protocol-level logic.

These challenges motivated me to create a dedicated library.

2. Introducing smpp-ts

smpp-ts is an open-source SMPP library written in TypeScript for Node.js.

Its purpose is to provide a modern, reusable foundation for applications communicating with SMSC infrastructure through SMPP.

GitHub repository:

https://github.com/AristideDongo/smpp-ts

The project focuses on:

TypeScript-first development.
SMPP client communication.
Connection and session management.
SMS submission.
Delivery Receipt tracking.
Connection pooling.
Extensible delivery tracking persistence.
ESM and CommonJS compatibility.
Zero runtime dependencies.

The goal is to keep the library focused on SMPP communication while allowing applications to implement their own business logic and infrastructure.

3. What does smpp-ts provide?

Connection management

An SMPP application must establish and maintain a session with an SMSC.

smpp-ts provides connection and session management capabilities to help applications communicate with SMS infrastructure.

SMS submission

The library provides mechanisms for submitting SMS messages through SMPP.

This includes the protocol-level operations needed to send messages to an SMSC.

Delivery Receipt tracking

One important aspect of SMS messaging is knowing what happens after submission.

A successful submit_sm response does not necessarily indicate successful delivery to the recipient.

Delivery Receipts provide additional information about the message lifecycle.

smpp-ts includes a DeliveryTracker designed to associate message submissions with their delivery receipts.

The tracker also supports customizable persistence through a storage interface, allowing applications to integrate their own storage mechanisms.

Connection pooling

When working with higher message volumes, a single connection may not be sufficient.

The library includes pooling capabilities to manage multiple SMPP connections.

This provides a foundation for distributing message submissions across available connections.

Actual throughput must still be controlled according to SMSC and provider limits.

4. Designed to integrate with existing infrastructure

I do not see an SMPP library as a replacement for an SMS gateway.

For example, an architecture using NestJS, RabbitMQ, Jasmin SMS Gateway, and a telecommunications provider can use smpp-ts as its SMPP communication layer.

A simplified architecture looks like this:

Application
    |
    v
NestJS API
    |
    v
RabbitMQ
    |
    v
SMS Worker
    |
    v
smpp-ts
    |
    v
Jasmin SMS Gateway
    |
    v
SMS Provider
    |
    v
Mobile Network

Delivery receipts follow the return path and can be processed by the application to update message statuses.

This separation allows each component to have a clear responsibility:

NestJS handles application logic.
RabbitMQ distributes asynchronous work.
The worker processes SMS jobs.
smpp-ts handles SMPP communication.
Jasmin handles gateway responsibilities and routing.
The application persists business and delivery states.

The library is intended to complement this architecture, not replace its other components.

5. Why open source?

I decided to make smpp-ts open source because I believe protocol implementations benefit from independent testing and contributions.

SMPP has been around for many years, and there is valuable experience within the telecommunications and messaging communities.

I am particularly interested in feedback from developers who operate:

Jasmin SMS Gateway.
Kannel.
SMPP aggregators.
SMS notification platforms.
Banking and fintech messaging systems.
High-volume messaging infrastructure.

There are many implementation details that deserve testing across different SMSCs and network conditions.

I would rather have experienced developers challenge the implementation and identify weaknesses than assume that everything is correct simply because the code works in my own environment.

6. What I want to improve

The project is evolving, and I am working toward making it more reliable and production-ready.

Some of the areas I want to focus on include:

Reliability

Better recovery after process restarts.
More robust delivery tracking.
Better handling of uncertain submission outcomes.

Interoperability

More integration tests with Jasmin.
Testing against additional SMPP implementations.
Better coverage of real-world SMSC behavior.

Performance

Improved throughput management.
Better backpressure handling.
Load and stress testing.

Security

Stronger production configuration guidance.
TLS verification.
Resource limits and protocol input validation.

Observability

Better diagnostics.
Structured events.
Metrics for connections, submissions, and delivery receipts.

These are important areas of development, and community feedback will help determine the most valuable improvements.

7. Looking for contributors and testers

This is an open invitation to anyone with SMPP experience.

I would particularly appreciate help from developers who have experience with:

SMPP protocol implementations.
Node.js and TypeScript.
Jasmin SMS Gateway.
SMSC interoperability.
Delivery Receipt processing.
High-throughput messaging systems.

If you are interested, you can:

Explore the repository.
Try the library in a test environment.
Report bugs and compatibility issues.
Suggest missing features.
Contribute improvements through pull requests.

Repository:

https://github.com/AristideDongo/smpp-ts

Issues and feedback are welcome.

Conclusion

smpp-ts started as an attempt to solve practical problems I encountered while working with SMPP integrations.

It has since become an open-source project that I want to improve beyond my own use cases.

My ambition is to build a useful, well-tested, and maintainable TypeScript library for developers working with SMS infrastructure.

I am not claiming that it is perfect or production-certified. That is precisely why I am inviting the community to test it, review the implementation, and help identify what needs to improve.

If you work with SMPP, I would genuinely appreciate your feedback.

Let's make SMPP development in the Node.js ecosystem better.

Project: smpp-ts

Author: Aristide Dongo

GitHub: https://github.com/AristideDongo/smpp-ts

TypeScript #NodeJS #SMPP #OpenSource #Telecommunications #SMS #JasminSMS #BackendDevelopment

Explanation of Clean Architecture for Beginners

Aristide Dongo — Mon, 29 Sep 2025 13:22:39 +0000

Module 1: The Ultimate Goal: The Perfect Pizzeria

Imagine you’re building your own pizzeria. You want it to be so well designed that if you decide to change the wall color (the user interface) or replace your fridge (the database), your chef never has to change the recipe for your signature pizza.
That’s what Clean Architecture is all about: making sure the secret recipes (your most important code) are protected and don’t depend on anything other than solid ideas.

--------------------------------------------------------------------------
Module 2: The Magic Circles (The Layers)

Architecture is drawn with concentric circles, like Russian nesting dolls.
The Center (The Core): This is where your recipes and rules live (the Domain). It’s the most precious and least changeable part.
Around It (The Chefs): These are the people who apply the recipes (the Use Cases).
Further Out (The Translators): These are the servers that translate the customer’s order into chef language (the Adapters).
The Outside (The Details): This is the real world: the customers’ tables (the UI) and the fridge (the Database).

--------------------------------------------------------------------------
Module 3: The Core: The Secret Recipes (Entities)

At the center, we have the Entities. Think of them as the Original Recipe Book of your pizzeria.
Role: They contain the basic rules, like: "A pizza must always have tomato and cheese," or "The minimum price for a drink is €2."
Protection: They know NOTHING about the website’s color or the type of fridge used. They are pure and stable.
Our Motto: These are the rules that never change, even if the application does.

--------------------------------------------------------------------------
Module 4: The Head Chef (Use Cases)

Right after the Recipe Book, there’s the Head Chef. These are the Use Cases.
Role: Their job is to take a specific order ("Make a Margherita") and follow the steps: get the ingredients from storage, follow the Entity recipe, and give the pizza to the server.
Application Logic: This is the Chef’s logic, not the recipe itself. For example: "If the order is placed after 10 PM, add a €1 night surcharge."
Order: Use Cases are the only ones allowed to modify the Entities.

--------------------------------------------------------------------------
Module 5: The Golden Rule: Never Look Outside

This is the most important and magical rule of Clean Architecture:
Dependencies can only point inward.
The Chef (Inside) cannot depend on the Server (Outside). The Chef doesn’t care if the Server is wearing jeans or a suit. If the Server changes uniform, the Chef doesn’t have to redo the recipe.
The Core never depends on the Outside. If the fridge (DB) breaks, the Recipe Book (Entities) is still fine. This rule isolates the good idea (the Domain) from the technology that keeps changing.

--------------------------------------------------------------------------
Module 6: The Servers and Adapters (Interface Adapters)

This layer does the translation work.
The Controller (Server): It receives the customer’s order (a click on the "Order" button). It takes the raw information and transforms it into the exact format that the Chef (Use Case) understands.
The Presenter (Server that brings the plate): Once the pizza is ready, the Chef gives it to the Presenter. The Presenter puts it on a nice plate and makes sure it’s cut into six slices so the customer is happy (preparing it for the UI View).

--------------------------------------------------------------------------
Module 7: The Outside World (Frameworks and Details)

This is the layer farthest from the center, the most changeable, and the least precious.
The Dining Room (UI): This is what the customer sees: chairs, tables, colors. Today it’s a website; tomorrow, maybe a mobile app. The Chef doesn’t care.
The Fridge/Storage (Database): This is where the ingredients (data) are stored. Whether you use a Samsung or LG fridge (SQL or NoSQL), the Chef just needs the tomatoes brought to them.

--------------------------------------------------------------------------
Module 8: The Secret Service Trick (Dependency Inversion - DIP)

How does the Chef request ingredients without knowing which fridge is being used? It’s magic!
The Chef (Inside): He says, "I need an Ingredient Manager (this is an Interface, a promise)."
The Fridge (Outside): There’s someone called the "LG Fridge Manager," and this person fulfills the role of "Ingredient Manager."
Injection: Someone (in the outermost layer) gives the Chef the phone number of the "LG Fridge Manager" saying, "Here’s your Ingredient Manager!"
Result: The Chef calls the role (the Interface) and not the fridge brand (the concrete implementation). The dependency flow is reversed, and the Core remains pure!

--------------------------------------------------------------------------
Module 9: The Storage Boxes (Component Architecture)

Imagine your Chef. He organizes his tools. He doesn’t mix pizza knives with soup ladles.
Key Principle (CCP): Group together things that change for the same reason. If I change the rule about cheese, I put the cheese recipe and the cheese inventory in the same "code box."
Isolation: If you change the "home delivery" box, it shouldn’t affect the "dessert recipes" box. This makes updates faster and safer.

--------------------------------------------------------------------------
Module 10: The 5 Developer Commandments (SOLID)

Clean Architecture is just the application of 5 basic rules (called SOLID) to the whole pizzeria:

1.SRP (Single Responsibility Principle): Each person has only one job. The Server doesn’t make pizzas.

2.OCP (Open/Closed Principle): You should be able to add a new recipe (Open) without touching the old ones (Closed).

3.LSP (Liskov Substitution Principle): If you replace your Chef with another Chef of the same title, they must make the same pizzas without breaking the rules.

4.ISP (Interface Segregation Principle): The Chef doesn’t need to know the dishwasher’s rules; they only have their small order notebook. (Small notebooks = small Interfaces)

5.DIP (Dependency Inversion Principle): Our Secret Service trick (Module 8). The Core depends on abstractions, not details.