DEV Community: HILQIA KENDA

Rebuilding RouteMatrix

HILQIA KENDA — Mon, 23 Feb 2026 16:08:09 +0000

A few months ago, I shipped the first version of RouteMatrix.

Technically, it worked.

Users could create trips. Data flowed. The system held up.

But something felt off.

I was shipping features… without deep clarity.

So I paused and asked myself a harder question:

What problem am I actually solving?

That question forced a reset.

The Realization

RouteMatrix started as a generic trip management tool.

But logistics teams don’t need “trip tools.”

They need:

Clear fleet visibility
Accountability across drivers and dispatch
Operational clarity without chasing spreadsheets
Reliable tracking that reflects real-world constraints

I wasn’t building for those pains directly.

So instead of iterating on surface features, I decided to rethink the foundation.

The Rebuild

RouteMatrix is now being rebuilt as a Tracking Truck SaaS — designed specifically around operational workflows in logistics.

This isn’t a UI redesign.

It’s a structural shift:

New architecture
New data model
New mental model

I’m redesigning how trips are represented.
How tracking events are stored.
How fleet-level aggregation works.
How accountability is enforced at the system level.

Less “feature shipping.”

More system design thinking.

Building in Public

I’m documenting the rebuild openly:

Architecture decisions
Mistakes
Trade-offs
What I’d never do again

Future posts will go deeper into:

Backend architecture
Data modeling for fleet tracking
Scaling event ingestion
Designing for operational clarity instead of feature volume

If you’re building in logistics, fleet management, or SaaS infrastructure — I’d love to exchange ideas (or even collaborate).

The next updates will be more technical 👀

Why Refactoring Can’t Save Bad Architecture

HILQIA KENDA — Sat, 14 Feb 2026 13:15:32 +0000

When a codebase starts to feel messy, the first instinct is almost automatic:

“Let’s refactor it.”

I did that.
Again.
And again.
And again.

Each time, the code looked cleaner — for a while.

But no matter how much I refactored, the system kept collapsing back into complexity. New features would arrive, and the mess would quietly return as if nothing had changed.

That’s when I learned something the hard way:

Refactoring improves code. It does not fix architecture.

The Phase Where Everything Felt Wrong

This was the stage where:

Features were tightly coupled
Models were doing too much
Business logic had leaked into places it didn’t belong

The system worked, but it felt heavy, fragile, and hard to extend.

So I did what most developers do when they sense disorder.

I tried to clean it up.

I renamed variables.
Extracted methods.
Reorganized folders.
Split large functions into smaller ones.

And yes — it looked better.

But only on the surface.

The Illusion of Progress

The code became more readable. Easier to navigate. Cleaner to look at.

But beneath that:

The boundaries were still unclear
- Responsibilities were still blurred
- The system still didn’t know what it wanted to be
- And the real test came when I started adding new features.

The mess returned.

Not because I wrote bad code.
But because the architecture was never designed for growth.

I was repainting walls in a house with a cracked foundation.

What Refactoring Actually Does

Refactoring is valuable. It absolutely has its place.

Refactoring:

Improves readability
Reduces duplication
Simplifies functions Makes code easier to understand But architecture is something else entirely.

Architecture:

Defines boundaries
Controls dependencies
Separates responsibilities Protects the system from entropy as it grows

Refactoring cleans.
Architecture contains.

If the structure is wrong, no amount of cleaning will stop it from collapsing under new weight.

The Real Problem I Hadn’t Faced

I hadn’t clearly defined:

The core domain of the system
The long-term goal of the application
The separation between planning, tracking, and operations
What belonged where — and what absolutely didn’t

So every new feature bent the structure a little more.

Until eventually, it snapped.

The Lesson

Refactoring is not a substitute for architectural thinking.

Before cleaning code, ask:

What are the boundaries in this system?
What responsibilities belong to each part?
How will this design behave when the system doubles in size?

Because if the architecture isn’t prepared for growth, the mess will always come back.

No matter how clean the code looks today.

[Boost]

