[2.x] Add Inertia SSR Support #1012
Conversation
|
@xiCO2k I guess we could also port the same option to Breeze now. 😅 |
|
Count me in :) |
|
Hi! Maintainer of Ziggy here. Running Not sure who the best person is to answer this question, but could we cache it? Like can we use @xiCO2k is there any way to tell on the server if Inertia is running in SSR 'mode' so we don't generate Ziggy's routes unless it is? I assume in SSR mode it doesn't matter if it's a bit slow because all the pages are 'visited' and rendered in advance, right? |
Hey, normally if Edit: sorry you probably asking on Check: https://github.com/xiCO2k/franciscomadeira.com/blob/main/app/Ssr.php Cheers |
|
@bakerkretzmar I've made a note of this and will take a look at what we can do. Happy for someone else to jump on it, but i'll circle back shortly and see what we can do. |
|
Hey folks, I spent some time looking at this today. My initial feeling is that if we introduce caching it will have flow on effects around the development and deployment story, which I don't love the idea of. We would have to only cache in prod to not impact local development, and then we'd also have to bust the cache on deployment. We also push everything out to user-land, so if this does become a performance issue (which won't be the case initially as Jetstream / Breeze are meant for new projects), the individual project can introduce caching in their own applications. I believe we still need to generate the routes in SSR and non-SSR as the SSR generated pages can still utilise the I wonder if the performance implications of Ziggy with a large routes definition could be written up on the Ziggy docs for users that do end up hitting the issue and some potential solutions? I'm not calling any shots here btw, just my thinking after taking a quick look - so very open to discussion and push back. |
|
That sounds good to me, I can work on adding some notes on this to the Ziggy docs. It's come up a few times in discussions/issues so it's definitely worth writing up properly. I'll think about better ways to only run this once, too. In most apps I'd just suggest using the |
|
In a non-SSR request, we would have a single request come through and do... <head>
@routes
</head>Nothing special here. This means that In SSR mode, a similar thing will happen still.
My understanding is that as Ziggy statically caches its calculated routes in the constructor, this should have all the same performance issues / tradeoffs as the non-SSR version. That, again, is my understanding of how all this interacts. |
|
npm run build |
This PR adds the SSR support for the Inertia stack.
To not be a default option, I added a
--ssroption, this way we will only include the SSR part if the user wants.to have the SSR running make sure to run:
then to start the ssr server run:
More information on the Inertia website: https://inertiajs.com/server-side-rendering
The directive
@inertiaHeadadded to theapp.blade.phpwill not do anything if the SSR is not enabled.