Vert.x and Dropwizard

[Kenneth]

Hi!

OK, first the usual disclaimers: I'm pretty new to vert.x so the architecture behind my idea might be broken. In fact, that's one of the things I want to to find out.

I'm a big fan of Dropwizard (a java REST glue stack), and right now I'm looking at using it together with vert.x on a project. Specifically I need to implement a bunch of REST APIs that should handle incoming orders. I'll describe my (very simplified) architecture so that you get the feel of my domain:

An order can consist of a number of products. Each product can be bought separately and each product is different from each other. As such,  the order is just a wrapper for products (like a shopping cart).

Orders are going to be picked up asynchronously, persisted to a database and then split up. Each product in an order is then going to be processed separately. Again, this is an extremely simplified and "constructed" example architecture, just to be able to get the discussion going. Illustration:

OK... my questions are:

1) Anybody got any experience with using vert.x in a manner similar to this? That is, with an existing "servlet front" that dispatches stuff to the event bus. If so, how did you did you initialize vert.x? Alternatives I have thought of:

• a) Let the servlet app be as it is, and just bundle/embed the vert.x eventbus stuff and communicate with vert.x through the PlatformManager thingy.
  
• ...or b) Wrap you servlet app in a vertx module and do something clever to start the whole shebang as a native vert.x module

2) If not Dropwizard, what kind of RESTful application stack for Java do you prefer using for vert.x. Please don't tell me that you don't see the point in using a REST framework, and that I should simply just create a http listener and implement jax-rs myself.

3) Anybody know any good REAL LIFE examples/architectures for vert.x beyond the echo examples?

Thanks a lot for any answers or comments!

Regards, Kenneth

[Mikael Karon]

Have you seen http://github.com/englishtown/vertx-mod-jersey/ ? Full jax-rs with access to all vertx stuff beneath.

/ Mike 

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Ken Yee]

On Thursday, October 3, 2013 3:08:21 PM UTC-4, Kenneth wrote:

Orders are going to be picked up asynchronously, persisted to a database and then split up. Each product in an order is then going to be processed separately. Again, this is an extremely simplified and "constructed" example architecture, just to be able to get the discussion going. Illustration:

I'm a big DropWizard fan as well :-)
But have you thought about using SpringBatch instead?  Seems a bit more like what you want to use it for.  I've been looking at the three different Spring/Dropwizard integrations so far, but none of them has jumped out as obviously the best way to use it.

Of your options of using vert.x, I'd use (1)...just embed a communications stack for Vert.x into DropWizard.

[Kenneth]

No I didnt see that one. Thanks for the tip!

[Kenneth]

Do you mean SpringBoot? Yep, I have seen that. At least for now I think Dropwizard wins the battle of being the best REST stack since it is not trying to be a full web application stack, like Spring Boot. But with the heavy Spring-movement to back it up, it is a very interesting project.

I also did a lot of investigating when trying to combine Spring with Dropwizard, and looked at 3-4 alternatives. The best I found was using jacek99's approach as examplified here: https://github.com/jacek99/dropwizard-spring-di-security-onejar-example. It has worked out pretty nice so far, and it does not feel hacky.

As for combining with vert.x. An alternative for my project would of course be to treat my rest front end completely separate from the vert.x part, and having a "job discover verticle" by reacting to file or database changes. Might not work out well in real life though, and I suspect that I would be implementing some kind of variant of (1a)

[Kevin R. Pastorino]

No real world experience but "non-real world possibility", I think this should "work":

 

1)  Copy the whole example code from - vertx examples/  java /  eventbus_pubsub / Sender.java   straight into you servlet source.  (You'll need to include the vertx jars.)

 

2)  Initialize vertx and send to the receiver:

Sender sender   = new Sender();
sender  .setVertx            ( VertxFactory.newVertx() );
sender  .start               ();

sender.send ( 'address_you_choose', "order info, function( reply )
{});

 

3)  use  vertx examples/  java /  eventbus_pubsub / Receiver.java as a starting point.

[Chris Micali]