HILQIA KENDA — Thu, 12 Feb 2026 20:21:15 +0000

⚡ Setting Up the Server for a Real-Time Chat App with TypeScript & Express

HILQIA KENDA ・ Aug 23 '25

#typescript #node #javascript #beginners

🚀 Building a Fuel Route Optimization API with Django, Redis & OpenRouteService

HILQIA KENDA — Thu, 12 Feb 2026 19:45:00 +0000

Last night, I challenged myself to solve a very practical problem:

How do you find the cheapest fuel stops along a driving route between two cities?

At first, it sounded simple.

Until I opened the fuel station dataset and realized…

It had no coordinates. 😅

That’s when this turned from a simple API into a deep dive into:

Routing
Geocoding
Spatial matching
Caching
Performance engineering

🧠 The Core Idea

Given:

Start Address → End Address as a string or list of coordinates

The system should:

Geocode both addresses using OpenRouteService
Fetch the driving route polyline
Build a route corridor using bounding boxes along the path
Match fuel stations from a CSV dataset that fall inside this corridor
Return the cheapest stations along the trip

No coordinates in the dataset? No problem. We make the map logic do the work.

⚡ The Performance Problem

Geocoding and routing APIs are expensive and slow.

So I introduced Redis caching:

Addresses are geocoded once and cached forever
Routes are cached
Fuel stations are loaded into memory using Pandas

And here’s the fun part:

❌ No database
❌ No GIS server
✅ Pure spatial computation in memory

After the first request, response times drop to under 150ms.

🛠️ Stack Used

Django + DRF
Redis
Pandas
GeoPandas
OpenRouteService API
Spatial math (without PostGIS)

💡 Key Engineering Lessons

Normalize messy data instead of bending your logic around it
Cache aggressively when dealing with external APIs
You don’t always need a database for spatial problems
Bounding boxes + in-memory data can be incredibly fast

This project genuinely felt like building a mini map engine from scratch.

⚡ Setting Up the Server for a Real-Time Chat App with TypeScript & Express

HILQIA KENDA — Sat, 23 Aug 2025 05:30:00 +0000

Real-time applications are everywhere today — from chat apps to trading dashboards. I recently started working on a real-time chat application, and the first step was setting up the server to handle secure, scalable communication.

Here’s a walkthrough of the setup:

🏗️ Project Structure

I’m building the app in TypeScript with Express.
The backend structure looks like this:

backend/  
 └── src/  
     ├── features/  
     ├── shared/  
     ├── config.ts  
     ├── routes.ts  
     ├── setupDatabase.ts  
     └── setupServer.ts

⚙️ The Server Setup(setupServer.ts)

Here’s the core of the server class:

import {
  Application,
  json,
  urlencoded,
  Response,
  Request,
  NextFunction,
} from 'express';
import http from 'http';
import cors from 'cors';
import hpp from 'hpp';
import cookieSession from 'cookie-session';
import HTTP_STATUS from 'http-status-codes';
import 'express-async-errors';
import helmet from 'helmet';
import compression from 'compression';

export class ChattyServer {
  private app: Application;

  constructor(app: Application) {
    this.app = app;
  }

  public start(): void {
    this.securityMiddleware(this.app);
    this.standardMiddleware(this.app);
    this.routeMiddleware(this.app);
    this.globalErrorHandler(this.app);
    this.startServer(this.app);
  }

  private securityMiddleware(app: Application): void {
    app.use(cookieSession({
      name: 'session',
      keys: ['key1', 'key2'],
      maxAge: 24 * 60 * 60 * 1000
    }));
    app.use(hpp());
    app.use(helmet());
    app.use(cors());
  }
}

🔐 Security Middleware

Real-time apps need robust security because of constant data exchange. I’ve added:

cookie-session → lightweight session handling
hpp → protects against HTTP parameter pollution
helmet → adds secure HTTP headers
cors → enables cross-origin requests safely

📡 Next Steps

With the foundation in place, the next steps are:

Integrating a database (setupDatabase.ts)
Adding WebSocket support for real-time messaging
Implementing user authentication & chat channels

