Search code examples
playframeworkvue.jsfrontendwebjarstwirl

Using Vue.js in a Play Framework Application

If anyone has experience using Vue.js as a frontend for a Play Framework application, I'd like to know the recommended approach.

My current setup is a Play application (in Java) with Models, Controllers, and DAOs for handling REST requests - this is effectively my backend. Now Play also lets you use the Twirl template library to create views that can be served as static HTML. However, I found the Twirl syntax needlessly complex and difficult to compose views for a single-page-app. I'd prefer using something more fine-tuned for UI work like Vue

My research shows two options for integrating Vue to Play:

  1. Using Webjars:
    Its some sort of Play plugin that bundles JavaScript libraries like JQuery into .jar files that can be deployed by Play. Frankly, I don't understand the process and I have no idea how this would let me write my view in .vue files.

  2. Using a separate Vue project loosely connected to the Play backend:
    This is my current outlook before posting this question. I suppose I could create a standard Vue Webpack project using the vue-cli and NPM, then I can call the Play backend APIs RESTfully. The problem with this is the additional complexity of deploying a backend and a frontend separately. I'd prefer everything in one Play application (project folder)--backend and frontend.

Which one of these is the way to go? I am also open to new suggestions. For any suggestions, please explain the advantages of that approach and preferably provide a minimal working example (a Github repo will suffice).

Thanks.

Solution

  • First we used a Webpack-SBT setup like the repo suggested by @Tim Barclay (play-vue-webpack), although with our own handcrafted Webpack config files and SBT hooks...it was pretty time consuming and required a good knowledge of Webpack internals.

    So we later went with Option 2 in the original question: Using a separate Vue project loosely connected to the Play backend. Initially it was more work indeed, but as the codebase grew, it was way easier to understand and maintain than the earlier approach of coupling the 2 codebases.