Moqui Framework Evolution: Balancing Core Data Model Strengths with Modern Frontend Trends

heguangyong · October 15, 2025, 8:03am

Introduction

As a developer deeply engaged in upgrading the Moqui framework, I recently explored its evolution in the context of modern frontend trends, particularly in light of the increasing adoption of frontend-backend separation. Moqui’s strength lies in its robust backend, driven by a set of universal data model patterns inspired by The Data Model Resource Book series (by Len Silverston). These patterns, akin to the GoF design patterns for object-oriented programming, encapsulate industry-proven relational data models for scenarios like ERP, CRM, and supply chain management. They are the “core beauty” of Moqui—timeless, flexible, and generalizable. However, with frontend technologies like Vue3 + Quasar2 gaining traction in 2025, how should Moqui adapt while preserving its unique strengths? This post summarizes a discussion with Grok, an AI assistant, to explore this balance, and I’d love to hear the community’s thoughts.

Moqui’s Core: The Data Model Resource Book

Moqui’s backend is powered by its Entity and Service Engines, which bring to life a set of universal data model patterns from The Data Model Resource Book. These patterns, detailed across multiple volumes, cover industry-specific scenarios (e.g., manufacturing, retail, finance) with standardized entity relationships and constraints. Much like the 23 GoF design patterns provide reusable solutions for software design, these data models offer a crystallized form of human wisdom for enterprise data structures. They enable Moqui to deliver:

Universality: Predefined models (e.g., Party, Product, Order) support diverse industries with minimal customization.
Flexibility: XML-based entity definitions and Groovy-driven logic allow dynamic extensions (e.g., EECA/SECA rules).
Stability: Relational models are timeless, unlike the fast-changing frontend landscape.

This backend strength is Moqui’s differentiating factor, ensuring robust integration with databases, message queues, and authorization systems. It’s the foundation we must protect during any framework evolution.

The Frontend Challenge: Navigating Trends

Frontend technologies are inherently volatile, driven by trends that shift every few years (e.g., from AngularJS to React to Vue3). In 2025, Vue3 + Quasar2 is a popular choice for its reactivity, TypeScript support, and cross-platform capabilities (SPA, PWA, mobile, desktop). However, adopting such frameworks in Moqui raises questions:

How do we integrate modern frontend trends without diluting Moqui’s low-code philosophy?
Should Moqui’s Screen/Widget system, built for server-side rendering and session-based applications, be replaced or retained?

My perspective, refined through discussion with Grok, is that Moqui’s frontend should serve as a flexible “connection layer” to its backend, embracing trends like Vue3 + Quasar2 while preserving the option to use Screen/Widget for traditional, low-code scenarios.

Proposed Strategy: A Dual-Track Approach

To balance Moqui’s core strengths with frontend evolution, I propose a dual-track approach:

1. Retain Screen/Widget for Traditional Use Cases

Moqui’s Screen/Widget system, based on FreeMarker and XML, is a powerful low-code tool for generating CRUD interfaces and internal tools. Its tight integration with the backend (leveraging the data model patterns) makes it ideal for:

Rapid prototyping of enterprise applications.
Session-based workflows (e.g., SAML/OAuth-integrated dashboards).
Teams with limited frontend expertise, as it requires minimal JavaScript knowledge.

Rather than phasing it out, we should maintain Screen/Widget as a stable option, potentially enhancing it with modern CSS frameworks (e.g., Tailwind) for better aesthetics while keeping its server-side rendering simplicity.

2. Embrace Vue3 + Quasar2 for Modern Frontend Needs

To align with 2025 trends, Moqui can adopt Vue3 + Quasar2 as a recommended frontend for projects requiring modern UX or cross-platform deployment. Key advantages include:

Rich UI Components: Quasar2 offers Material Design-based components, animations, and responsive layouts, enhancing user experience.
Cross-Platform Support: Build SPAs, PWAs, mobile apps (via Capacitor), or desktop apps (via Electron) from a single Vue3 codebase.
Community Appeal: Vue3’s popularity attracts frontend developers, addressing Moqui’s smaller community size.

