Support for private & public url
Is your feature request related to a problem? Please describe.
Currently it's only possible to set one value for the configuration field "URL". On some setups the url called by the server is not the same as the browser (example: In a k8s cluster we have internal domains and we can close the connection to outside of the pod).
Describe the solution you'd like (not working)
One solution could be to use the private/public runtime configuration. Here an example (nuxt.config.ts):
export default defineNuxtConfig({
//...
runtimeConfig: {
directus: {
url: '',
autoFetch: true,
autoRefresh: true,
},
public: {
directus: {
url: '',
autoFetch: true,
autoRefresh: true
},
},
}
});
Describe alternatives you've considered
The current alternative is to manipulate the DNS of the pod to redirect to the right server. But it can be really painful when dealing the SSL certificates.
Additional context
Thank you for your help. I wish you a lovely day :)
@crbast Hi, is it works well by your runtimeConfig that you mention it?
Hello @Mirgfx , no, currently only the "public" value is used on the nodejs process & browser process. I just put this code as the potential expected solution. I wish you a lovely day :)
I don't have time yet to propose a fix but the issue could be fixed in the file https://github.com/Intevel/nuxt-directus/blob/main/src/runtime/composables/useDirectusUrl.ts
By checking the value of config.directus.url & config.public.directus.url depending of the runtime.
If I have time in some days I will do a MR but feel free to propose your version :)
Indeed, this is one of the many refactors that were taking place for the next major.
There still is an old pre-release nuxt-directus-next based on the sdk that did have various new features. I was hoping for some free time to work on that during jan, but looks like I'll need to push it further to mid/late feb, at very least ☹️
If you primary concern is latency then as long as the pods and clusters are correctly configured they will route the connection internally even when using the domain configured in your ingress. This applies both for k8s as well as docker deployments