Hi everyone, Over the past few weeks we’ve had some very valuable discussions on the mailing list about the future direction of Apache OFBiz, including topics such as modularization, API-first architecture, and making applications more independent from the framework.
Several people have pointed out that while Apache OFBiz has strong capabilities, the current codebase still behaves largely as a monolithic system. Ideas such as gradually separating subsystems, improving boundaries between components, and enabling more modular deployment models have come up repeatedly. I wanted to propose a practical experiment that could help us explore these ideas concretely. *Proposal: A New Headless, API-First Manufacturing Application* The idea is to build a new Manufacturing application as a plugin in the OFBiz plugins directory. This new application would aim to replicate the functional capabilities of the existing Manufacturing component, but with a modern architecture approach: - API-first - Headless - Framework-independent application layer - PWA-based user interface The goal is not to replace the current manufacturing component immediately, but rather to create a working reference implementation that demonstrates how modern OFBiz applications could be built going forward. This could help illustrate how OFBiz can operate as: - A backend enterprise automation framework - with applications built as modular plugins - and UI layers decoupled from the backend *Why Manufacturing?* We recently documented the Manufacturing application and its workflows, contributing them to the OFBiz wiki. This process gave us a solid understanding of the domain. Because of this domain knowledge, Manufacturing felt like a good candidate for a reference implementation that could help validate architectural ideas while also producing something useful for the community. *Proposed Phases* To keep the scope manageable, the work could be broken into incremental phases. *Phase 1 — API-First Backend* In the first phase: - Reuse the existing manufacturing services where possible. - Expose those services as REST APIs. - If any workflows currently rely on events, convert those flows into services that can also be exposed via REST. - Test complete manufacturing workflows purely through the APIs to ensure the logic behaves correctly. This phase would effectively produce a fully API-driven manufacturing backend. *Phase 2 — Headless PWA UI* Once the APIs are stable: - Build a Progressive Web Application (PWA) as the UI layer. - The UI will communicate only through the REST APIs. - Validate full workflows through the new UI. This phase would demonstrate how headless OFBiz applications can work in practice. *Phase 3 — Agentic / AI Experiments* In a later phase, we could experiment with agentic workflows, where AI agents interact with the system through APIs. This could include: - Agents invoking OFBiz services - Workflow automation through LLM-driven interfaces - experimenting with emerging agent frameworks The goal here would be to explore how OFBiz can integrate with AI-driven automation systems. *Why This Could Be Valuable for the Community* This effort could serve as a living example of several modernization ideas we have been discussing: - API-first OFBiz applications - Headless architecture - Plugin-based applications - Clearer separation between the framework and application layers - modern UI approaches such as PWA It would also give developers a reference implementation showing how to build modern applications on top of Apache OFBiz. *Development Approach* To keep the process flexible and non-disruptive: - I will initially start development in a personal GitHub repository. - Once the architecture stabilizes and the community finds the direction useful, we could discuss merging it into the OFBiz plugin repository. - I will also create a parent JIRA ticket for this initiative so that tasks can be tracked and broken into smaller child tickets. Additionally, I plan to create a requirements document describing the manufacturing workflows that the new application should support. That document can serve as the baseline for development and discussion. *Request for Feedback* I’d really appreciate feedback from the community on this idea. Some questions that may be useful to discuss: - Does building a reference application plugin feel like a useful way to explore modernization ideas? - Are there architectural considerations we should keep in mind from the start? - Are there other areas where this approach could be useful? My hope is that this can become a collaborative experiment that helps us better understand how Apache OFBiz can evolve while still respecting the existing codebase and community practices. Looking forward to hearing your thoughts. Thanks -- Divesh Dutta www.hotwaxsystems.com
