Goals / vision of the project

Gergely Kis 1
Viewed 19

Hi @Revant,

I have been following your awesome work in the Frappe Ecosystem for quite some time now, and this new project is very interesting as well.

Even in its current state it seems to be fixing many issues with Frappe (e.g. database independence, document immutability, modern frontend).

I also found the business-m repo, which seems to be a start of the business suite that parallels ERPNext.

I see huge potential in this project, but before diving into it deeper, I would like to gather more information.

Could you please elaborate on what your vision is of the project, why did you decide to start a completely new project instead of trying to fix the issues in Frappe ... etc.?

Thank you,
Gergely

vision
1 Answers

Hi Gergely,

I’m glad you’re digging into the repos! To answer your question, the core vision for Framework M is to be a "zero-cliff" framework.

I wanted a tool where you can build an app with extreme velocity on Day 1, but completely trust it to scale on Day 100. In many "batteries-included" frameworks, you eventually hit an architectural wall where the framework's "magic" starts working against your custom needs. Framework M is designed to let you reach down into "framework-level" logic from your custom apps so you never hit that cliff.

Why a new project instead of a Frappe refactor?

I have immense respect for Frappe; the developer experience (DX) of getting CRUD, UI, and an API out of the box from metadata is world-class. However, Frappe’s architecture is a reflection of the best practices of a decade ago. To bring it into a modern, async, headless era wouldn't just be a "refactor"—it would be a ground-up rewrite that would unfortunately break the entire existing ecosystem.

Here’s why I felt a fresh start was the most responsible path:

  • The Async Shift: Moving from synchronous Python to async/await is a fundamental change. It would require rewriting the entire ORM and every DocType controller, which would be an impossible migration for current Frappe users.
  • Modular Monolith vs. Tight Coupling: Frappe is an incredible monolith, but it’s tightly bound to its infrastructure. Framework M uses a Hexagonal Architecture (Ports & Adapters). This lets you swap out things like the database or the event-bus (using NATS, for example) without rewriting your business logic.
  • Embracing Global Standards: Rather than re-inventing components internally, I wanted to build on top of massive, independent open-source communities. Using React (refine.dev), SQLAlchemy, and Alembic ensures that Framework M stays compatible with the broader tech industry’s trajectory.
  • The Headless Future: By decoupling the frontend entirely, we gain the flexibility of a modern stack without being tied to legacy JS or Jinja patterns.

Framework M isn't about "fixing" Frappe—it's about taking the brilliant DX that Frappe pioneered and applying it to a modern, horizontally scalable, and headless enterprise architecture. I’ve spent years working with Frappe, and this project is really the culmination of everything I’ve learned about where the next generation of business software needs to go.

I'd be happy to dive deeper into any of these architectural choices if you're interested!

Revant Nandgaonkar1
Related