Hi, Thank you for the detailed reply. These are exactly the kinds of discussions I was hoping to have, and you raised several important points that I hadn't fully considered.
I think the question you asked at the end: "What pain point are you trying to address?" is probably the most important one. My motivation is not only about reducing the amount of data transferred over the network or optimizing mobile bandwidth. The bigger pain point I've experienced while building the PWAs for the manufacturing component is the developer experience. As I build new screens, I often find myself thinking about what new REST aggregation endpoint I need to create. Different screens require different combinations of the same business objects, which naturally leads to creating more UI-specific APIs over time. My thought was whether there could be a more flexible composition layer on top of OFBiz that allows applications to retrieve only the data they need without introducing another aggregation endpoint for every new use case. I completely agree that simply placing GraphQL on top of our existing aggregation services would not provide much benefit. As you pointed out, the entire service would still execute, so the backend work would remain the same. One thought that crossed my mind (and this is just brainstorming) is whether GraphQL resolvers would necessarily have to invoke services for every query. Perhaps there could be a hybrid approach: - GraphQL queries could, where appropriate, use carefully controlled read-only access through the Entity Engine or view-entities for data retrieval. - GraphQL mutations would continue to invoke OFBiz services so that business logic, validations, transactions, SECAs, and other framework features remain intact. Of course, this immediately raises the questions you mentioned around permissions, query complexity, N+1 problems, and performance. I certainly don't have answers to all those questions yet, and they would require discussion before such an approach could ever be considered practical. At this stage, I'm not advocating for GraphQL as a replacement for REST, nor do I have a concrete implementation proposal. I'm mostly trying to understand whether there is an architectural direction that could make OFBiz an even better platform for building modern PWAs, mobile applications, dashboards, and AI applications while continuing to leverage the strengths of the existing service layer. Thanks again for taking the time to share your thoughts. They definitely helped me think about the problem from a different perspective, and I'm looking forward to hearing what others think as well. Regards -- Divesh Dutta www.hotwaxsystems.com On Mon, Jul 6, 2026 at 1:56 AM Konstantinos Marinos <[email protected]> wrote: > > Hello Divesh, > > > i think the idea of first party support for graphQL in OFBiz is interesting. As you mentioned it shines in the mobile, PWA, multi-client world with distributed, headless backend services. Additionally being able to query the schema directly offers a great developer experience. However in my opinion, the road towards this adoption will not be short or easy. > > > GraphQL is famous for its N+1 query problem and simply mapping over services will not make it trivial to avoid this pattern here as well. In addition, graphql would only be saving data "on the wire". Even if you request one field of a service, the whole service would need to run, executing all queries and downstream services completely, since the service engine wouldn't have a way to "know" what part of the implementation is necessary to correctly return the value requested, and ignore the rest or exit early. Same goes of course for SECAs. Similar issues arise if you wanted to enable graphql for entity querying only. > > > In combination with the point above, GraphQL Mutations would create new ways of combining services that could cause serious performance issues on the backend, create cyclic references and even end up DoS-ing your own application. Unfortunately i currently have no good ideas on how to prevent such a scenario. > > > GraphQL allows you to jump through entities and fields by deep nesting queries. How does the permission concept of OFBiz work in this case? I feel like creative queries and pathways would make it trivial to ignore boundaries and access data that the current user isn't allowed to access if they were accessing them directly. > > > These are some of my initial thoughts and to not make my reply even longer i won't expand any further. As a final point, i would like to ask you what pain point specifically are you trying to address with GraphQL? If you are trying to optimize the data access of mobile apps, maybe the BFF pattern (Backend for frontend) or similar API Gateway solutions with REST might already offer significant benefits, without the technical complexity of adjusting the service and entity engine to fit graphQL. > > > Thank you for bringing this idea up for discussion. As always, I would also be interested to hear everyone's thoughts on this. > > > Best regards, > > Konstantinos Marinos > > On 2026/07/04 13:59:13 Divesh Dutta wrote: > > Hello everyone, > > > > Over the past few months, while building standalone PWA applications on top > > of Apache OFBiz I've been thinking about our API strategy and wanted to > > share an observation from my implementation experience. > > > > I believe our current direction of exposing REST APIs backed by OFBiz > > services is the right foundation. The business logic remains encapsulated > > within OFBiz services, while REST APIs expose well-defined business > > operations for external applications. > > > > However, as I build more UI screens, I've noticed that many pages require > > data from multiple business domains. For example, an order screen may need > > information about a customer, a product, and inventory. There are generally > > two approaches today: > > > > > > - Make multiple REST API calls and compose the data on the client. > > - Create a dedicated REST endpoint that aggregates everything required > > for that particular screen. > > > > > > Both approaches work well, but as we build more PWAs and different clients, > > we may gradually end up with many UI-specific aggregation APIs. Different > > applications like PWAs, mobile applications, dashboards, and AI agents > > often require different combinations of the same business objects. > > > > This made me wonder whether exploring GraphQL support in OFBiz would be > > worthwhile. > > > > The GraphQL server would simply orchestrate existing OFBiz services, while > > all business logic would continue to reside in the service layer. > > > > The main benefit would be that clients could request exactly the data they > > need in a single query. This would reduce multiple network calls, avoid > > over-fetching unnecessary data, and provide a strongly typed, discoverable > > API for developers building applications on top of OFBiz. > > > > As OFBiz continues moving toward API-first development and standalone > > applications, I think this could be an interesting capability to explore. > > > > I'd be interested in hearing the community's thoughts on a few questions: > > > > > > - Would it make sense to prototype GraphQL support as an optional plugin > > first, allowing the community to evaluate its usefulness? > > - If the idea proves valuable, should GraphQL support eventually belong > > in the framework itself, or should it remain an optional plugin? > > - Has anyone previously experimented with GraphQL integration in OFBiz > > or evaluated similar approaches? > > - Are there architectural considerations or challenges that should be > > taken into account before exploring this direction? > > > > > > I'd love to hear different perspectives from the community. > > > > Thanks > > -- > > Divesh Dutta > > www.hotwaxsystems.com > >
