The journey of Kahiether is not about chasing the latest framework or achieving peak performance benchmarks. It is about creating a microservice and an ecosystem that remains simple, portable, flexible, and above all, useful in everyday life.

Over more than a decade of trials , false starts, and accumulated experience, a vision emerged: to design something minimal yet practical, something resilient yet lightweight, something that does not bend under the weight of complexity.

In my sleep I dreamed one time of a world where automated systems could assist people, so everyone could keep their job will less hours, spending more time with family, doing with activities and doing what they really want to do.

Kahiether's Microservice is not engineered as a system designed for the market. It began as an exploration of how tools could be built to just assist and reduce workload.

The process involves identifying recurring difficulties, learning from repeated failures, forming a clear vision, and then gradually building the foundations of an ecosystem that grows one service at a time. We learned in production engineering concepts that are the essence of improvement:

• 改善 (Kaizen) : Improve Continuously
• 平準化 (Heijunka) : Level production / load
• 無駄 (Muda) : Eliminate waste
• 標準作業 (Hyojun sagyo) : Standardize work
• 現地現物 (Genchi Genbutsu) : Check directly in production to see real problems
• The 5 S :
  • 整理 : sort "most used vs less used"
  • 整頓 : organize " easy to find"
  • 清掃 : clean " start fresh "
  • 清潔 : standardize "create patterns and architectures"
  • 躾 : discipline " follow as possible the vision"

The result of transposing these process into software engineering create a frame to build a microservice, but this process was not linear and simple as expected.

Constraints Before Kahiether 🌋

Large applications often suffer from a fundamental overwork: only a fraction of the code is used at all.

In many systems, around 80 percent of the logic remains dormant, running only in rare cases or existing to support optional features. For example, a software must be compatible and run in CentOS, Feodora, Debian, Windows 11 but at some point of its lifecycle no one use Debian to run it. Yet this unused code still needs to be maintained, updated, and shipped. It increases complexity without adding proportional value. Such bloat leads to applications that are heavier than they need to be, with consequences for performance, maintainability, and scalability.

A second difficulty arises in the imbalance of component usage.

In many platforms, different parts of the application receive drastically different amounts of traffic, I particularly noticed this in e-commerce and markeplace applications. For example, a product page might account for half of the total system load (in RAM, CPU, thread and disk memory for data), while a cart handles ten percent and other sections much less. Despite these uneven demands, traditional architectures scale the entire application uniformly. This creates inefficiency, as resources must be allocated to every component even when only one or two are under stress. The result is unnecessary cost and complexity.

We (buy and) install modules because we don't want to rewrite what was already written before, but these modules in most of cases contains a lot of parts that doesn't fit to our use case and opens the way to customization mess.

Indeed, another source of frustration comes from libraries ( dear npm/yarn install😄). Many libraries are designed for broad compatibility: multiple operating systems, numerous use cases, and features covering edge scenarios. Yet in practice, less than half of the library’s code is ever called by the application. The rest is unused, but it still ships, loads, and needs maintenance. Instead of simplifying work, such libraries often add hidden layers of complexity.

Taken together, these constraints revealed a problem : mainstream approaches are all different and they were not aligned with personal needs of simplicity, efficiency, and autonomy. These problems set the stage for the search for a different approach.

Improving from Failures ⛺

The first attempt to solve these difficulties was an application called MyPa, short for “My Personal Assistant.” It was created in VBA, and its purpose was straightforward: to store data, open links, and act as an assistant. I included inside a monolithic structure with hyperlink storage and opening, data management, data mass import and quick manipulation Although it worked at a basic level, it was constrained by the environment.

VBA tied the tool and restricted web and mobile capabilities.

It was an experiment that highlighted the things not to do and paved the way to the exploration of numerous open-source microservices available online, mostly built in JavaScript. Each attempt revealed once again that the existing options were designed with assumptions that did not align with the goals at hand.

A more ambitious step was then taken: building a microservice directly using Vue.js 2.

At first, it seemed promising. Tools like Webpack were added to manage builds, followed later by Vite. Each of these technologies is really powerful, state-of-the-art but their introduction came with trade-offs: performance improvements at the cost of rising technical debt, maintenance work, number of dependencies. Instead of reducing complexity, these tools expanded it.CSS libraries were also brought in to simplify interface work. While they offered shortcuts, they introduced the same long-term issue: dependency overhead.