🚀 Takeaway

Setting up a server for a real-time chat app is more than just “getting Express running.” It’s about:

Structuring middleware for scalability
Prioritizing security early
Preparing for real-time event-driven communication

I’ll share progress on WebSocket integration in the next part. Stay tuned!

🛠️ Setting Up Fusio as an API Gateway for CRM & LLM Microservices

HILQIA KENDA — Thu, 24 Jul 2025 22:10:24 +0000

Over the past few days, I’ve been working on integrating an open-source API management layer using Fusio (v5.2.3) to centralize and secure communication between our CRM and LLM-based applications.

🔍 Why Fusio?

Fusio provides a lightweight, flexible API gateway and management system with:

Visual interface for API operations
Built-in support for OAuth2, rate limiting, and request logging
Schema-driven API design
Real-time analytics & monitoring dashboards
It’s a great fit for internal service coordination, especially when you're running microservices for systems like:
Customer Relationship Management (CRM)
Large Language Model (LLM) integration APIs

⚙️ What I Set Up
🚀 API Gateway Layer between multiple services (CRM-Core, CRM-MatchMaker, LLM engine)
🧩 Defined operations, actions, and routes inside Fusio to handle each microservice endpoint
🔐 Centralized access control and token handling
📈 Enabled real-time metrics for test coverage, error rate, usage per operation, and latency

🧪 Testing & Challenges

✅ Successfully simulated and monitored traffic between internal endpoints
🐛 Faced and fixed a persistent MySQL connection issue while spinning up the Fusio container (lesson: always verify DB port exposure + credentials in .env)
🔄 Used docker-compose to manage isolated services, with volume resets during setup retries


# Used this command combo to reset and re-run the setup
docker-compose down -v
sudo rm -rf ./db
docker-compose up -d

✅ What’s Next

Finalizing integration with the production application layer
Setting up WebSocket event streaming for real-time updates
Deploying Fusio on a cloud server for internal + external access

💡 Final Thoughts

Fusio is a powerful open-source tool that gives devs full control over API lifecycle management — without depending on heavy SaaS solutions. For internal microservice architectures, especially with real-time and AI-driven logic like CRM + LLM, it’s proving to be a great fit.

🧵 Stay tuned

next post will cover production deployment and runtime performance benchmarks.

Tags:

@backend @api @microservices @opensource @devops @crm @llm @fusio @pytutorial @docker

Why the Single Responsibility in Software Development?

HILQIA KENDA — Fri, 24 Jan 2025 14:17:12 +0000

Why use a single responsibility in software development?

A single responsibility into the application, resulte to a clean and well-organized architecture by breaking down an application into different layers, we can easily manage and maintain our code.
Single responsibility reduce the duplication as well and improve scalability of the application.

This is some few benefits and the beauty of single responsibility into an application.

The This Keyword

HILQIA KENDA — Tue, 14 Jan 2025 21:48:59 +0000

**Im a going to give a closer look to one of the features that confuses many developers in JavaScript; the This Keyword. Mostly that is because of the poor explanation or teaching materials about the this keyword. I personally I was really confused about this keyword and it was not easy to understand how it works, until I found these 2 rules to understand it easily; these are execution with: 1) A Method or function within an object and 2) with Regular function.

Frist of all What is the this keyword? This refences the object that is executing the current function.
If a function is a method in object, this references object itself. E.g.
// method -> obj

If the function is a regular function (which is not in object) this references the global object. E.g.
// function -> global (in browser: windows, in Node: global)

1st Rule within an Object
Let take an example:

const vehicle = {
  brand: "Toyota",
  productionDate: "2020-04-05",
  start() {
    console.log(this);
  },
};

vehicle.start();

Because start is a method in the vehicle object, we will get the vehicle object in the console.
Here is the output:
// {brand: 'Toyota', productionDate: '2020-04-05', start: ƒ start()}

If we add a stop method as follow:

const vehicle = {
  brand: "Toyota",
  productionDate: "2020-04-05",
  start() {
    console.log(this);
  },
};

