So you’re coming in at a weird time for React haha.
A lot of frameworks are cementing how their RSC picture will look and that will lead to some aspects being in flux and be a confusing transition.
SSR and prerender are a similar idea in that a user gets HTML with actual content on first page load. Otherwise, in an SPA(single page application) without some sort of pre-client render the user basically gets an empty div that the javascript will load in after the fact.
This is bad for SEO because the search engines will just see nothing as they crawl the site.
Prerender will bake in what the JS would’ve generated on the client before hand so that client gets served full html. Prerender will happen at build time as the app gets deployed.
SSR allows you to do a similar thing but will load in content at runtime which has more power in not needing to declare everything that needs to be prerendered.
So now the other aspects that make it a little hard are with RSC and how Redwood used to be architected vs. how it will be architected to allow these options going forward. Redwood used to be more of a backend server serves a static web page with the html css and js to load the rest of the content. Now you will likely have a frontend server and a backend server for RSC so deployments can be a little experimental.
I know there were some rough edges around SSR + prerendering and using dbAuth.
RSC you can sort of pre-refactor for by being mindful of what will run on server and then what will run client and nesting components. Biggest win with RSC is non blocking rendering with streaming.
I would try to do no SSR, no RSC, YES prerendering BUT experiment with the SSR and RSC canaries on the side to understand what is going on. SSR will be a big win once unlocked.