A small project could quickly become entangled in third-party code that added weight without proportional utility. Over time, these dependencies made the project harder to maintain.

These failures stretched over a certain time. Each attempt reached a certain point and then collapsed under the same contradictions: seeking simplicity while being trapped by complexity. Yet from these failures, clarity emerged. The accumulated lessons pointed toward a vision that could finally align with the original goals.

Vision (the Why) 🏞️

The vision of Kahiether is shaped by being constrained unnecessary weight and focusing on solving real problems.

The single purpose is to build tools that directly address practical needs / problems.

These are concrete, everyday challenges: resizing images for administrative tasks, converting files to PDF, memorizing hanzi and kanji while learning languages, synchronizing files across devices, automating repetitive operations like retrieving website HTML. Each of these use cases is modest but real, and together they represent the kind of productivity gains that matter most.

Another principle is acceptance of limitations.Kahiether does not aim to be the most secure system in the world.

Instead, it reduces risk by design: no sensitive personal data is stored, most data lives offline, and the system is built to fail gracefully. If servers are attacked or fail, services are designed to restart quickly and continue functioning in offline mode. Basic protections like rate limiting are in place, but the goal is resilience, not absolute invulnerability.

Portability is also central :Kahiether uses Docker and experiments with Podman, but avoids the complexity of Kubernetes.

The aim is not to manage massive clusters but to keep services lightweight and flexible. Code is stored redundantly across different regions and providers: GitHub in the United States, GitLab in Europe, and a third depot in China. This ensures continuity and independence.The microservice architecture is designed to be web-based but storage-independent.

Progressive Web Apps (PWAs) allow mobile use while still functioning offline.

Distribution is embraced as a way to reduce energy consumption: once a service is downloaded, it can run indefinitely without constant server calls, lowering CO₂ impact.

Technical debt is kept minimal : Kahiether’s backend relies on only two dependencies: Express and Node.js.

On the front end, there are zero dependencies. No bundlers like Webpack or Vite are used. This keeps the system light, transparent, and easy to understand.

This vision shaped the direction of Kahiether. The goal became clear: to create an ecosystem that could remain small in structure yet broad in utility.

Birth of Kahiether

The name “Kahiether” brings together two symbolic ideas.

• “Kahie” 📖 means book in Malagasy, a reference to structure, clarity, and the ability to preserve knowledge.
• “Ether” ⚗️ referreds intially to a volatile element that filled space or void. Today it is still considered as a volatile element used for example in dissolvents.

Combined, the name represents a system that is both structured but very light, so light that it volatile, very fluid, and flexible.

Kahiether ecocsytem was never meant to be a single microservice template. From the beginning, it was conceived as a system of multiple microservices and some opensource solutions forming an ecosystem. Each service would stand on its own but share the same design philosophy.

Some open-source components are integrated in the core ecosystem such as Node-RED, Docker, Ghost, Wordpress, but the core remains independent and open-source.

The creation of Kahiether was a gradual alignment of vision and practice.

Features ⚙️

Kahiether services are guided by a set of clear features that distinguish them from conventional approaches.

• Offline-first functionality. 🛜

Every service comes with a service worker, ensuring that files are stored locally. Once installed, a Kahiether service continues to work without internet access.

Updates are fetched when connectivity is available, but core functions are always accessible. This makes Kahiether resilient in contexts where online connectivity cannot be guaranteed.

• Light structure. ▫️

A Kahiether service is built with three main files: main.js, styles.js, and index.html.

An earlier file called db.js was used in older services but later removed to reduce complexity. No folders are used. Everything is visible at a glance. Each file is kept under 1,000 lines, including spacing, with verbosity preferred over compact optimization. The goal is transparency and readability rather than maximum efficiency.

• Light Load. ⚖️

Less than 1vCPu and less than 500Mb of RAM for microservices.

• Responsivity. 📱

Each service includes a manifest.json, enabling installation as a PWA. I need to say goodbye to sinfle software with one codebase per platform : one codebase in kotlin, one in Swift, one in C# ...

This allows the same codebase to serve both web and mobile / tablets use cases without relying on separate applications.

