11 posts tagged with "Architecture"

In enterprise environments, database choice is rarely a developer's preference—it is often a strict organizational mandate. Whether it is a legacy Oracle database, a standardized SQL Server (MSSQL) cluster, or a specialized MySQL configuration, frameworks that lock you into a single database engine are a non-starter.

When we designed Framework M, we focused heavily on providing out-of-the-box support for PostgreSQL and SQLite. For completely different databases (like MongoDB), we introduced the MX Adapter Extension Pattern, allowing developers to completely swap out repository and transaction protocols without forking the framework core.

Today, we are taking this composability a step further. We have refactored our standard SQLAlchemy database adapters to support the Hybrid MX Pattern, allowing developers to connect any official or unofficial SQLAlchemy-supported database engine to Framework M by subclassing standard components and overriding only the dialect-specific parts.

Think about your daily workflow in Google Workspace or Microsoft Azure. In the top-right corner, you click your profile picture and switch instantly between your personal account, your work account, and a client’s tenant—all without logging out.

Users have come to expect this seamless, multi-account profile experience in modern web applications. Yet, if you look at the product backlogs of most enterprise SaaS startups, you will find that multi-account profile switching is deprioritized to 'never.'

In this article, we’ll look at why this feature is so hard to build from scratch, how open-source identity providers like Zitadel are driving this requirement, and how Framework M makes supporting it as simple as flipping an environment variable flag.

Hierarchical data is everywhere in business applications—from organizational charts and product catalogs to tasks, nested comments, and ledger accounts. Yet, representing tree structures in a relational SQL database is a classic engineering trade-off between write performance, read complexity, and storage overhead.

In this article, we'll walk through the evolution of tree strategies in Framework M: how we moved from a Frappe-inspired Nested Set model to a pluggable Strategy Pattern supporting recursive CTEs, and how this architecture paves the way for specialized document and graph repositories.

In modern web development, background jobs and scheduled tasks are the backbone of asynchronous operations—handling everything from daily email reports to outbox processing and periodic data cleanups.

However, running scheduled tasks (cron jobs) reliably in a clustered, high-availability (HA) environment is a notoriously difficult problem. Traditionally, developers have had to choose between heavy distributed locking protocols or complex, stateful leader-election daemons.

WebAssembly (WASM) and browser-based runtimes like Pyodide are quietly redefining the boundaries of application portability. Running full-stack, enterprise-grade Python frameworks directly inside the browser—with zero server costs, instant boots, and offline-first capabilities—is no longer a theoretical exercise. It is reality.

But porting database-driven applications to the browser sandbox exposes a massive "productivity cliff" where traditional server-side tools break down. Among these, database schema migrations present one of the most stubborn hurdles.

Here is how we bypassed the typical runtime hacks to implement first-class, dual-mode migrations inside Framework M using clean, decoupled architecture.

WebAssembly (WASM) and browser-based runtimes like Pyodide are quietly rewriting the rules of application portability. Running python-based backends directly in the browser—with near-native speeds, zero server cost, and instant startup—is no longer a futuristic dream. It is here today.

But running enterprise-grade python frameworks in WASM comes with a major catch: C-extensions are a brick wall.

Recently, I decided to test the limits of Framework M's portability. My goal was simple: get our entire modular monolith booting directly inside the browser using Pyodide.

The result of that experiment taught me one of the most powerful, real-world lessons about the true beauty of clean, decoupled architecture.

Every modern cloud provider and SaaS company is trying to sell us the same story: your software must live in the cloud on Day 1. You need a Kubernetes cluster, a managed database subscription, a global CDN, and a four-digit hosting bill just to get started.

But let’s be honest: 90% of real-world businesses don't care about the cloud.

Why would a restaurant owner, a factory operator, or a local service provider spend a single second thinking about database connection pools or server maintenance? They are focusing 100% of their energy on physical operational challenges. The cloud is the absolute last thing on their minds.

Yet, the tech industry forces a single, dogmatic path: mandatory, lock-in cloud rent.

As engineers, our job isn't to build fragile sandcastles that require constant, expensive cloud maintenance to stay standing. We build digital castles that last for centuries.

To support these businesses from Day 1 with a zero-cost, zero-latency, zero-maintenance sovereign setup, we built Business Local—packaging our entire Monolith stack inside a native Tauri wrapper that runs fully offline.

But as we refined this architecture, a breathtaking new spectrum opened up. If you write your business domain logic once, why shouldn't you be able to run it anywhere across a seamless continuum—from a micro-minimalist IoT edge controller processing transient MQTT events, to a sovereign offline laptop, all the way to mega-scale hypervisor clusters in the cloud?

To unlock this absolute scaling sovereignty, we have shipped a major new architectural capability: 100% Stateless & Database-Free Boot Mode.

In our last post on Transparent UI Macroservices, we talked about the "what": breaking a monolithic frontend into independent, deployable units without breaking the user experience.

But as soon as you move from two services to ten, you hit a new wall: The Discovery Cliff.

How does the shell know where the finance service lives today? How does it find the inventory remote entry on a developer's machine versus a production Kubernetes cluster? And how do we do this without a 400-line configuration file that needs to be updated every time a port changes?

Today, we’re introducing the Discovery Oracle.

Two weeks ago, we introduced the concept of Zero-Cliff UI Composition. We shared our vision for a progressive architecture where your code remains the same whether it's a monolith or a distributed suite.

Today, we are taking the next step: UI Macroservice Decomposition.

A question I keep running into when talking to developers:

"Can we deploy modules separately and manage them independently—like microservices?"

My answer is always: "Yes—if designed that way."

But that answer deserves a much longer conversation. So here it is.