I’ve only built mobile apps so building a web based SPA is new to me, but it seems that one downside is that you’d need two round trips from the server to display content:
Round trip 1: get the client
Round trip 2: get the dynamic content
I’m wondering if having the first page be server rendered would be a good compromise. Then get the client and the dynamic content in one pass, and from then on make REST API calls to the server. Or is there a better way to do it?
That’s pretty much how it works subject to having to run node server side.
Keep in mind that due to the static nature of the SPA part after the initial visit the html / css / js is all cached. This means that on subsequent visits you’re basically just doing the dynamic content.
But I do see the lingering need to reduce that first page load time. It would be for logged-out users by definition (if you were logged in, you’d have the client already). I would think that most frameworks use Redis to send the client and the (cached) dynamic content, but it seems like Phoenix is fast enough that no one uses Redis. So I believe that means using a standard server-rendered page.
Google is not the only search engine, and there are a lot of corner cases and limits on how google bot does index