• Universality. 🌍

Services are written in plain JavaScript, without TypeScript or other abstractions.

This choice accepts JavaScript’s drawbacks—such as loose typing—but prioritizes universal compatibility. To reinforce universality, Unicode is embraced, including emoji, and only widely available fonts like Arial and Noto are used.

• Finally, Kahiether must be adaptable. Several services have already been created to showcase this philosophy in several domains such as:
  • MyPa : indexing and multi task.
  • Shiro : games
  • Nali : travel utilities with geolocation.
  • Resizer : image resizing, text reading, and speech.
  • Yapishu : e-learning through quizzes, writing, and listening.
  • Mpaka : content extraction.
  • Kizuna : modular scripting and feature import.

Each of these services are not perfect, they serve a unique need insure that their main purpose is served.

Perspectives

The development of Kahiether is not a finished story. Several directions shape its future.

One perspective is the integration of lightweight artificial intelligence.

🤖 As models become smaller and more efficient, few candidates from Hugging Face are being tested. Kahiether could incorporate these models, bringing powerful AI capabilities into offline-first services.

Another direction is the creation of full list microservices that replicate what are currently large monolithic systems.

🏪 Entire domains such as e-commerce, customer relationship management, and enterprise resource planning are today dominated by heavy solutions. Kahiether has the potential to show that these same functions can be delivered by small, independent, resilient microservices without the overhead of massive platforms.

Finally, the future of Progressive Web Apps could open even more opportunities.

📴 As specifications expand and browsers provide deeper native integrations, PWAs may gain more capabilities to interact with devices and the Internet of Things. This would allow Kahiether services to extend naturally into new contexts, from mobile devices to connected environments.

It is what it is 🏝️

To sum it up : Kahiether is not the fastest, nor the most secure, nor the most feature-rich system. It does not claim perfection. It offers services that are simple, transparent, lightweight, and resilient. It is a system that prioritizes usefulness over complexity, autonomy over dependence, and clarity over optimization.

Born from difficulties, refined through failures, and shaped by a clear vision, Kahiether is expression the vision that innovation often emerges from constraints. By keeping code minimal, dependencies light, and functionality offline-first, it shows that software can be practical without being heavy, and universal without being overloaded. My big hope for PWA is that one day they could run Daemon or cron like execution like native systems. Kahiether future lies in extending these principles further, exploring new services with artificial intelligence, modular replacements for monolithic systems, and deeper capabilities through progressive web apps. Why ? because

✨Some innovations emerge from the toughest conditions. Progress begins when open tools empower everyone, everywhere.✨

Hello,

Pre requirement : This strategy is very related to the microservice pattern where all the logic is stored fully in client side. We need to remember that this pattern doesn't works for use cases where some logic and data are manage by the distant server.

This time, we'll explore how to build web applications and mobile / desktop PWA taking account of network constraints - from fiber-optic highways to the most challenging network environments on Earth. This story started 20 years ago in Madagascar.

Network Reality Check

When 56k Was a Dream

Picture this: Madagascar, 2005 - 2010. While the world was transitioning from dial-up to broadband, we were celebrating when our connection stayed stable long enough to download a single MP3 file. I personally remember spending 2-3 days downloading just a few megabytes, forcing to switch from direct download to using eMule and BitTorrent's partial download features to grab chunks.

The strategy was simple but effective:

• Download small chunks when possible
• Resume from where we left off
• Pray that some parts of the file is not missing
• The file will be usable only if the full chunks are downloaded

Sound primitive? Maybe. But it taught me invaluable lessons about resilience and the importance of designing for the worst-case scenario.

Fast Forward to Today: Not Much Has Changed

We would think that 20 years later, with 4G, 5G, satellite network and fiber optics spreading globally, these problems would be ancient history. But, some of the challenges are still there:

• Connection speeds might be better on paper, but reliability remains abysmal especially when moving out in the deep countryside
• Power outages are still frequent and long
• Network interruptions happen without warning
• Data costs make every megabyte precious

The infrastructure has improved, but the fundamental challenges persist. This reality shaped my approach to building solutions that actually work for everyone, not just those with gigabit connections.

The Problem: Traditional Caching Strategies Fail

Why Standard Approaches Don't Work

Most web caching strategies assume:

