Vert.x core lib embedded in playFramework ?

[Frederic Masion]

Hi,

I'm working on a realtime app built with playframework 2. One great advantage of vert.x is the ability to use the eventbus in the browser with the sockJS bridge. This would make my app easier and more browser would be compatible.

Actualy play doesn't offers a good way to emulate websocket with fallback like socket.io or sockJS do.

Waiting for this i was temporaly using a node instance as "proxy" like this :  Play <---ws---> Nodejs <---socket.io---> Browser

I found some articles on how to use vert.x core library with other frameworks (including spring or osgi) 

In each case vert.x core replaces the http server to enable a sockJs connection (in spring vert.x isn't use in conjuction with spring MVC and in the OSGi demo Glyn uses vert.x in replacement of Gemini Web or Jetty) 

In my particular case I would like to use playframework2 AND vert.x core library but both come with their own netty.io library (play's is currently in 3.3.0 and vert.x in 3.5.0)

This means I can't use the vert.x server on the same port play does ;-(

What I would like to do is upgrade play netty version and find a way to bind vert.x on the same netty that play uses. 

Idealy Play would continue to handle routing and delegates to vert.x core lib as if it would be a module. Play would continu to handle rest requests and vert.x would handle sockets (not all the app needs realtime)

Do you think this could be possible ? is it a better way ?

thanx Fred

[Tim Fox]

One thing I would be interested in knowing: What is it about the Play framework that continues to make you want to use it instead of using Vert.x for the whole of your application?

If we can offer an end-end realtime web app solution in Vert.x, there shouldn't be any need for Play. I'd like to know where the gaps are currently in Vert.x so we can fill them.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/vertx/-/r6vUq1ZrJswJ.
To post to this group, send an email to ve...@googlegroups.com.
To unsubscribe from this group, send email to vertx+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/vertx?hl=en-GB.

[Frederic Masion]

Hi Tim,

The reasons are not about what misses to vert.x. My next project will probably use vert.x alone and I'm a great fan of what you're doing.

The first reason is the legacy code. The projet started on play 1.2.4 then we have migrate on play 2.0 at this time I didn't know about vert.x. 

Now it would be a lot of work to rewrite the logic in an event base paradigm.

Secondly their's still one point where I don't feel confortable with (maybe because I need more practice with vert.x) it is about transaction handling and ACID database opérations. 

The app we're writing has a complicated model with a lot of referential dependencies.

Actualy for this use case I feel more comfortable with this imperative type of developement (as in a complicated sequential diagrams I can easily identify transactional demarcation). 

I have difficulties to project myself in event base dev for this use case. May be the hole database operation should be defered in a worker ? if so why wouldn't it be possible to delegate this opération to play as a peer ?

Last Play is a great framework, part of my team knows it and is already productive. Play is a full stack framework. Compilation is done on page reload (F5 programing) The compilation also include assets (coffeeScript and Less analysis etc...)

Play has an other approache to acheive the same goal as vert.x it handles concurency with the akka actor model and non blocking io with iteratee, enumerator...pattern

I think the main objective is not to determine if vert.x is better than play. I think it depends on uses cases and I would be nice to have choice. Some time I feel it is easer in one way some time in the other. maybe it's only a matter of experience.

Each come with solution that I feel more confortable with depending on the use case. Why should I have to choose if I can have the benefits of both ?

If I dare giving you one tip to make vert.x better it would be to include a real life exemple app (not only an echo on different network protocol) and add a section in the documentation to illustrate how verticles can collaborate to solve a non trivial problem.

I think it would be interesting to explain how to shift your mind to an other developement model. how to transpose the transactional problem would also be nice. I think this points would ease vert.x adoption.

Do you think my approach merging play and vert.x is still invalid ?

In the same way I think Glyn Normington's attempt to merge virgo OSGi server and vert.x could be really great : a real time non blocking solution and a container that permit's to deploy services and verticles with version management via the web console without stoping the service : wow ! a golden hammer for log analysis, ad servers and every service you can't stop for maintenance etc... +1

 

So Any idea on the way to provide to vert.x an already existing Netty httpServer instance ?

thanx Fred

[Stéphane Maldini]

Tim, 

To summarize main differences I'm aware of with Play :

• Conventions and Artifacts : Domains, Controllers, Routes, Config, Views, Assets... I think this is the top 1
• Build System and project lifecycle management  (SBT), profiles (prod, test, dev) 
• Debug friendly : Error pages in development, static checking etc
• View technology
• Promise/Iteratee/Enumerator : Rich Streaming support
• Plugins architecture, integrated with project lifecycle management, good repository length
• Hot Reloading
• Scala
• Doc directly included when you first start app
• IntelliJ support
• Command to init project skeletons
• Declarative configuration of Akka subsystem ( threadpools , load factor etc)
  
• Massive PR, leveraging Typesafe hypeness and good UI apps

As Play is also inspired from Grails, minus the Spring techs, here the differences with it :

• Conventions and Artifacts : Domains, Controllers, Routes, Config, Views, Resources... 
• Build System and project lifecycle management (Homegrown, Ivy), profiles (prod, test, dev) 
• Spring backed apps, integrate easily with
• Servlet API and War generation
• Debug friendly : Error pages in development, part static checking, 
• Dev command scripts and console
• View technology
• Rich Database support (Both SQL and NoSQL)
• Plugins architecture, integrated with project lifecycle management, large repository length
• Hot Reloading
• Excellent IDE support
• Detailled online doc and good resources on the interwebz
• Rely on containers for web threading or plugins for events bus, actors etc
  
• Mature tech, still evolving, interested in systems like Vert.x

[R. Rajesh Jeba Anbiah]

On Aug 21, 4:53 am, Stéphane Maldini <stephane.mald...@gmail.com>
wrote:

> To summarize main differences I'm aware of with Play :

<snip points>

With Vertx?

> As Play is also inspired from Grails, minus the Spring techs, here the
> differences with it :

<snip points>

With what?

Do you mean to prefer Play! than Vertx?

[Stephane Maldini]

Yes I compare just raw differences with Vertx.

No it doesnt mean Play! is better. As stated, Play! is a full stack web framework. Vert.x is very unique and can serve wider purposes (well you can argue that every frameworks can do that depending of your use). Vert.x is a polyglot Node.js running on JVM, and people now tends to like micro framework and compose their stack themselves. Plus its event-bus is very unique and so much scalable.

The right tool for the right purpose.

These last days I've worked on integrating Grails with Vert.x using embedded container/vertx. It's a first step to close the gap btw a full stack web framework and Vert.x amazing capabilities.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.

To post to this group, send an email to ve...@googlegroups.com.
To unsubscribe from this group, send email to vertx+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/vertx?hl=en-GB.

--

Stéphane MALDINI

--

[R. Rajesh Jeba Anbiah]

On Aug 23, 2:10 pm, Stephane Maldini <stephane.mald...@gmail.com>
wrote:

> Yes I compare just raw differences with Vertx.

> No it doesnt mean Play! is better. As stated, Play! is a *full stack*
> *web *framework.

> Vert.x is very unique and can serve wider purposes (well you can argue that
> every frameworks can do that depending of your use). Vert.x is a polyglot
> Node.js running on JVM, and people now tends to like micro framework and
> compose their stack themselves. Plus its event-bus is very unique and so
> much scalable.
>
> The right tool for the right purpose.

Thanks for the clarification. BTW, did you mean Play! 1.2.x or 2?
And, Java or Scala?

> These last days I've worked on integrating Grails with Vert.x using
> embedded container/vertx. It's a first step to close the gap btw a full
> stack web framework and Vert.x amazing capabilities.

If possible, can you share some insights? I don't quite understand
why you need to use Vertx along with Grails. From my understanding, if
we need HTML view, we can use Play! or Grails. For, API/SOA based
sites, we may use Vertx or DropWizard along with Backbone.js.

[Stephane Maldini]

On Thu, Aug 23, 2012 at 3:28 PM, R. Rajesh Jeba Anbiah <ng4rrj...@rediffmail.com> wrote:

On Aug 23, 2:10 pm, Stephane Maldini <stephane.mald...@gmail.com>
wrote:

> Yes I compare just raw differences with Vertx.

> No it doesnt mean Play! is better. As stated, Play! is a *full stack*
> *web *framework.

> Vert.x is very unique and can serve wider purposes (well you can argue that
> every frameworks can do that depending of your use). Vert.x is a polyglot
> Node.js running on JVM, and people now tends to like micro framework and
> compose their stack themselves. Plus its event-bus is very unique and so
> much scalable.
>
> The right tool for the right purpose.

   Thanks for the clarification. BTW, did you mean Play! 1.2.x or 2?
And, Java or Scala?

I meant Play 2 (I think it applies to Play 1 as well). Scala or Java doesn't matter here its just about the web features. 

 

> These last days I've worked on integrating Grails with Vert.x using
> embedded container/vertx. It's a first step to close the gap btw a full
> stack web framework and Vert.x amazing capabilities.

    If possible, can you share some insights? I don't quite understand
why you need to use Vertx along with Grails. From my understanding, if
we need HTML view, we can use Play! or Grails. For, API/SOA based
sites, we may use Vertx or DropWizard along with Backbone.js.

Grails is much more than serving views, this is a development toolkit as well. Reload agent, scripts, build lifecycle, plugins. Vert.x is more than a performant backend for JS apps, it's an event bus and non blocking api.

Combining both could result in the same goal than Play+Akka -> Verticle could be actors, incoming request could be forwarded to grails processors using verticles/event bus, everything could be ran async, except the servlet requests. This would be a second step, extract enough grails facilities from the servlet bound api and applies it to Vert.x through Mod, lightweight web framework or something else.

The concrete result at this moment is your Grails app can communicate with your vert.x app using the same bus, useful if you have a mixed app with realtime features and backend. You can also cluster 2 grails app leveraging the event bus from vert.x since it's embedded in each Grails.

 

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To post to this group, send an email to ve...@googlegroups.com.
To unsubscribe from this group, send email to vertx+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/vertx?hl=en-GB.

--

Stéphane MALDINI

--

[R. Rajesh Jeba Anbiah]

On Aug 23, 7:44 pm, Stephane Maldini <stephane.mald...@gmail.com>
wrote:
<snip>

> Grails is much more than serving views, this is a development toolkit as
> well. Reload agent, scripts, build lifecycle, plugins. Vert.x is more than
> a performant backend for JS apps, it's an event bus and non blocking api.
>
> Combining both could result in the same goal than Play+Akka -> Verticle
> could be actors, incoming request could be forwarded to grails processors
> using verticles/event bus, everything could be ran async, except the
> servlet requests. This would be a second step, extract enough grails
> facilities from the servlet bound api and applies it to Vert.x through Mod,
> lightweight web framework or something else.
> The concrete result at this moment is your Grails app can communicate with
> your vert.x app using the same bus, useful if you have a mixed app with
> realtime features and backend. You can also cluster 2 grails app leveraging
> the event bus from vert.x since it's embedded in each Grails.

Thanks a lot for sharing insights.