Best strategy for maintaining NextJS PWA and Vue 3 client in the same Caddy configuration on the same domain #2381
Replies: 3 comments
-
Hi and thanks for the kind works! In my opinion, serving everything from the same domain simplify everything and increase performance. Could you share what was the problem with Caddy when following this strategy? Note they depending on how you deploy your app, you can also configure the routing at the ingress level (for instance if using Kubernetes) if more relevant. Also, you’re using both Next and Vue in the same project? Wouldn’t it be easier to switch from Next to Nuxt or from Vue to React to simplify the code base and have everything server from the PWA? Cheers, |
Beta Was this translation helpful? Give feedback.
-
Hi @dunglas . Good morning and thank you very much for your reply! Yes, serving everything from the same domain has been noticeably quicker in some of the tests I've done and what you've written in your article makes total sense. I call it philosophy because we recognise a lot of out of the box thinking inside the entire API Platform and its documentation, where design decisions have taken a different angle to other frameworks (e.g. ADR pattern - makes total sense!). I digress... but suffice to say, we really like API Platform!
When trying to follow this idea (relating to point 1 above), the "Vite App" renders as a white page, but I can see the HTML when inspecting the source and the built css and js have also come through (albeit as HTTP 302). The console message reads as Here's the associated
Excellent!! I've thought of this too and I think the idea would be to go with (a) a single server block in Caddyfile like it was before (b) the
We like how you've built Since we had already started making data-driven (loosely coupled with the backend) components with Vue and Tailwind, it made sense to keep what we have and only update the areas affected by recent changes in Vue 3, Pinia and Composition API. Thanks again! |
Beta Was this translation helpful? Give feedback.
-
Hi ! |
Beta Was this translation helpful? Give feedback.
-
So this is about having my cake and eating it - wanting it all in one.
API Platform 3.x is a big improvement, not forgetting the efforts everyone has made with the client generation utilities etc.
I try not to deviate from Kévin's philosophies as they make sense. I want to make sure the backend (API Platform), the PWA (NextJS) and the generated client (VueJS) are all served from the same domain to prevent all the CORS preflight requests as Kévin describes.
Here's what I tried so far
Vue in subfolder route: This involves using a
handler {...}
statement inCaddyfile
for catching and handling a special route (such as/cx
(for customer experience)) for the Vue client. There were some issues where Caddy was serving the minified/bundled JS file as HTML MIME. I tried to resolve by setting the--base
flag when compiling with Vite. It created the right output, but something wasn't right when running through Caddy. I can investigate this further, but I temporarily ditched the idea.Ignore the philosophy above for Admins (a smaller user group): This involves creating two CaddyServer blocks
$ADMIN_SERVER_NAME
and the original$SERVER_ADMIN
, where the former maintains the@pwa
statement for Admins while the latter serves the static output from Vue. The idea would be to haveadmin.example.com
andexample.com
- yes different domains from CORS perspective. This required using complex regex withTRUSTED_HOSTS
andCORS_ALLOW_ORIGIN
, which isn't a problem, but theMERCURE_PUBLIC_URL
needs to be fixed as the frontends subscribe to this URL.So both of my options are undesirable as I am in the process of rolling out multiple API Platform solutions and I like to keep everything consistent across all projects and also not to deviate from API Platform base. Once I make a decision, it will likely be locked in for a long time.
I'd be interested to hear other people's ideas. The third option is just to deploy the static Vue (dist) assets under a different domain/subdomain and change the CORS settings in Symfony/Nelmio and also
Caddyfile
and be done with it (as I think this is what was intended), but it leaves me wondering as I like the idea of Vue not needing to make pre-flight requests, particularly when we're expecting thousands of active users per month.Thoughts welcome.
Beta Was this translation helpful? Give feedback.
All reactions