1. Stable connections (even if slow)
2. Ability to complete HTTP requests
3. Predictable timeout behaviors
4. Power reliability
5. Stable servers (no attacks, no errors)

In Madagascar-like conditions, these assumptions crumble:

When your connection drops every few minutes and power cuts mid-download, traditional cache-first or network-first strategies leave users stranded.

The Solution: Adaptive Resilience Strategy

Learning from P2P: The Chunking Philosophy

Remember how eMule and BitTorrent solved the download problem? They broke files into chunks, grabbed what they could, and assembled the pieces later. We can apply similar thinking by considering each file as chunk to web apps, and add a microservice pattern to reduce the number of chunks managed in a single app :

javascript

const CONFIG = {
  CACHE_NAME: self.SW_CACHE_NAME || 'faritany-v2',
  TEMP_CACHE_NAME: self.SW_TEMP_CACHE_NAME || 'faritany-temp-v2',
  FIRST_TIME_TIMEOUT: parseInt(self.SW_FIRST_TIME_TIMEOUT) || 30000, // 30 seconds
  RETURNING_USER_TIMEOUT: parseInt(self.SW_RETURNING_USER_TIMEOUT) || 5000, // 5 seconds
};

The Strategy

After a few years of refinement, here's the last approach that has proven successful since now :

1. First Contact: Maximum Patience

New users need to download the app at least once. We give them every chance and time to fetch all the assets:

