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

[elbasti]

Hi folks,

I’m working on a greenfield webapp. The stack I’d like to try is Vue on top of Phoenix. I’m not new to vue, but I’m new to Phoenix.

I wonder how you all have been addressing the js build chain at development & build time.

I’d love to be able to use the vue cli as much as possible. JS tooling is definitely not my strong suit and so far I’ve found it incredibly useful, with super sane defaults and really cool features (ex, modern mode )

However, one side effect of using vue-cli is that webpack config is kind of abstracted away.

Right now I’m thinking about structuring my project as follows:

1. Start a new phoenix project with --no-webpack ;
2. Start a vue project using vue-cli-service , with these two changes:

• priv/static should be the build target
• lib/myapp/templates/layout/app.html.eex should be the index_path for vue-cli-service

Would this work? Anyone here using vue & phoenix have a similar setup?

As well, how do you handle developing the vue component of your app (ie, leveraging vue-cli-service serve ) with such a setup?

Many thanks, loving phoenix so far.

[sribe]

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.

[nthock]

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.

[elbasti]

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.

[elbasti]

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

[peerreynders]

@elbasti

So you have Phoenix serve your static vue app?

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

Isomorphic ReactJS managed by Elixir

Hey friends! My company runs a single page app, and it is a hard requirement that we do isomorphic rendering for our front end. Our back-end is implemented in Elixir. I was thinking it might be nice to cut out the middle man and use Elixir to isomorphically render our reactjs application on our elixir back-end. Are there any libraries, conference talks, etc. you can point me to that could be helpful? Thanks a bunch!

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:

Missed Opportunity: Phoenix needs a guide for creating REST APIs

Let me start by stating an assumption: Phoenix is a great approach to building REST APIs. There are many reasons for this, but I will assume that those on the forum understand why this is so. Now assume that a team that needs to create a new REST API has heard about the performance and reliability characteristics of Elixir, and after a little research they come upon Phoenix as an implementation candidate. Being new to Phoenix, where do they start their research on evaluating Phoenix as a candi…

[sribe]

@elbasti

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 ?

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.

@elbasti

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

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

[mikemccall]

@elbasti

As well, how do you handle developing the vue component of your app (ie, leveraging vue-cli-service serve ) with such a setup?

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.

[nthock]

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.

[amnu3387]

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).

[DragosMocrii]

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!

[DiodonHystrix]

I haven’t used GraphQL, but…

@DragosMocrii

• 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

These seem ok.

@DragosMocrii

(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?)

I’m not exactly sure if primary reason to use Cloudfront is eliminating any kind of bottlenecks.
I guess you are a bit paranoid, it should be fine. But remember that Phoenix can handle so many requests at once only if it has enough resources .

@DragosMocrii

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?

Totally valid. You don’t lose any advantages if you use it purely for API.

[DragosMocrii]

Thank you!

[marcalchca]

Hi,

Any news since a year ago? Have you applied successfully the approach you described?

Below is the context/reason for my question:

I’m considering a career switch and I decided to use Elixir/Phoenix (OTP).
I want to build for sure web + mobile apps (maybe target also smart watch and maybe IoT?).

I think of building PWAs to span all targets with mainly 1 code base (as closely to native mobile apps for the mobile part of my target).
However, so far there’s no home-made front-end framework for Phoenix … except maybe LiveView but it doesn’t support offline scenario’s (so far - maybe BEAM in local? When? Or compile to WASM? Roadmap?).

So in order to stay with Elixir/Phoenix I feel forced to choose between:

• using LiveView and gaining enormous productivity for many use cases but failing for real mobile use cases
• using LiveView and inventing a solution myself for the gap (not realistic, I guess?)
• turning to another front-end framework or solution (but I want to AVOID JavaScript as much as possible)

I considered ELM, but there’s too much controversy around it (small user base, support?, LT-continuity? …).
So I’m looking at the alternatives - so many of them !!! (e.g. Xamarin (but forced to c#), Flutter?, React/Native (Javascript !), Corona?, AppCelerator? PhoneGap? …)

Vue seems to be the 2nd best choice (after LiveView if it were fully mature) to get up-and-running fast.
There’s a lot of tooling around it and it has nativescript …

What’s your advice, assuming you have used Vue+Phoenix in the mean time?

(advice from anyone is much appreciated)

[josvme]

I don’t know if this is going to be useful to you. But I will try anyway :D.

I have some experience using Vue and Phoenix. I chose Vue for the same reason that it will be easier to convert to a mobile app at some point. say using Nativescript. . I am also not a fan of Javascript, so I use Vue with Typescript, which works amazingly well.

Now coming to development, I am a fan of separating frontend from backend. This allows independent development of both and facilitates decoupling. Deploying Vue with Phoenix is easy. I just compile Vue to a single JS file and serve it using Nginx. So my index page shows Vue app. Vue calls into Phoenix using /api url. All calls to /api is redirected by nginx to my Phoenix listening on say port 4000. When combined with Docker, the deployment is also very pleasant. In case you are interested you can also check out my blog post for more info. Have a nice day

[marcalchca]

Thanks a lot.
Sorry for my late reply, not about not being interested, I was drawn in work (despite lock down, lucky me).

I’ll certainly have a look at your blog post! Thanks for your post.
Lately LiveView is getting better and better … I’m wondering how long it will take before the “offline” issue is tackeled, and then we probably don’t need anything else anymore :-).