Serving static resources: native web server vs. vert.x web server

[Olaf Geibig]

Hi,

sorry if I maybe bother you with this old question. I did my research here on the forum but I did not come to any conclusion. So let's say I want to develop a high traffic complex web application with vert.x, what is the best way to serve the app and it's static resources? Using a mature web server like nginx or the vert.x web server module? Somebody here in the forum made a performance comparison and concluded that the vert.x web server is not significantly slower. But performance is not everything. It's also about ease of use, deployment, features and flexibility. So this is my vision of the stack I want to use:

• Back end with vert.x
• Front end with AngularJS
• Using the vert.x event bus instead of a REST http API
• The front end project is separate from the back end project (git)
• The front end project is using grunt to build the project

The grunt build results in a minified front end app in a directory and a gradle build would package back end and front end separately. After some experiments I think it's also possible to set up a gradle build to package the front end project into the vert.x app's ./src/main/resources directory and then everything could be packaged in a fat jar. So that means both approaches could result in a convenient build system. One way results in one single fat jar and vert.x serves the front end and the other in a back end fat jar and a front end zip file.

So I wonder what could be the advantages and disadvantages of using a web server. The app would make use of SSL of course and the whole app must be secured. Which way would scale better? What would be easier to maintain? What do you think and which way would you prefer or what is your way?

Thanks

Olaf

[Olaf Geibig]

Hmmm... maybe my question looked like being specific to the software stack I want to use but mainly I was interested if most vert.x users who develop a web application would serve the web app and the static files with a web server (e.g. nginx) or the vert.x web sever nodule?

[qsys]

My 2c: for complex web apps, I'd go for nginx (or apache, if you want it more heavyweight :) ). If you have a few to many apps/sites to manage, I'd use nginx. If it's about one simple app/site, it doesn't matter.
Reason? Because serving web pages is what nginx does, and it does it well. It has quite a few options/settings you can use, like some (micro)caching, security stuff, ... . For me, it's a matter of separation of concerns: vert.x is an amazing app platform and nginx is one of the best web servers to me and clean but not overdone separation means 'easier to maintain' for me, in most cases. Just a quick thought.



Op dinsdag 1 juli 2014 18:05:50 UTC+2 schreef Olaf Geibig:

[Olaf Geibig]

That are of course good reasons for a well established web server and I had similar thoughts. But you would have to deal with a two step deployment when updating the whole application. On the other hand it enables you to update the front end (nginx) and the back end (vert.x) independently. But what about possible pitfalls? I've read about people running into timeout issues with nginx and the vert.x event bus. Analog to a java REST API running in tomcat I would let nginx proxy the requests to let's say /api to localhost:8080, but what about the event bus? As far as I know SocksJS also uses http, so proxying should just work, right?

[qsys]

:)

http://nginx.com/blog/websocket-nginx/ - They should change the example code from node.js to vert.x, though ;). Yeah, it should work, but haven't got enough 'complex application' experience to say it will work :p.

I don't think it 'll be necessary to have a 'two step' deployment, but you'll probably have to configure nginx properly. Setting up one SockJSBridge should be fine.

However, thinking about it, using the vertx webserver module might be fun as well. I actually never thought to do so. Reading https://groups.google.com/forum/#!topic/vertx/kPfizM4ZVKo, it might be worth the effort.




Op woensdag 2 juli 2014 16:09:21 UTC+2 schreef Olaf Geibig:

[thir...@gmx.net]

Hi Olaf!

I am currently developing with the stack you are describing. I did not really consider using anything else than the HTTP server that comes with Vert.x. I think for a bigger business, where there is already infrastructure/ configuration management present, I could make sense to not use vert.x for static files, but if you want to start from scratch, I would always do it for the sake of simplicity.
The project I am working on includes both front- and backend in a single repository, but your idea about Grunt and Gradle make perfect sense to me, and I think for my next project, I would also do it that way.

Btw, in case you don't know this awesome AngularJS module, I strongly recommend it:
https://github.com/knalli/angular-vertxbus

Regards,
Thomas

[Olaf Geibig]

On Thursday, July 3, 2014 2:18:50 PM UTC+2, thir...@gmx.net wrote:

I am currently developing with the stack you are describing. I did not really consider using anything else than the HTTP server that comes with Vert.x. I think for a bigger business, where there is already infrastructure/ configuration management present, I could make sense to not use vert.x for static files, but if you want to start from scratch, I would always do it for the sake of simplicity.

That's what I think, too. If the build would result in a fat jar containing the back end and the front end then for deployment the only thing you have to do is scp the jar and 'java -jar MyApp.jar' - that's quite simple.

The project I am working on includes both front- and backend in a single repository, but your idea about Grunt and Gradle make perfect sense to me, and I think for my next project, I would also do it that way.

If I'm able to solve it with Gradle I'll post my solution here. So far I have Grunt integrated into the Gradle build and that 'grunt serve' proxies the API calls to whatever port vert.x is running on. What is missing is that Gradle packages up the Grunt dist directory into the vert.x fat jar.

 

Btw, in case you don't know this awesome AngularJS module, I strongly recommend it:
https://github.com/knalli/angular-vertxbus

Yes, I've seen it and I plan to use it. Thank you. How did you solve authentication and authorization for your event bus API? Are you using SSL for the event bus bridge server and if yes, is it working smoothly with angular-vertxbus?

[thir...@gmx.net]

| How did you solve authentication and authorization for your event bus API? Are you using SSL for the event bus bridge server and if yes, is it working smoothly with angular-vertxbus?

Yes, I do use SSL, and I did not have any problems so far.
In my current project I am using the mod-auth-manager. I copied the source from github and extended it with group based authorization.
Within Angular, I have an Auth service, which the rest of the app uses for everything auth-related.
My event bus bridge config looks like this:

"inbound_permitted": [
    { "address":"auth_manager.login" },                
    { "address":"auth_manager.authorise" },
    { "address":"auth_manager.logout" },
    { "address":"query.verticle", "requires_auth": true }
],
"outbound_permitted": [
    { "address":"web.client" }
]

[Olaf Geibig]

Great to know that this is just working as I hoped it would. Thanks for the insight into your solution. I can't wait until I can start working on my vert.x project.

Would be great to have a modular vert.x web application framework. Yoke is great but it focuses on server side HTML rendering. But I prefer doing the front-end with a client side MVC solution. Maybe in the future we could extract some of the solutions we develop for our applications.

--
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/2A9yolEEDMI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[adeola ojo]

For existing application infrastructure, i would use a more mature web server like nginx to drive front end user experience while vertx would drive my backend processing..