Kenneth,

    We are building a similar architecture.  We are using Dropwizard for all of our services and Vert.x for one specific piece.  I have built a small glue library that lets you host Vert.x verticles in a Dropwizard service (so you can just deploy everything as Dropwizard services.  If you're interested in this I'll see if I can get it on github.

-c

On Thursday, October 3, 2013 3:08:21 PM UTC-4, Kenneth wrote:

[Norman Maurer]

Sounds interesting.... Go for it

--

[Ken Yee]

On Friday, October 4, 2013 3:29:21 AM UTC-4, Kenneth wrote:

Do you mean SpringBoot?

Nope.  I meant SpringBatch: http://docs.spring.io/spring-batch/

Seems like you're doing essentially some sort of async batch processing with what you want to do w/ Vert.x...

[Chris Micali]

Kenneth,

   I uploaded what I have so far at http://github.com/sagedevices/dropwizard-sage - You can check the example app to see how it works.  

-chris

On Thursday, October 3, 2013 3:08:21 PM UTC-4, Kenneth wrote:

[Kenneth Leine Schulstad]

Chris,

Thanks a bunch! Will have a look at this and let you know how it works out :-)

2013/10/6 Chris Micali <chris....@sagedevices.com>

--
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/Yx98InzBgaI/unsubscribe.
To unsubscribe from this group and all of its topics, send an email to vertx+un...@googlegroups.com.

[Kenneth Leine Schulstad]

Ken,

Don't think Spring Batch is a good fit for us. The example is a bit constructed, so that might be misleading. but thanks for the suggestion though... 

2013/10/7 Kenneth Leine Schulstad <ken...@leine.cc>

[Tim Fox]

I'm curious - why use dropwizard for the REST part, not Vert.x?

--

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

To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.

[Kenneth Leine Schulstad]

Mostly because I don't see any support in vertx for a lot of the "glue code" that's conventient to have for REST services. A framework like Dropwizard provides this (and in a well-opiniated, dev-op friendly way that). Another reason for building REST-stuff on Dropwizard is of course also because this represents a stack that I know. As already mentioned in this thread, initiatives like https://github.com/englishtown/vertx-mod-jersey/ might help, but then I would still be needing to implement a lot of boiler plate myself. 

But I'm humble here, my approach might be a bit broken. Please let me know if you sense major disturbances in the force here. The ideal situation would maybe be to have something like Dropwizard being kicked off by and participating more "natively" with vert.x.

2013/10/7 Tim Fox <timv...@gmail.com>

--
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/Yx98InzBgaI/unsubscribe.
To unsubscribe from this group and all of its topics, send an email to vertx+un...@googlegroups.com.

[Jez P]

Hi Kenneth, 

I kind of agree and disagree with you on this. 

Agree that a dropwizard-like framework built on vert.x would be a good thing, disagree because I don't think it's core vert.x (which is an overall platform). In the same way that yoke provides a web framework for vert.x, it makes sense for someone who wants to use vert.x for RESTful services to start work on an opinionated add-on module which offers some/all of what dropwizard offers. 

Vert.x is a more general platform than a web platform, though it offers ease of building of web functionality, but there's nothing to stop anyone implementing an opinionated RESTful module on top of it. I'm sure there are some REST modules out there already in various states of maturity, though I doubt many of them offer everything dropwizard does.

Cheers,

Jez

[Kenneth Leine Schulstad]

Then I don't think we disagree. I'm not missing this kind of thing from core vert.x. I meant that it would be nice to have this as an "add-on module" like you say. (I also think that the existence of such an add-on functionality might boost the adoption of vert.x in general.)

Different kinds of animals that bridge the gap between "low level" vert.x and established tools/frameworks are starting to pop out of the bushes. And I think that a Vertwizard-kind of thing would be very interesting addition to the zoo.

2013/10/7 Jez P <mr.n...@gmail.com>

[Mikael Karon]

Just to add a little bit of context here regarding Jersey and REST. Jersey is the JAX-RS (JSR 311 & JSR 339) reference implementation, and vertx-mod-jersey is more or less wiring Jersey to use Vertx rather than a servlet.

When you mention "glue code", what exactly are you referring to? I ask because from our experience implementing REST services in JAX-RS has virtually no glue or boilerplate code.

/ Mike

[Kenneth]

The glue that I'm referring to are stuff like configuration handling, validation, statistics, error reporting, and in general all the pieces that you would normally end up implementing in addition to jersey. Also I find that having an opninated application structure, patterns and conventions helps out a lot. As such jersey is only one of the building blocks in such a stack.