"Serving a clear single purpose " ⚗️ Kahiether services
Innovating is a journey🛣️
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, andindex.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:
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.✨