Motivations for using React/Vue SSR

[yurko]

Edit - From: What should be my front facing server, Vue or Phoenix?

@bulldog_in_the_dream

With decoupled I was thinking of using Phoenix as a pure API, with no Vue in it whatsoever. This way the backend and the frontend don’t need to know anything about each other’s implementation details, and they can be in different repos. All that connects them is some communication protocol, usually REST.

We do that with WebSocket API - there is an Backend / API server and a separate server for web client. Works fine, though I wouldn’t do that just for the sake of decoupling, in our case we have other clients (native apps) using the same API server which “legitimizes” the use case For a normal SPA I’d go with a single server.

[peerreynders]

@yurko

For a normal SPA I’d go with a single server.

From what I’ve come across your typical React or Vue SPA will be bundled with webpack which will tend to generate its own index.html. While that can simply be served as an asset by Phoenix there hardly seems to be a good reason to do so given that Phoenix’s asset handling primarily exists to be used to support pages generated with EEx. Now if you aren’t using EEx then there is a strong argument to keep Phoenix “unentangled” from the frontend.

Also to me SSR in connection with React or Vue implies that the server side rendering will be handled by Node.js - so serving your React/Vue SPA from Phoenix would prevent you from using their typical SSR technologies.

Now it is entirely possible to generate pages with EEx that reference/include React or Vue components which are served by Phoenix - but I wouldn’t call that an SPA. And while the EEx rendering happens on the server side, the components themselves are still rendered on the client side.

[yurko]

@peerreynders

Also to me SSR in connection with React or Vue implies that the server side rendering will be handled by Node.js

Yeah, when I wrote “normal SPA” I meant an SPA that uses server API and is rendered client side. Moving the rendering part to the server and throwing a NodeJS Server in might be a case of premature optimization, I’d start with client side rendering and maybe async components (for Vue Components Basics | Vue.js I think React has a similar concept starting with v.16).

Offloading the rendering to the server has it’s costs since it takes away the work from the browser of each user and lets server do it - the more users the app has, the more extra work for the server. It’s by no means a deal breaker but still I’d avoid using it unless there’s a good reason.

[peerreynders]

@yurko

It’s by no means a deal breaker but still I’d avoid using it unless there’s a good reason.

I understand your concerns but React/Vue SSR is such a hot topic because of targeting mobile devices. Its getting to the point that if you are targeting the mobile market AND using React/Vue it is assumed that you will be using their respective SSR technologies to offset the delay of rendering the entire page inside the client device.

A more frugal way would be to stick to EEx generated HTML and even handwritten CSS to minimize loading times with just a bare minimum of JavaScript. But many feel that the loss of interactivity is just not worth it.

Also outside of the Phoenix space the frontend is already taking on more responsibilities because of serverless technologies so combining SSR with React/Vue isn’t viewed as much as premature optimization but the cost of doing business with mobile customers.

[aadii104]

We can have another thread for this discussion, as this doesn’t comes under my question.
Hope you can understand.
Thanks.

[yurko]

But what about progressive web apps then? They’re red hot, they target mobile users and they are using client side rendering by default

S. Architecture  |  web.dev

The prevalent architecture up until recently has been to use server-side rendering (SSR), which is when the browser fetches the page over HTTP/HTTPS and it immediately gets back a complete page with any dynamic data pre-rendered. Server-side rendering is nice because:

…

Client-side rendering (CSR) is when JavaScript runs in the browser and manipulates the DOM. The benefit of CSR is it offloads page updates to the client so that screen updates occur instantly when the user clicks, rather than waiting while the server is contacted for information about what to display. Thus, when data has changed after the initial page render, CSR can selectively re-render portions of the page (or reload the entire page) when new data is received from the server or following user interaction.

So what we speak about is technically going from SSR to CSR and then optimizing it by kinda going back to SSR with different server software, I know the hype but it does’t make much sense unless we already use NodeJS server side

@aadii104 ok sorry if it went off rails!

[peerreynders]

Nice Reference!

However look at https://hnpwa.com/ - a lot of them seem to utilize product specific SSR when it is available. Given that the frontend library/framework is implemented in JS, rendering it on the server side is going to get Node.js involved in one form or another.

I have to wonder whether the people at GoogleHQ with their near perfect, high speed mobile connections on their high-end smartphones may not have accounted for the more rudimentary quality of mobile connections and devices globally.

Businesses always have the option of developing native Android, iOS, etc. apps that connect to a backend but I think there is a movement to mostly just go back to the browser because otherwise there are just too many permutations to cover (and the user typically has to get involved in the app upgrade process).

[yurko]

@peerreynders

However look at https://hnpwa.com/ - a lot of them seem to utilize product specific SSR when it is available.

There’s no denying the hype, that’s for sure. Though from the practical perspective I’m not sold, at least yet I can have an SPA with client side rendering, should it grow too big, I’d split it in parts and load them on demand asynchronously. Converting it to PWA was easy when using CRA and now they seem to have it out of the box create-react-app/packages/react-scripts/template/README.md at main · facebook/create-react-app · GitHub

Also on topic of this forum, when using Phoenix WS APIs these apps feel extremely fast, somewhat like using desktop software, so if anything, moving from HTTP requests to WebSockets makes way more sense to create that real-time-y feel

@peerreynders

Businesses always have the option of developing native Android, iOS, etc. apps that connect to a backend but I think there is a movement to mostly just go back to the browser because otherwise there are just too many permutations to cover (and the user typically has to get involved in the app upgrade process).

Yep, the web has won the war

[bulldog_in_the_dream]

For the last four years most of the projects I’ve worked on have had this decoupled frontend/API architecture. Usually the teams have been divided with 1-2 people on the frontend and 1-2 people on the backend. From a developer ergonomics perspective it has worked well, and I have terrible memories of the one time we thought we’d “just add a little bit of jQuery” to a .NET MVC app.

I am currently looking for the fastest/easiest setup for personal projects, and since I have most experience with frontend dev I’ve concluded it is easier for me to do all templating and routing in the frontend framwork. The times when I have tried to integrate a frontend framework like React into a backend framework (Rails, Django) it has been cumbersome and felt messy. I’m currently torn between using something serverless like Firestorm Firebase or using a backend framework that does the pure API bit well. Phoenix looks promising so far.

[kokolegorille]

Probably You mean Firebase

[fareesh]

SSR is important for any product where SEO or Social Sharing is a consideration. If you want to build the next Airbnb or Yelp, you will need SSR for your listing and category pages to show up in Google, and for Facebook users to be able to share them with rich previews.

If you go with something like Phoenix, you should probably limit the use of a JS framework to something like Vue where you can focus strictly on event bindings and some interactive widgets like search typeaheads, notifications, etc. which are not important for indexing. You won’t be able to do templating and routing in the front-end framework AND have crawlability/shareability unless you render on the server.

[mikemccall]

An application load balancer can work for required SSR. You can have your standard routes hit the node server for SSR and something like /api/* or api.hostname.com hit your elixir/phoenix server.