How are we going to maintain performance if UI is now going to use a service API for all the data to be rendered?

the UI service is just used to serve static content - This is mainly a CDN - the data will be obtained through the DX API built as micro-services (Project fnx)

Really excited about Preview Panel. It is going to be a game changer and it is simply awesome. Could you please also enlighten us about performance impact in real time user experience?

Click on the preview button, will open the case object in the preview panel – the performance impact is similar to opening the same case in the main browser window.

How are we keeping business logic out of the UI when certain fields are visible, required, etc. based on values from other fields?

Visible when and required when will still be supported - but when rules are defined outside of the view – By business logic in the UI, we are referring to using action sets with data transform or activities that are used to show / hide elements in the UI

Would this affect the filesystem space and configurations on the app server/jvm? If so, in what ways? Also, any considerations for infra functions node autoscaling etc.?

Using stateless apis and micro-services will significantly improve autoscaling

React

When the React version changes, can that be easily updated in Pega?

The React version will be bundled with the platform. Similar to other 3rd party lib shipped in the platform, we will upgrade the React version regularly and hotfix for security issues

Are we planning for client-side state management e.g., Redux etc.?

yes - the current implementation of the Constellation orchestrator uses Redux and RXJS for state mgt and to maintain as much as possible of the state on the client side. The DX API is stateless and as such most of the state is now maintained in the client.

Cosmos: Pega UI rules are converted to React code in the server side through the Constellation engine and finally the React code is rendered in client side. Is this statement correct?

No – rules contain the model – the model is sent to the client using the DX API – the model is interpreted by the core UI layer to render React components

Is the current Cosmos user portal built on React UI?

No - Cosmos Rules available since Pega 8.3 is using the current Pega Infinity UI technology and is using sections and skin. This was provided to make it easier to move to the Cosmos Design system

If everything is going through service calls, is it safe to say that we don't need to configure HA and passivation settings as there are no requestors involved in a complete Cosmos system?

Yes – there will no longer be needed to configure requestors in the future… but like any micro-services, there might still need to provision for auto-scaling

What does Client refer to? Is it a browser, how can I make runtime orchestrator available on the browser?

Yes - Client is your browser. The orchestrator is a JavaScript library to process the response and renders the UI dynamically from the model.

Is Cosmos tightly coupled with React technology, so in near future if some more advanced UI technology comes in future, how easy it will be to change?

No – Cosmos design system is currently implemented as React components – other rendering framework could be used in the future.

Is Cosmos built on React then?

Cosmos is the Pega Design system. It has 2 implementations: Cosmos Rules is the implementation that was released in 8.3 and is still using section / harnesses and the Pega Infinity UI rendering engine. Cosmos React is available in 8.5 as a preview.

Is Cosmos currently using DX API?

Cosmos Rules is not using the DX API - it is using the current UI rendering technology - React Cosmos will only use the DX API v2