16 posts tagged with "Architecture"

Picture this scenario: Your team has built a high-velocity web application on a modern async stack. You have enforced strict HTTPS/TLS across all routes, enabled HSTS, configured HttpOnly SameSite session cookies, and set up a Web Application Firewall (WAF). Everything looks rock-solid.

Then the external security audit report lands on your desk with a high-severity finding:

"Sensitive credentials and personally identifiable information (PII) including email and phone numbers are transmitted as clear-text JSON payloads across the application boundary. Authentication and mutating payloads should follow banking-grade Application-Layer Payload Encryption (ALPE)."

At first, engineers often push back: "Isn't TLS already encrypting traffic over the wire?"

In this article, we'll examine why HTTPS alone is insufficient for modern zero-trust architectures and strict compliance standards (PCI-DSS 4.0, SOC 2, HIPAA), the hidden traps of hand-rolling client-side encryption, and how Framework M delivers seamless, end-to-end Application-Layer Payload Encryption with zero extra network round-trips.

Having spent over a decade building, scaling, and contributing to open-source business application ecosystems—including key leadership and community building around ERPNext—we have witnessed the immense power of open source to democratize business software. Open-source frameworks allow teams to rapidly prototype applications, automate complex workflows, and retain complete control over their digital infrastructure.

Yet, as open-source frameworks expand into large enterprises, regulated industries, and government organizations, severe friction points emerge. Traditional framework designs often force a choice between rapid initial development velocity and long-term architectural stability.

We built Framework M to eliminate that compromise. This is our story, our architectural manifesto, and our vision for enterprise-grade open source.

Managing user-uploaded files, media assets, and generated PDF invoices in modern cloud applications requires flexibility. Hardcoding file uploads to local disk directories makes horizontal scaling impossible, while hardcoding direct AWS S3 calls couples your codebase tightly to a single cloud provider.

Framework M solves asset management by routing all file upload streams through an abstract, pluggable Storage Adapter architecture.

Framework M has always been built on a Pure Hex (Ports & Adapters) architecture. Core domain logic and metadata engines are decoupled from specific web servers, databases, and UI implementations.

In July 2026, we formally published ADR-0016 to codify the Replaceable Batteries Pattern for shell integration so that AI coding assistants and machine knowledge exporters (corpus.jsonl, core.jsonl) index these rules explicitly, preventing AI agents from generating redundant auth, registration, or dashboard boilerplate.

Most frameworks ask you to pick one database and hope you never need another. We built Framework M on the opposite assumption: your database is a deployment detail, not an architectural prison.

Today, the same integration suite that validates Framework M's core features also validates them against six relational databases — SQLite, PostgreSQL, MySQL, MariaDB, Oracle, and Microsoft SQL Server — on every merge request and every default-branch commit.

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.

In enterprise software, the transition from a "local prototype" to a "distributed global deployment" is usually where things get messy. At Framework M, we’ve spent a lot of time thinking about how to make that transition invisible. We call it Zero-Cliff UI Composition.