Ask Questions and Find Answers

Hello,

since we have a problem deploying just the configurations for our (frontend) client-extensions into our Liferay PaaS, we opened a ticket (103969) regarding this topic. At the moment, we (theoretically) just have the possibility for ci/cd to deploy the config over lcp deploy, but this will lead to a new starting service in PaaS - which is not the expected behaviour.

The ticket is still under investigation, but we had a neat idea to solve this problem, thus I got requested to create a feature request on this. I will provide parts of the ticket to explain the situation and the requested feature

---

For our developed react applications, which we want to implement into Liferay as custom-element client extensions, we need to setup a CICD. In this process we need to deploy the client-extension configuration and/or changes of the configuration to our specified liferay instance/s.

We don't want to create a service or something, we just need to get the configuration imported.

Furthermore we don't want to have the single react applications in the "base" liferay repository and don't want to have the instance to be restarted just because of an add/update by client-extension config. That's why we also don't want to have the LUFFA files in this repository too, as we want the react apps to be decoupled from the "native" liferay services and so on.

We don't necessary need a CLI based solution like the LCP CLI Tool, since we just need to add/change/delete a configuration for client-extensions. Another approach which (in my mind) could be a simple, yet sufficient solution, could be a rest endpoint. Since Liferay deeply uses the headless rest api for many cases already (e.g. object definitons, objects, ...), it would be neat to have endpoints for client-extensions, which uses Post, Put, Patch, Delete. This way we could easily handle our deployment process and overcome the problems we actually encounter.

Furthermore (maybe this helps in your investigation on this) I found out, that on the jsonws api there is a path on which I see functions for CRUD of client-extensions. The end of the path would be: /api/jsonws?contextName=remoteapp.
Example: https://the-liferay-instance.com/api/jsonws?contextName=remoteapp

With regards to consistency in our projects and deployment, we nonetheless would like to avoid using jsonws and a rest endpoint would be much appreciated.

Thank you very much and best regards,

Andreas