Dear All,

We are using traditional dxAPI (v1) to render UI elements in a separate tier. Constellation dxAPI (2), so far, is not a valid option in our case as it has limitations for CRM applications we are using.

We are facing a major issue from dxAPI with response time exceeding acceptable values. In fact we have noticed:

• Case creation : 0.5 to 1 second average time
• Action on case : 2 seconds average time (GET /api/v1/cases/{case ID}/actions/{action ID})

We have already tunned dxAPI with DSS : v1DXAPIFUA=true and v1DXAPIFUAMode=rule-update

Unfortunately, that's not enough yet to get acceptable results in the perspective of generalizing dxAPI to all our use cases.

My first question: are there projects using dxAPI to render UI elements? What experience can be shared across these projects?

My second question: dxAPI is based on a stateless mechanism (reload of case context each time), which causes any case context to be rebuilt at every api call. That is one of major limitations to have a fluid experience between UI and Data. It also can influence any move to microservice architecture in the future. Do anyone share our concern on that ?

My third question is related to traditional dxAPI (v1) section based : the case sections we manage are divided into portions that can be combined to be used at several stages (modular sections, reused as section-include). The FUA engine that generates JSON for dxAPI is likely to spend time rebuilding the entire UI and Pega team advices us to not use nested sections for dxAPI. But we don't identify the good practice to keep UI complete, modular and performant. Have you faced the same concern and what were your choices?

(we are under Pega 8.7.4 and we are using webComponent which defines the UI elements entirely for Front-End)

Many thanks to anyone who can give guidance or share his experience.

Halim