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 >
