Phoenix + Vue.js CLI: How do you manage the build and development pipelines?

Personally, I run them completely separately in development. And have a shell script in the Vue project that builds the release then rsync’s it into a folder in the Phoenix project when I’m ready to push out a release.

We are using Phoenix as the backend, and Nuxt (a Vue framework) as the frontend. Both frontend and backend are separate application and we deploy them separately.

Thanks! I suppose that makes sense. So you have Phonenix serve your static vue app? Just for clarification, does this mean that your phoenix templates/layout/app.html.eex is actually the vue index page? Where do you have a <div id="app"> (or similar), in templates/layout/app.html.eex or in templates/pages/index.html.eex ?

Sorry for the follow up; just trying to figure out how to marry the phoenix pages with the index page created by vue.

Thanks. So your vue app is served by a different server? (node.js, presumably)?

No. With that setup Phoenix doesn’t serve any of the Vue app’s asset’s - it strictly functions as an independent JSON server.

I had a Vue example for Phoenix 1.3 using the app.html.eex but the consensus seems to be to keep Phoenix/Vue separate so that using Nuxt.js remains an option.

For React there is elixir_react_render

but there is nothing like that for Vue yet.

Some “Phoenix as a JSON API server” resources:

• Building a JSON API in Elixir with Phoenix 1.4
• Mix Tasks: mix phx.gen.json
• Phoenix Views: Rendering JSON

Harvested from:

In dev, I have a dev (Node) server serving the Vue app, which talks to the Phoenix server, websockets in my case, but could just a well be a REST API. In production, the Phoenix server just serves the Vue app as static assets.

I don’t. I create the Phoenix app with --no-html.

I don’t. If I’m using the cli I use it standalone. The vue cli doesn’t do a good job integrating with existing frameworks, I believe this is an oversight and it will be resolved but it doesn’t seem to be a priority. There are some open issues and ongoing discussions around this. I have a hard time accepting the whole “Just output the index.html file where your backend app will server it” There are many cases where people don’t want to replace the entire rendered page with vue. I love vue as a frontend framework because you can use it in many different forms. From adding it from the cdn and sprinkle in some components all the way to full SPA. The vue-cli really pushes towards SPA. Now that phoenix uses webpack adding vue (and using single file components) is as easy as adding the vue loader.

It’s actually fairly straight forward!

cd assets && npm install --save-dev vue-loader

Update the webpack.config.js

...
{
  test: /\.vue$/,
    use: {
      loader: 'vue-loader'
    }
  },
...

In your app.js

import Vue from 'vue'
import App from './src/App.vue'

new Vue({
  el: '#app',
  render: (h) => h(App)
})

Any page you want to render vue just add the appropriate tag:

For example myapp_web/templates/page/index.html.eex

<div id="app"></div>

At this point nothing stops you from installing and using the vue-router or vuex. Customize and use at will.

No. You do not really need a backend server if you are not using server-side rendering. The nuxt portion can be compiled to a JS file that can then deploy as a static site in Netlify.

In fact, if you just have a bunch of static pages along with a walled section (like user area, that doesn’t need to be SEOed) then nuxt generate and deploying that as a static website is great (you can also use Aws S3 and distribute the frontend through cloudfront for instance). If you have a lot of dynamic generated pages that you need to have SEOed then indeed you need to have a back-end server, or generate the dynamic bits (which can become overly complex easily and require a pipeline for continuous generation & deployment).

Sorry for re-spawning this thread, but I’m struggling with something similar. So far, I think I understood the gist of the responses here, but just to re-cap, can someone please validate if the following ideas are correct? I’d like to use VueJs/Apollo client for building the front-end of my app, and Phoenix 1.4/Absinthe for serving GraphQL responses.

With the proposed setup:

• The front-end app built with VueJS does not have to be integrated in the same project with the Phoenix back-end app
• In fact, the front-end app can be worked on independently from the back-end (planning to mock all GraphQL responses anyway while working on the front-end first)
• The Phoenix back-end app does not need to have any JS build tools, since it does not serve any static content. Its sole purpose is to serve the GraphQL queries. As suggested before, this can be achieved by creating the Phoenix app with the --no-webpack --no-html arguments.
• The front-end can be deployed as a static site to AWS S3 to leverage distribution through Cloudfront
• The front-end app (regardless from where it is served in Cloudfront) would send the GraphQL requests to the same central Phoenix app
• Since the VueJS app would be a walled section (ie app.mysite.com) requiring the user to log in, it’s not supposed to be SEO friendly anyway, so no concerns needed about that
• The content site (mysite.com) can be built independently with other tools for content management like Hugo, Wordpress, etc
• (This last one item is something I’m curious how to solve. Supposedly, we can use Cloudfront to make sure the front-end is served with no bottlenecks. Could something similar be used to serve the Phoenix back-end, but keep the same GraphQL endpoint URI? Or, am I being too paranoid about this, given that Phoenix can handle millions of requests at once, which means this should be of no concerns until it becomes an issue?)
• Is this a valid way to use an Elixir/Phoenix app? I know Phoenix is touted for being exceptionally efficient at rendering templates, so if I’m only using it as a GraphQL server, am I losing any of Elixir’s/Phoenix’s advantages?

Would something like this work for a production ready application? Appreciate any comments or concerns!