What should be my front facing server, Vue or Phoenix?

phoenix
vuejs
Tags: #<Tag:0x00007fcf980c9698> #<Tag:0x00007fcf980c9558>

#1

I am working to make Vue-phoenix SSR solution, with some basic start I am getting some queries.
what should be my front-facing server, either Phoenix or Vue?
my points:- for me phoenix suits better coz I am doing ssr and it would be good if I get all the request in Phoenix, process them and deliver the content. Also pheonix is handling my AAA ( authentication and authorisation ).
I need the help of the community to understand this topic or concept deeper.
thanks.


Motivations for using React/Vue SSR
#2

Does Vue contain a server? I thought it’s a frontend framework. In any case you should use Phoenix to serve the HTML and the related JS/CSS files. There’s no reason to have two servers on the backend where one can do the job.


#3

I have developed with both a. Phoenix at front-end and b. VueJS on front-end with Phoenix on back-end including authentication and authorization.

My suggestion based on my experience is to use Phoenix on front end while integrating some VueJS components as needed in the html.eex files (if VueJS is used to render data from the server, then JSON based API end must be used, i.e. render results as JSON to be consumed by VueJS).


#4

Maybe its a matter of personal taste, but Vue as a standalone SPA (with a phoenix JSON API) is way easier to work with than trying to integrate directly into phoenix. Not to mention the logical separation of concerns (e.g. you can’t just assign everything on a conn and hope for the best).

Edit:
Rereading the question again, why use Vue at all if you want to do purely SSR?


#5

The Benefits of Server Side Rendering Over Client Side Rendering:

That means your browser will start rendering the HTML from your server without having to wait for all the JavaScript to be downloaded and executed. In both cases, React will need to be downloaded and go through the same process of building a virtual dom and attaching events to make the page interactive — but for SSR, the user can start viewing the page while all of that is happening.


#6

I was under the impression Vue made much more sense for CSR when integrating with phoenix, as phoenix templates + jquery could handle pretty much everything you’d need if you wanted SSR.


#7

@peerreynders

A quote from a comment. is that right?


#8

We have a React clientside app that talks to Phoenix backend with token auth for API access access.

In your case you can have server-side rendering with Phoenix auth (cookie based) and ALSO frontend architecture talking to that API via token auth.

It’s really a balance for you to answer. I don’t recommend going 100% clientside. There are times when a server side rendered page is better, like for example a simple static about us page.


#9

I view SSR as an optimization as your web app is less of a static page with some interactivity (ala jQuery) sprinkled in and becomes more of a SPA towards a progressive web app - specifically targeted to replace a native app on mobile devices. The initial CSR rendering on a mobile device can take long enough for the user to get bored and move on to something else. With SSR the first HTML is already there for the user to view (but not interact with) while JavaScript is still setting things up in the background.

Have a look at the various numbers on Hacker News readers as Progressive Web Apps to see loading times for various SSR/CSR approaches.

That being said Polymer HN does pretty well without SSR.


#10

If you want SSR you can either let Phoenix render all the HTML and sprinkle in JS/Vue where needed, or you can completely decouple the frontend and the backend. In the latter case you acheive SSR using something like Nuxt.js, while the Phoenix app is a pure API serving only JSON.

If I were to make a JS-heavy app I would probably choose a decoupled solution. I think that’s that real question — what kind of app are you building and how much JS will it need.


#11

sir, I want to use the goodness of Phjoenix and vue, actually it would be a csr + ssr thing.
to keep my code secure from hydration problem, i want to use vue as it handle things pretty well.
thanks for the replay :slight_smile:


#12

Thanks for your suggestion. Would like to discuss some more details regarding this phoenix - vue ssr setup. Dont want to clutter here. Can we discuss over some private channel - mail/slack or something that’s convenient for you?


#13

Your suggestion on decoupling makes good sense. Im a newbie working with Phoenix, Vue SSR. Can you bit more elaborate on the decoupled setup - in crude way I’m thinking of like this:

  1. Phoenix as front facing API server - that has the knowledge of invoking the needed ‘N’ Vue components for the requested route
  2. Node based Express server to take Vue components related requests - acting as rendering server(does vue ssr)
  3. There need to be a two way communication path between these servers - may be a web socket. Why? - Phoenix Controllers should be able to call Vue components in some way & the Vue components would call Phoenix back end APIs - to fill section data & render.
    Seeking comments on whether this would be a good approach for Phoenix as API server & Node server for Vue SSR.
    Would be of great help if someone can shed some light on how to go about on this. Thanks in advance

#14

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.

The advantage of this is the decoupling. You can now make changes in either the frontend or the backend, and as long as you don’t change the communication interface – the API – the other part of your application is not affected.

If you want to do this I suggest you start by builiding a pure API Phoenix app that only serves JSON over rest, no HTML. You do the routing in Vue. All you need is a Phoenix API backend and something like Nuxt.js to give you SSR.


Motivations for using React/Vue SSR
#15

7 posts were split to a new topic: Motivations for using React/Vue SSR


#16

I’m in the process of trying the same thing right now… but with ReasonReact and Next.js doing the SSR instead of Vue/Nuxt. Phoenix completely decoupled serving as graphql endpoint. I like the setup as it simplifies the webpack config for code splitting/lazy or async loading limiting the CSR required and it’s fast and efficient for the browser. I had quite a lot of JS on every page and felt decoupling made sense.

So far so good but sessions/cookies/csrf protection becomes a little trickier as it has to be implemented in the custom Express setup instead of Phoenix. I know that Nuxt has similar facilities for this as Next but this slowed me down a little bit.

Also you’ll have to understand the lifecycle hooks and whether they are executed server side or client side (or both). I imagine websockets will be a bit trickier than standard http req/res depending on whether the server or client is subscribing… but haven’t attempted this yet.

Not sure it was worth decoupling yet in terms of time to develop and added server side complexity but seems like a good pattern.