vehicle.stop = function (){
    console.log(this)
}

vehicle.stop();

the output in the console is still the same, because stop is a method or a function in the object.

2nd Rule is with a regular function.
Let take an example:

function startVehicle() {
  console.log(this);
}
startVehicle();

if this function is long to the console, we are going to get a window object in browser and global in Node.
However, if we use a constructor function with the new operator the output will be different, let see a similar example:

function StartVehicle(brand) {
  this.brand = brand;
  console.log(this);
}

const start = new StartVehicle("BMW");

With this the output is:

// StartVehicle {brand: 'BMW'}

This time we are getting a new object here. By the way note that this object is a completely different object, it is not the StartVehicle object.
When you use the “new” operator it returns an empty object “{}”and then set this keyword to point the new object, that is ho we get the new object returned.

// new -> {} and then this point to the new object

Here is the take away, when dealing with a object this reference to the object itself.
However, when dealing with the regular function this by the default reference to the global object. But if you call a function using the new operator the case in our early constructor’s function example, this will reference a new empty object create by the new operator.

I am going to give a closer look to one of the features that confuses many developers in JavaScript; the This Keyword. Mostly that is because of the poor explanation or teaching materials about the this keyword. I personally I was really confused about this keyword and it was not easy to understand how it works, until I found these 2 rules to understand it easily; these are execution with: 1) A Method or function within an object and 2) with Regular function.

Frist of all What is the this keyword? This refences the object that is executing the current function.
If a function is a method in object, this references object itself. E.g.

// method -> obj

If the function is a regular function (which is not in object) this references the global object. E.g.

// function -> global (in browser: windows, in Node: global)

1st Rule within an Object
Let take an example:

const vehicle = {
  brand: "Toyota",
  productionDate: "2020-04-05",
  start() {
    console.log(this);
  },
};

vehicle.start();

Because start is a method in the vehicle object, we will get the vehicle object in the console.
Here is the output:

// {brand: 'Toyota', productionDate: '2020-04-05', start: ƒ start()}

If we add a stop method as follow:

const vehicle = {
  brand: "Toyota",
  productionDate: "2020-04-05",
  start() {
    console.log(this);
  },
};

vehicle.stop = function (){
    console.log(this)
}

vehicle.stop();

the output in the console is still the same, because stop is a method or a function in the object.

2nd Rule is with a regular function.
Let take an example:

function startVehicle() {
  console.log(this);
}
startVehicle();

function StartVehicle(brand) {
  this.brand = brand;
  console.log(this);
}

const start = new StartVehicle("BMW");

With this the output is:

// StartVehicle {brand: 'BMW'}

// new -> {} and then this point to the new object

DEV Community: HILQIA KENDA

Rebuilding RouteMatrix

The Realization

The Rebuild

Building in Public

Why Refactoring Can’t Save Bad Architecture

The Phase Where Everything Felt Wrong

The Illusion of Progress

What Refactoring Actually Does

The Real Problem I Hadn’t Faced

The Lesson

[Boost]

⚡ Setting Up the Server for a Real-Time Chat App with TypeScript & Express

HILQIA KENDA ・ Aug 23 '25

🚀 Building a Fuel Route Optimization API with Django, Redis & OpenRouteService

🧠 The Core Idea

⚡ The Performance Problem

🛠️ Stack Used

💡 Key Engineering Lessons

⚡ Setting Up the Server for a Real-Time Chat App with TypeScript & Express

🏗️ Project Structure

⚙️ The Server Setup(setupServer.ts)

🔐 Security Middleware

📡 Next Steps

🚀 Takeaway

🛠️ Setting Up Fusio as an API Gateway for CRM & LLM Microservices

🔍 Why Fusio?

⚙️ What I Set Up

🧪 Testing & Challenges

✅ What’s Next

💡 Final Thoughts

🧵 Stay tuned

Tags:

@backend @api @microservices @opensource @devops @crm @llm @fusio @pytutorial @docker

Why the Single Responsibility in Software Development?

The This Keyword