We have a PWA solution running with lib-static, in a different vhost, which needs to poll the standard solution through a service in order to get the newest alert info from a content (the service just gives the site-specified content’s title and text). So far we managed to get this working, but the polling call has to be done using the origin’s absolute url.
I’d like to use a relative or more “safe” url, as nowadays the polling call shows the full server admin url. Can it be done?
Ok, so just to make sure I understood your setup correctly…
You have two apps, on two different domains, and one of them is polling a service in another one. Is that correct? How do you generate url of the service in the second app? Pretty much all of our url generation API methods have type parameter where you can specify that you need an absolute url, f.ex. serviceUrl. I would also fix it so that polling only happens in “live” mode.
Thanks for the quick response.
Yes, they’re two solutions. The PWA one is just react (built with react-scripts) embedded with lib-static in an Enonic app. This is served in a service which is vhosted (alongside nginx) to another url.
The polling service url is simply set as server/_/service/enonicAppName/serviceName in the PWA’s env file and, besides security reasons, it’s quite cumbersome to build for all the servers.
We’re not using the serviceUrl as the PWA needs to be built beforehand in order to be accessible in the Enonic build process.
I admit I may be missing something very simple here. So far, I had ideas with get and buildGetter, though I only guess they can work together, and with mapping plus (maybe, don’t know yet if it’s necessary) vhost.
Why? You can call serviceUrl any time, as long as the app containing the service is actually present in the same XP instance. Normally you should not hardcode service url but let XP generate it for you as it takes into account things like vhost and app name.
But what was the original problem? What did you mean by “using a relative or more “safe” url”? If your service is on a different domain then you obviously cannot use a relative url to access it.
The PWA solution is currently non-Enonic react, built with react-scripts. This output is thrown inside the Enonic app structure, under resources, then accessible through the lib-static. Would it work to set up Enonic calls inside the PWA then?
The problem is that the service serving lib-static buildGetter (calc) is mapped to a second url, but still needs access to another service (updater) that currently is only possible through the server’s admin url, which I’d like to avoid leaving out in the open. I may be overthinking it, as perhaps a simple mapping in site.xml should be able to enable a friendlier url to this service (updater).
Yesterday I was told about a PWA starter, using webapp, and perhaps this would be the way to go, but we lack the budget for the moment, unfortunately.
If you are not using serviceUrl then there’s really no point in using a service.
Maybe I still misunderstand your setup, but you can set up a controller mapping of a simple url (like server/myendpoint) to your current service’s logic (which you now have at server/_/service/enonicAppName/serviceName).
The service solution was just as a way of providing an endpoint. In the end, I had a controller mapping set-up so at least the admin urls are not in the open.
In the future I intend to move it, as suggested, into a webapp.
It’s probably worth mentioning that we are currently working on a new Webapp starter with PWA capabilities. The PWA starter we have now is more of a demo app than a starter. The new one is going to be React-based and it’s going to be a pure starter (with no or minimal samples included).