Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[2.x] Add Inertia SSR Support #1012

Merged
merged 7 commits into from
Mar 25, 2022
Merged

Conversation

xiCO2k
Copy link
Contributor

@xiCO2k xiCO2k commented Mar 20, 2022

This PR adds the SSR support for the Inertia stack.

To not be a default option, I added a --ssr option, this way we will only include the SSR part if the user wants.

to have the SSR running make sure to run:

npm run prod

then to start the ssr server run:

node public/js/ssr.js

More information on the Inertia website: https://inertiajs.com/server-side-rendering

The directive @inertiaHead added to the app.blade.php will not do anything if the SSR is not enabled.

@taylorotwell taylorotwell merged commit 090fdfb into laravel:2.x Mar 25, 2022
@taylorotwell
Copy link
Member

@xiCO2k I guess we could also port the same option to Breeze now. 😅

@xiCO2k
Copy link
Contributor Author

xiCO2k commented Mar 25, 2022

Count me in :)

@bakerkretzmar
Copy link
Contributor

Hi! Maintainer of Ziggy here. Running new Ziggy on every single request is very strongly discouraged because it gets slow if you have tons of routes.

Not sure who the best person is to answer this question, but could we cache it? Like can we use Cache in jetstream / a starter kit?

@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?

@xiCO2k
Copy link
Contributor Author

xiCO2k commented Jun 30, 2022

Hi! Maintainer of Ziggy here. Running new Ziggy on every single request is very strongly discouraged because it gets slow if you have tons of routes.

Not sure who the best person is to answer this question, but could we cache it? Like can we use Cache in jetstream / a starter kit?

@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 typeof window === 'undefined' you are on SSR Mode.

Edit: sorry you probably asking on php side, for my website I have a Singleton class to handle the Ssr and only there I render the Ziggy.

Check: https://github.com/xiCO2k/franciscomadeira.com/blob/main/app/Ssr.php

Cheers

@timacdonald
Copy link
Member

@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.

@timacdonald
Copy link
Member

timacdonald commented Jul 4, 2022

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 route() helper.

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.

@bakerkretzmar
Copy link
Contributor

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 @routes Blade directive since it's uncommon for routes to change in production, so whatever loads initially should be fine to keep around globally and re-use. I've never worked with SSR and don't really know how it works so I'm not sure if that would still make sense there.

@timacdonald
Copy link
Member

In a non-SSR request, we would have a single request come through and do...

<head>
    @routes
</head>

Nothing special here. This means that new Ziggy is called once on every request.


In SSR mode, a similar thing will happen still.

  1. The request will come into Laravel.
  2. The "before" Inertia middleware is called, which in turn calls the "share" function where we can see new Ziggy.
  3. Then, in the same request, Laravel will generate the view - which still calls the @routes directive...

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.

@santutu
Copy link

santutu commented Jul 16, 2022

npm run build
node bootstrap/ssr/ssr.js

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants