Add new recipe how to deploy an Inertia Rails app with Kamal and SSR support #167
Conversation
brodienguyen
changed the title
| @@ -0,0 +1,222 @@ | |||
| # Deploy with `Kamal` | |||
|
|
|||
| Rails 8 will ship with [Kamal](https://kamal-deploy.org/) preconfigured as the default deployment tool. | |||
There was a problem hiding this comment.
This is true when you generate a new app with rails new -j esbuild or other builders. By default (with importmap), you'll be missing Node.js-related dependencies.
There was a problem hiding this comment.
Is this comment related to this line though ?
'Cause I'm pretty sure that Kamal is the default deployment tool for rails 8, even without -j esbuild flag.
My guess is that your comment relates to the following lines (l.4-5) 
:
If your application does not require [SSR](/guide/server-side-rendering.md), you simply just need to [update your asset_path](#update-asset-path-inconfig-deploy-yml), and deployment should work seamlessly.
There was a problem hiding this comment.
yeah, I ment to comment the next line 😅
There was a problem hiding this comment.
@skryukov I did update my PR to highlight the difference between the new Dockerfile compared to the fresh default Rails 8 one. The preview of the new docs have been updated in the PR description as well. Could you help me to re-review it, please?
docs/cookbook/deploy-with-kamal.md
Outdated
| ```ruby | ||
| InertiaRails.configure do |config| | ||
| config.ssr_enabled = ViteRuby.config.ssr_build_enabled | ||
| config.ssr_url = "#{ViteRuby.config.protocol}://#{ViteRuby.config.host}:13714" # [!code ++] |
There was a problem hiding this comment.
@ElMassimo I saw you had defined default value for ssr_url option at lib/inertia_rails/configuration.rb as http://localhost:13714.
Should we dynamically generate it using this approach please?
ssr_url: "#{ViteRuby.config.protocol}://#{ViteRuby.config.host}:13714"Given it results the same value but works out of the box for all environments.
There was a problem hiding this comment.
For clarity, the default value of ssr_url was added in:
inertia_rails does not depend on vite_ruby, nor is vite_ruby so commonly used that it would make sense to auto-detect it and use it as a default.
In addition, I would suggest to avoid using ViteRuby.config, as it refers to the configuration for the Vite Dev Server, and not the SSR server.
Even the protocol might differ in many apps:
- In many cases it's desirable to run the Vite dev server over SSL so that HTTP2 can be used and connections are multiplexed (loading unbundled files faster in development).
- In contrast, a common setup for running the Inertia SSR server is for that to be in the same box using plain HTTP (without SSL).
There was a problem hiding this comment.
Yeah, I guess this part is a leftover from when I tried to understand what bin/vite ssr does (which is basically just a shortcut) 😅
I think it's better to use something like this instead: ssr_url: ENV.fetch('INERTIA_SSR_URL', 'http://localhost:13714') and set INERTIA_SSR_URL in the Kamal deployment config (any suggestions for a better name?).
There was a problem hiding this comment.
Thanks @ElMassimo, @skryukov for your detailed discussions and suggestions. I agree with all those valid points and prepare another PR to allow to set Inertia SSR URL via the ENV variable:
|
Thanks for this PR. Adding this recipe will help some of us (ie me 🐯) set up SSR the right way. |
|
Question for the room... why do you want to use SSR? (genuine question, no right/wrong answers, just trying to understand how people use Inertia in the real world) |
The app I'm working on needs to be SEO friendly. I believe SSR is much better than CSR on that matter. |
Ignore the benefit of SEO, in my case, purely because I would like to propose Inertia to the team where we are building and maintain a very legacy B2B software product. There are some requirements about backward compatibility on older devices or browsers with limited Javascript support in the existing contract so we have to play a bit safer on this transition. Also since there are a lot of CRUD screens where their pages are built purely with form and don't change that frequently, with SSR we can cache them a lot longer to save some computation and loading time for our user too. Without JS, at minimum they can still submit the form and get the job done rather than raising a bunch of support ticket to us (I am still not 100% sure if it is achievable with how InertiaJS form works). |
… via ENV variable
|
This PR is ready to review. I am still marking it as draft because it depends on another change at: |
This PR adds a new recipe to the Cookbook list, providing detailed steps on how to deploy an Inertia Rails application with Kamal, configured for SSR support.