The vue3quasar2 branch in Moqui 4.0 (as of May 2025) is a promising step, integrating Quasar2 into moqui-framework, moqui-runtime, SimpleScreens, and MarbleERP. This allows developers to replace Bootstrap with Quasar components while maintaining backend compatibility.

Implementation Details

API-First Backend: Moqui’s RESTful APIs (Entity/Service REST, OData support) already enable seamless integration with any frontend. Standardizing API contracts (e.g., via OpenAPI) ensures flexibility for future framework switches (e.g., to Svelte or Qwik).
Frontend Modularity: Develop a plugin system (like moqui-quasar) to encapsulate Vue3 + Quasar2 as an optional module. This allows teams to choose between Screen/Widget and modern frontends without breaking the ecosystem.
Conversion Tools: Create utilities to map Screen/Widget XML to Vue components, reducing migration effort. For example, a tool could generate Quasar-based QTable components from Moqui entity definitions, preserving low-code benefits.
Aesthetic Evolution: Use Quasar’s components (e.g., QForm, QDialog) to modernize UI while ensuring the backend’s data model patterns (e.g., Party relationships) are elegantly visualized.

Long-Term Considerations: Sustainability and Aesthetics

From a strategic perspective, Moqui’s longevity depends on balancing its niche strengths with broader appeal:

Sustainability: Moqui’s community is smaller than mainstream frameworks like Spring Boot. Adopting Vue3 + Quasar2 can attract frontend developers, while retaining Screen/Widget ensures continuity for existing users.
Aesthetics: The data model patterns embody a “design elegance” through their simplicity and reusability. Frontend choices should reflect this by prioritizing intuitive, responsive UIs that showcase these patterns (e.g., a Quasar dashboard visualizing Order-to-Invoice flows).

Call to Action

I’m currently exploring Moqui 4.0’s vue3quasar2 branch for my upgrade project and plan to test Quasar integration with SimpleScreens. I’d love to hear from the community:

Have you experimented with Vue3 + Quasar2 in Moqui? What challenges or successes did you encounter?
Do you agree with the dual-track approach, or should we lean more toward modern frontends?
Any ideas for tools to bridge Screen/Widget with Vue components, preserving low-code efficiency?

Let’s discuss how to evolve Moqui while honoring its “core beauty” rooted in The Data Model Resource Book. Your insights will shape our framework’s future!

jcigala · October 15, 2025, 5:39pm

Great job! Kudos!

houcun · October 17, 2025, 4:57pm

Great job! Both, New one as components.

michael · October 23, 2025, 9:19pm

I think an important question to ask here is: what are the goals of Moqui’s UI layer?

We currently have an out of the box experience that has hundreds of screens to be used to interact with the Moqui system. I’m sure pretty much everyone using Moqui uses these as a UI to interface with their backend. Then when people build products out of Moqui they either use the xml screen approach, or build their own entirely custom frontend in next.js, quasar, etc.

So then the question is what are the responsibilities we give to the community vs expect product developers to create themselves.

So then the question is what do we do as a community?

Xml screens were initially created to be a low code way to build screens for the Moqui framework, and are a great abstraction that has been used and customized over the years. It primarily being a template engine based on vue 2 and quasar 1 means that it needs to be upgraded at the very least. There has been a lot of effort put into these screens, and keeping them and maintaining is a worthwhile effort with the resources we have.

Now if we’re thinking about the future and how we can build a more attractive system for people to use, we would have a base level of UI widgets, components, and screens that are composable and used at for the backend screens, but are flexible enough to be used in most production ready products built on top of Moqui. That would give a significant productivity boost to anyone building a business application. Moqui would work out of the box as a scalable API layer with reusable components to hit the ground running with any project. An example of this is how many order history screens have each of us built? What if we had the groundwork of an order history screen layed out, and we could use it in our products and if there’s problems we contribute back to core. Then there’s less seperation between the products built on Moqui and the core community and aligns incentives and resources.

At the end of the day, Moqui xml screens get rendered into vue components in the DOM, so mixing the xml widgets and vue components would be a data passing, project formatting, render mode, and syntax problem. But they could totally be mixed if there was enough effort put into it.