Integrating Vert.x With Frontend Development Workflows

[deven.p...@redhat.com]

I've been having discussions with Paulo and Clement off-list about developer workflows when using Vert.x with "modern" frontend frameworks (e.g. Angular/Vue/etc...), but I wanted to open the discussion up to the community at large for more feedback and input.

So, a little background. I was recently working on a project using Vert.x 3.4.2, Angular 4, and Service Proxies... The issue that we hit was that we need to compile the Java code in order for the Service Proxy code generation to happen. We then need to copy those generated JavaScript files into the frontend source tree and transpile/bundle/link that into a static JS artifact, but that needs to happen BEFORE the fat-jar is created. Additionally, we were looking for a solution for rapid development like grunt's `dev` server so that when files change the JS and Java code can be recompiled and redeployed automatically. 

Clement and Paulo are kinda working at this from 2 (equally valuable IMHO) directions. Clement has been working with Red Hat and Fabric8 on the Vert.x Maven Plugin and making it work well with the frontend-maven-plugin, but there are still some challenges (which he thinks will soon be resolved) with using them together. Paulo has been working from the other end using frontend build tools like WebPack to control maven and thus solve the problems from that direction. I feel like both can and probably should work so that we can reach developers from whichever way they are approaching Vert.x. Devs who have more experience with frontend development will be more comfortable with using NPM/WebPack/Grunt/etc..., whereas traditional Java devs will be more comfortable coming at it from the Maven perspective.

Paulo has also mentioned that it may even be possible to integrate server-side rendering within Vert.x for some of those frontend frameworks (Woot!). 

What I would like to know is if anyone else on this group is having similar challenges, how you are tying to address those challenges, and if you have any suggestions for how we as a community should approach the problems.

Thanks in advance!!!

Deven Phillips

Red Hat, Open Innovation Labs

And thanks again to the Vert.x core team for all of their time and support!!!

[Jez P]

FWIW I experimented (basically successfully but i didn't do anything complex) with gradle and gulp for this - also found I could run in such a way that I could auto-reload the front end as a result. What I didn't get to was auto-seeing Java changes. But my workflow was pretty basic and unsophisticated, and I wasn't using Service Proxy stuff. With maven's lifecycle phases I could see your scenario being doable but painful. I'm sure your flow would be easier in gradle than in Maven (though it could probably be done with the right Maven plugins).

For me personally, and I'm no gradle expert, I think I'd go down the "experiment further with gradle" route as I just feel it gives you a bit more flexibility than Maven. You can certainly call gulp from gradle and from a talk I saw a while back you could also trigger rebuild on change. So as long as your build process dependencies were correct (JS transpile/bundle/link dependent on java compilation, packaging dependent on JS transpile/bundle/link AND java compilation) then I think you'd get what you wanted. 

[Paulo Lopes]

For reference here is my web pack plugin:

https://github.com/pmlopes/webpack-vertx-plugin

It works by calling maven to unpack dependencies to node_modules before babel/tsc run and then call maven package to build a fat jar after a successful babel/tsc build.

My approach is more geared towards front end /full stack developers if you like and will not remove maven out of the equation. It will allow the user to use her own pom file and no extra plugins.

I guess it could be also done with gradle...

[Deven Phillips]

Jez, 

    Thanks for the suggestions, but for my work Gradle just doesn't stack up as well as Maven. I have used it on many projects over the years, and I keep coming back to Maven for it's stability. I believe that Clement will have a working Maven solution next week, and I look forward to trying it out. 

Cheers, 

Deven 

--
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/y_tvWhc10ok/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/c6ce26ac-dddc-42a6-bca4-4981538ec69a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paulo Lopes]

Hi everyone,

small project update, I've added several project templates to the webpack plugin I've been working. Currently you can find:

* angular4 + typescript + testing + vertx - https://github.com/pmlopes/webpack-vertx-plugin/tree/master/templates/angular
* aurelia.js + typescript + vertx - https://github.com/pmlopes/webpack-vertx-plugin/tree/master/templates/aurelia
* basic - simple backend + frontend in js - https://github.com/pmlopes/webpack-vertx-plugin/tree/master/templates/basic
* knockout + typescript + vertx - https://github.com/pmlopes/webpack-vertx-plugin/tree/master/templates/knockout
* minimal js frontend + java backend + vertx - https://github.com/pmlopes/webpack-vertx-plugin/tree/master/templates/minimal
* react + redux + typescript + vertx - https://github.com/pmlopes/webpack-vertx-plugin/tree/master/templates/react-redux
* react + typescript + vertx - https://github.com/pmlopes/webpack-vertx-plugin/tree/master/templates/react
* vue + typescript + vertx - https://github.com/pmlopes/webpack-vertx-plugin/tree/master/templates/vue

Excluding the basic and minimal all the other frameworks implement a simple application on typescript using:

* bootstrap for CSS
* a simple REST API

I am facing some issues with SSR (although I got it working to some extent for react) due to the limitations of Nashorn + assumptions of webpack.

Feel free to check and provide feedback!

To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.

[Arnold Schrijver]

Its a bit old SSR sample, but maybe there is something there for you https://github.com/engagingspaces/vertx-react-example

[Paulo Lopes]

Thanks, React SSR is simple and works, the troubles come when you add the latest react-router and redux since the router from v4 works with promises and we need to keep re-rendering until all reroute and store (redux) updates complete.

Things get messier with NG4 which assumes that we're on a browser since we dont emulate the full node API and it tries to instantiate XMLHttpRequest objects ;)

Anyway for simple projects it can be added but I'll continue for a bit longer in the next days to see if I get it working properly.

My Promise polyfil works so most of the issues are fixed, now it's a question of solving all the issues where libraries assume we're on a browser by providing the right polyfllls.

Cheers