How to combine playback frames and angular2?

Question

My question is how to organize the front and back together in the project. As far as I know, there are two ways to do such a thing.

• Group front and back in one project using web banking dependencies and sbt plugins. This way sbt will do all the necessary operations like uglify , concat , compilation ( typescript to javascript ) ...
• Separate the front and back and separate them separately. In this case, the back end should add the header Access-Control-Allow-Origin . In this way, the front and back can be deployed on two different hosts. And the tool used is npm and gulp / grunt
• Compound 1 and 2. Still use the same repository for the front and back sides, but the front is created and generated by external tools like npm, bower and gulp / grunt

At the moment, there are not a large number of documents for options 2 and 3. Also, the typescript plugin is not yet ready.

Which method is better for scala play + angular2 development?

Answer 1

I recently worked with several Angular and Angular 2 applications and had a similar problem. For all scenarios, our server and front-end applications were separate in terms of code and exchanged data only through REST interfaces. Nevertheless, we supply both the frontend and the backend part, and it was natural to use one server for both (maybe Play Framework or Tomcat).

Option number 1 First, we chose this option. Webjars look like a miracle, and several sbt or maven plugins can help you with mini compilation, line, etc. Your frontend project. For some, this may go well. Unfortunately, I found this workflow unnatural. Some plugins were missing or their configuration was complicated. Webjars are not always up to date, some of them are automatically available, some are not ... etc. In a simple project, this might work, but for me this was not enough.

Option number 2 We tried separate development servers, but we quickly left. For most actions, you still need your server - frontend and backend. Therefore, you must start both. This means that you have 2 more teams or workflows to remember and teach others. CORS is not a big problem, but you might consider disabling it for production, which means additional work in the project. Developing a backend or interface separately was faster, but, in my opinion, if you want to provide both, your development process should help you with this.

Option number 3 This is the one we use. With sbt, this is possible and convenient. SbtWeb plugin allows you to set playRunHooks to any action that you would like to run with your project. The idea is to run a JavaScript build tool that will perform all the necessary frontend tasks, fe:

 playRunHooks += { Process(Seq("npm", "install"), file(portal)).lines.foreach(println) RunSubProcess(portal, "npm", "run", "watch") } 

RunSubProcess can be found here .

So, shortening the long history, you allow the Play Server to serve your static content, but ignore its changes. This is taken care of by npm , gulp , webpack , grunt - whatever you choose. There are many JavaScript tools, plugins, and templates available to help you. You don't need sbt plugins, just let the JavaScript world do its job. It may be difficult to set up at first, but it pays off quickly.

As an example project, you can check out the Activator Play Framework template with Angular 2 and Webpack 2 , and this project is hosted on GitHub: play-ng2-webpack2 . It helped me a bit.

Now you can also use Tomcat, xsbt-web-plugin and developmentMode. The philosophy is similar.

Hope you find your way :).