async function fetchFromNetworkWithExtendedTimeout(request) {
  try {
    console.log(`Service Worker: First time user - extended network timeout: ${request.url}`);
    
    // Extended timeout for first-time users (30 seconds)
    const timeoutPromise = new Promise((_, reject) => {
      setTimeout(() => reject(new Error('Network request timeout - first time user')), CONFIG.FIRST_TIME_TIMEOUT);
    });
    
    const networkResponse = await Promise.race([
      fetch(request),
      timeoutPromise
    ]);
    
    if (!networkResponse.ok) {
      throw new Error(`Server error: ${networkResponse.status}`);
    }
    
    // SUCCESS: Cache for future use
    console.log(`Service Worker: First time success - caching: ${request.url}`);
    const cache = await caches.open(LIVE_CACHE);
    cache.put(request, networkResponse.clone());
    
    return networkResponse;

This mirrors the patience we had downloading files 20 years ago - sometimes you just need to wait for that one good moment.

2. Returning Users: Try network of fallbacks

When a user returns, he already have a working version on his cache, so if he has network we try to update, but if the update takes too much time to complete, then we cut the update and fallback on cache:

javascript

    // Create timeout promise (5 seconds max wait)
    const timeoutPromise = new Promise((_, reject) => {
      setTimeout(() => reject(new Error('Network request timeout')), CONFIG.RETURNING_USER_TIMEOUT);
    });
    

3. Power Outage Protection: Atomic Updates

Nothing's worse than a half-updated app after power returns. So we need to check that everything is updated before switching the existing version:

javascript

// Install: Download all assets into a temporary cache.
self.addEventListener('install', event => {
  console.log('Service Worker: Installing...');
  self.skipWaiting(); // Force immediate activation
  
  event.waitUntil(
    caches.open(TEMP_CACHE).then(tempCache => {
      return Promise.all(
        ASSETS.map(url => {
          return fetch(url).then(response => {
            if (!response.ok) {
              throw new Error(`Failed to fetch ${url}: ${response.status}`);
            }
            console.log(`Service Worker: Cached ${url}`);
            return tempCache.put(url, response.clone());
          }).catch(error => {
            console.error(`Service Worker: Failed to cache ${url}:`, error);
            // Continue with other assets even if one fails
            return null;
          });
        })
      );
    })
  );
});

// Activate: Replace live cache ONLY if ALL assets are staged
self.addEventListener('activate', event => {
  console.log('Service Worker: Activating...');
  event.waitUntil(
    (async () => {
      const tempCache = await caches.open(TEMP_CACHE);
      const cachedRequests = await tempCache.keys();
      
      // ALL ASSETS ARE CRITICAL - Strict verification
      if (cachedRequests.length === ASSETS.length) {
        console.log('Service Worker: ALL assets staged successfully, updating live cache');
        
        // Complete atomic replacement
        await caches.delete(LIVE_CACHE);
        const liveCache = await caches.open(LIVE_CACHE);
        
        // Copy ALL assets from temp cache to live cache
        for (const request of cachedRequests) {
          const response = await tempCache.match(request);
          await liveCache.put(request, response);
        }
     

Real-World Implementation Details

Cache lock rescue

At the time of this update some code was already running with a specific version, so we need to implement the rescue process. The main issue that must be checked is the cache lock, so the solution is to intercept the main.js and inject inside of it the rescue code.

// server.js
const express = require('express');
const path = require('path');
const fs = require('fs');
const app = express();


// CACHE VERSION MANAGEMENT - Change this to deploy new version
const CACHE_VERSION = process.env.CACHE_VERSION || 'v2';
const APP_NAME = process.env.APP_NAME || 'faritany';

// Cache Lock Rescue - Intercept main.js to inject rescue code
app.get('/main.js', (req, res) => {
  try {
    // Read the actual main.js file (your existing game/app code)
    let jsContent = fs.readFileSync(path.join(__dirname, 'main.js'), 'utf8');
    
    // Inject ONLY the rescue detection code at the beginning
    const rescueCode = `
// Cache Lock Rescue - Check for ${CACHE_VERSION} users and free older versions
if ('serviceWorker' in navigator) {
  caches.keys().then(cacheNames => {
    const hasCurrentVersion = cacheNames.some(name => name.includes('-${CACHE_VERSION}'));
    
    if (!hasCurrentVersion && cacheNames.length > 0) {
      // Old version detected - unregister and reload
      console.log('Cache lock detected - rescuing to ${CACHE_VERSION}...');
      navigator.serviceWorker.getRegistration().then(reg => {
        if (reg) reg.unregister().then(() => location.reload());
      });
      return; // Stop here for old version users
    }
    
    // Current version users or new users - normal service worker registration
    navigator.serviceWorker.register('/service-worker.js', {updateViaCache: 'none'});
  });
}
`;

Lessons from the Field

What Really Matters

1. Assume Nothing: That 4G/5G signal might drop to EDGE without warning or come back to normal without warning
2. Cache Everything: Every byte downloaded is precious
3. Fail Gracefully: Errors should guide, not frustrate
4. Background Updates: Never completely block the user experience
5. The user usually manages to cut itself his data when it is not unlimited: Most user switch off data and uses specific prices for Facebook mobile only and Whatapp mobile only

The Bigger Picture

Why This Matters

Building for challenging situations is inside Kahiether's DNA.

1. Performance Benefits Everyone: Optimizations for slow networks make fast networks blazing, because it's a network first strategy, those with very good internet speed will not notice anything different.
2. Resilience is Universal: Power outages might happen in Silicon Valley too.
3. Future-Proofing: Today's edge case is tomorrow's standard requirement. We don't know maybe tomorrow we will use these apps in the moon, in the space, in Mars, under the Ocean 's Abysses
4. Global Market Access: Billions of users are in emerging markets

Beyond Madagascar

There is so much devices in the world, I have particularly noticed users that have more than one smartphone when double SIM wasn't that popular. Some of them uses a phone with an Orange SIM because they give unlimited Facebook for a day for a certain amount, and another phone with a Telma (Yas) SIM because the network is cheaper for every Mb consumed. But these patterns apply everywhere in a lot of different situations:

• Rural Areas: Spotty coverage in developed countries
• Transportation: Subways, flights, tunnels
• Emergencies: When infrastructure fails
• Cost-Conscious Users: Those managing data budgets

Wrapping Up

Twenty years after struggling to download files in Madagascar, the core challenges remain remarkably similar. But now we have better tools and strategies to handle them. The key insights:

Building truly resilient web applications requires embracing the reality that good networks are the exception, not the rule. Whether it's a specific country challenging infrastructure or a subway tunnel in New York, our apps should work everywhere, for everyone.

This strategy consists on three main steps :

Get once : get the app once

Always works : cache everything for work offline

Update if possible : update only if you are sure to be able to make a full update

This is not the perfect solution, but it is what it is. Switching frow the two network environment really taught me one lesson :

Some innovations emerge from the toughest conditions. Progress begins when open tools empower everyone, everywhere.

See you next time! 🌍