Microservices, Vert.x, Spring Boot

[Jamie B]

After evaluating Vert.x for a few weeks and then doing some wider research, I wonder what people consider to be the main benefits of using Vert.x over Spring Boot (and supporting packages)?

It seems to me that Vert.x provides some nice out-the-box functionality, but is held back by; no solution for callback hell (where are Promises?), horrible module system (honestly, it really is) and generally too prescriptive for many applications.

Having evaluated Spring Boot + Reactor, it seems you can get all the benefits of a micro framework with asynchronous handlers (when you want or need them) whilst avoiding nested callbacks with Promises and chained calls. With this comes all the normal benefits of a Spring managed application (annotation driven config etc). They are also addressing monitoring, service discovery/registry, api routing with the spring cloud project. From these Vert.x only really has service discovery (via HZ) which appears to be protected from the developer so is only really useful for Vert.x internals (ESB).

This is not meant to be a knock down of Vert.x, perhaps some of these issues are getting addressed in 3.0? I'm just wondering where the future of Vert.x lies and it's specific advantages over the Spring alternatives. I really liked Vert.x to begin with, but after using Spring Boot, I just feel so much more at home and confident about integrating services in the long term.

[Tim Fox]

Do you work for Pivotal? ;)

Where to start... I've tried to answer your questions below.

On 17/09/14 16:54, Jamie B wrote:
> After evaluating Vert.x for a few weeks and then doing some wider research, I wonder what people consider to be the main benefits of using Vert.x over Spring Boot (and supporting packages)?
>
> It seems to me that Vert.x provides some nice out-the-box functionality, but is held back by; no solution for callback hell (where are Promises?),

No solution for callback hell? There are several promises libraries and
other similar ways of mitigating callback hell (e.g. RxJava) which can,
and commonly are, used with Vert.x.

See https://github.com/vert-x/mod-rxvertx for example. RxJava, if you're
not aware of it, is like promises on steriod. It takes the idea of
promises and extends them to streams of data which can be composed in
many powerful ways. Project reactor's Composable is similar to what you
can do in RxJava but the latter is arguably more powerful.

Vert.x 3.0 is going to have automatic Rx-ification of APIs. So you can
use the simple callback style API if you wish, but we will offer
Rx-ified version for all our APIs too.

> horrible module system (honestly, it really is)

The module system no longer exists in Vert.x 3.0. I posted an update on
Vert.x 3.0 in this group just yesterday. There's some more information here.

> and generally too prescriptive for many applications.

Can you elaborate?

>
> Having evaluated Spring Boot + Reactor, it seems you can get all the benefits of a micro framework with asynchronous handlers (when you want or need them) whilst avoiding nested callbacks with Promises and chained calls.

As you do in Vert.x

> With this comes all the normal benefits of a Spring managed application (annotation driven config etc).

Now, aiui, you're talking about Spring framework, not project reactor.
Apples vs Oranges. Spring Framework has been around for a long time and
is a big stack. You can't compare it to Vert.x. And in any case, you can
use Vert.x in Spring if you want anyway, just like you can with reactor.
This becomes even easier in Vert.x 3.0.

> They are also addressing monitoring, service discovery/registry, api routing with the spring cloud project.

Again, you're comparing the Spring Framework to Vert.x. Seems an unfair
comparison. But in any case, as mentioned above, if you want to use
stuff from the Spring stack with Vert.x, there's no real reason why you
can't do that, especially in Vert.x 3.0. However, if you do use Spring
stuff with any async framework, bear in mind that many things in Spring
are inherently blocking, so will limit your scalability.

> From these Vert.x only really has service discovery (via HZ) which appears to be protected from the developer so is only really useful for Vert.x internals (ESB).

This is not really true. You are saying "Hey I can use project reactor
with <insert some other library here> and now I've got all this great
<long list of functionality>". Well, you can do just the same with Vert.x.

>
> This is not meant to be a knock down of Vert.x, perhaps some of these issues are getting addressed in 3.0? I'm just wondering where the future of Vert.x lies and it's specific advantages over the Spring alternatives.

Other advantages of Vert.x:

* Super high performance. I don't think Spring/Reactor even comes close:
http://www.techempower.com/benchmarks/#section=data-r8&hw=i7&test=plaintext

* Polyglot. I lose count of the number of languages we support. Reactor
supports Java and Groovy.

* We are building a full async stack for Vert.x 3.0. So while you can
(if you want) use it with Spring Framework (just like you can with
reactor), you'll also be able to use the async services we provide to
give the best performance and scalability end to end.

> I really liked Vert.x to begin with, but after using Spring Boot, I just feel so much more at home and confident about integrating services in the long term.
>

I strongly recommend you look at the work we are doing with Vert.x. It
does everything reactor does and more (well reactor does quite a lot
less than Vert.x, so it's not really hard), and we have loads of goodies
in there. You can use it with Spring Framework if you want. It's way
more polyglot than anything from Spring, and we have top end performance.

[And a bit of history.... I started Vert.x when I was at VMware. When I
left VMware project reactor popped up, so it's clearly inspired from
Vert.x..]

[bytor99999]

I will add one more thing to Tim's reply. You can use Spring inside a Vert.z app too. I created the mod-spring-appcontext module to do just that. We use it in our app. And with embedding Vert.x inside our Spring MVC app we can now communicate between our Spring MVC app and our Vert.x app using the eventBus. 

And while not any argument, this module and embedding Vert.x into a Spring app was around before Spring Boot even got released. We have been doing this for at least the past year and a half.

Mark

[Pedro Mata-Mouros]

Pedro.

On 17 Sep 2014, at 17:27, Tim Fox <purpl...@gmail.com> wrote:

It seems to me that Vert.x provides some nice out-the-box functionality, but is held back by; no solution for callback hell (where are Promises?),

No solution for callback hell? There are several promises libraries and other similar ways of mitigating callback hell (e.g. RxJava) which can, and commonly are, used with Vert.x.

See https://github.com/vert-x/mod-rxvertx for example. RxJava, if you're not aware of it, is like promises on steriod. It takes the idea of promises and extends them to streams of data which can be composed in many powerful ways. Project reactor's Composable is similar to what you can do in RxJava but the latter is arguably more powerful.

Vert.x 3.0 is going to have automatic Rx-ification of APIs. So you can use the simple callback style API if you wish, but we will offer Rx-ified version for all our APIs too.

Also https://github.com/englishtown/vertx-mod-when.

Pedro.

[Stephane Maldini]

Just a quick edit Tim: There is no benchmark per se on Reactor in techempower

Actually we use Ratpack for microservice on top of Spring, https://github.com/SpringOne2GX-2014/reactive-geocoder.

Ratpack and Reactor implement Reactive Streams and RxJava is about to do the same with the help of the very same committer of Ratpack and the heroes from Netflix.

--
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/d/optout.

--

Stéphane

--

[Joseph Sintim-Amoah]

Tim,

I really like your work, and it is helping a lot of projects including my own. I also agree to everything you noted in your reply to the above.

In the past, I have used Axon framework - really liked it, and also I have tried reactor before venturing into Vert.x. The only thing I not sure how it is implemented in Vert.x is the event bus system. With reactor and Axon, one can literally process millions of events per second(using the LMAX Disruptor library).

My question is have you compared (benchmark) it with the number of events per second a Vertx can handle(assume all other things are equal - equal ram, core, drivers, cpu, etc). Do you have any numbers if you have benchmark it; and if you have some sample code to share.

If the LMAX Disruptor is not part of Vert.x, it that something that we can expect in the near future? If that could ever happen, I would be stuck on Vert.x for life, because I believe it to be the best lightweight framework so far with all it capabilities, clustering, etc).

Thanks for all your hard work and keep it up. Lots of people are using your project so you can be proud of yourself regardless.

Joe

[trueb...@gmail.com]

We are currently working on a large scale enterprise application taking a microservice approach with Spring Boot at its core. I also happen to do some prototyping in vertx3. I wonder if it is legitimate to even compare those two platforms. If I had to give it a try, I would say the main differences are:

- Vertx is reactive, Spring isn't: 

Vertx uses asynchronous messaging, a mechanism that scales. It is particularly useful in mircoservices because messages do not care whether you send them across the network or locally in the same JVM. You can start with a monolith and do not have to decide upfront how to divide your application logic into microservices. Down the road if you decide to modularize your application into independently deployable mircoservices, you just change the packaging, not the code! That's a big win.

With Spring you have different mechanisms for local (method call on the stack) and remote communication (probably JSON/HTTP). That means you have to decide on your service boundaries upfront. That has been a big issue for us.

And "no", Spring does not support asynchronous messaging. Spring's AsycRestTemplate is an abomination.

- Spring is opinionated and heavyweight, Vertx is very raw/lightweight:

This has pros and cons. If you do everything the Spring way, if there is an annotation for all of your use cases, then you are fast and productive. Once you need something Spring does not support out of the box, then the pain begins. You have to fight against the framework and employ hideous hacks and workarounds. You will also find yourself debugging for hours and try to understand what magic causes your code to fail. That's true for most frameworks and not limited to Spring.

Vertx is more like a toolkit, very raw and down to the bone. That makes it very flexible because it allows you to tailor and tune the application according to your needs. On the downside this means, that you might have to write more code or build a library yourself. A simple annotation just won't do it. At first I considered this a drawback, but over the time I really appreciated that fact. I also have a much better understanding of how http-servers/-clients work because I had to think about it.

- Testing asynchronous code is hard:

Whether you are using Vertx, RxJava (Observables) or Akka, testing is simply not as straightforward as testing traditional, synchronous, blocking code. Same for debugging. It takes some time to get used to it. Spring on the other hand makes it easy to test your code.

What I really like about testing in Vertx are the rapid turnaround cycles. You can almost TDD on integration- and system-level tests because the startup time is so ridiculously fast. 

- Springs ecosystem is huge and it's easier to find help online:

I personally will always choose Vertx over Spring. For me, next to Vertx Spring feels too heavyweight and bloated. The abuse of annotations is obvious. But that's just my personal preference.

Hope that helps.

[Mik Quinlan]

Hi Jamie

We recently did an eval of Vertx against some of the technologies in this thread.  Our main concern was performance, although we found unit testing (JUnit) and acceptance testing (using Cucumber BDD) pretty straight forward.  We are going to be blogging about our results, but here is an early view of the performance numbers.  YOu will see that the standard deviation at the 99th percentile for Vertx is incredible.  In our tests, this was only surpassed by Go (results not documented here).

Hope this helps.

Mik

Performance Results

• SLA = no more than 50ms slower than upstream server response at the 99th percentile. e.g. if upstream takes 50ms, the Vertx proxy cannot take longer than 100ms at the 99th percentile.

• Test framework: https://github.com/wg/wrk/wiki/Installing-Wrk-on-Linux

• Hardware: AWS m3.xlarge with 4 cores all in same AWS zone

  • One instance running downstream mock service
  • One instance running app under test and wrk

• Call: wrk --latency -c 1000 -t 1 -d 50s --timeout 17s http://localhost:8080/ud/wait/15000

• 1 thread, 1000 connections, looped call for 50 seconds. Calls app under test which proxies onto a test server that waits 15000ms before replying. Run a minimum of 3 times before times are recorded and 3 runs recorded.

Vertx with 1 verticle.

Framework	Avg	Stdev	Max	50%	75%	90%	99%
Vertx (1v)	15.03s	5.91ms	15.04s	15.03s	15.04s	15.04s	15.04s
Vertx (1v)	15.03s	5.91ms	15.04s	15.03s	15.04s	15.04s	15.04s
Vertx (1v)	15.10s	197.88ms	15.83s	15.03s	15.03s	15.22s	15.83s

Vertx with 4 verticles, taking advantage of all cores.

Framework	Avg	Stdev	Max	50%	75%	90%	99%
Vertx (4v)	15.02s	3.92ms	15.03s	15.02s	15.03s	15.03s	15.03s
Vertx (4v)	15.02s	4.35ms	15.03s	15.02s	15.03s	15.03s	15.03s
Vertx (4v)	15.03s	10.99ms	15.07s	15.03s	15.04s	15.04s	15.06s

Framework	Avg	Stdev	Max	50%	75%	90%	99%
Ratpack	15.06s	174.38ms	16.05s	15.03s	15.03s	15.04s	16.04s
Ratpack	15.02s	220.60ms	16.04s	15.02s	15.03s	15.05s	16.04s
Ratpack	15.02s	330.52ms	16.24s	15.02s	15.03s	16.02s	16.24s

Framework	Avg	Stdev	Max	50%	75%	90%	99%
Undertow	15.14m	277.60ms	16.04s	15.02s	15.03s	15.42	16.04
Undertow	15.11m	243.80ms	16.03s	15.02s	15.02s	15.42	16.03
Undertow	15.16m	339.03ms	16.65s	15.02s	15.02s	15.83	16.65

• Extra test to saturate over a period of time
• wrk --latency -c 1000 -t 1 -d 5m --timeout 17s http://localhost:8080/ud/wait/150

Framework	Avg	Stdev	Max	50%	75%	90%	99%	Requests
Vertx	170.63ms	3.17ms	284ms	170ms	170ms	171ms	182ms	1,757,517
Ratpack	184.50ms	95.96ms	3.17s	170ms	176ms	181ms	386ms	1,628,271
Undertow	170.36ms	8.09ms	1.17s	169ms	170ms	171ms	180ms	1,757,202

[Rick Hight]

I have used Vertx at sites that have traffic that looks like a denial of service attack. Spikey as hell.

Vertx works in the real world. 

We wrote a service that handles 10x more traffic on 10 servers that another similar app runs on 2,000 servers using a traditional stack. 

We did cloud load testing and our hardware load balancer was dying before our services running in Vertx were. 

Vertx is bad ass. 

I wrote a lib that works with Vertx based on my experience with it. 

https://github.com/advantageous/qbit

The lib focuses on Java Microservice Development (HTTP/REST/WebSocket/JSON).

The lib has an RPC WebSocket lib and add Spring MVC style REST annotations to Vertx. 

The lib uses the fastest JSON parser which is 4x faster than the rest for the REST/WebSocket message use case.

The lib implements an efficient batch/queue system that can adjust based on back pressure. It can handle 100M++ ping pong messages easily.

Disruptor is great tech. But... it has some performance issues that make it possible not the best thing for every use case. 

You have to know the engineering tradeoffs. 

This lib was originally written to be embedded inside of Vertx, but on the last few projects, I had to use Vertx embedded inside of it (more politics than tech).

I plan on documenting how to embed it with Vertx.

You work with it like this:

@RequestMapping("/todo-service")
public class TodoService {

    @RequestMapping("/todo/count")
    public int size() {...

    @RequestMapping("/todo/")
    public List<TodoItem> list() {...

    @RequestMapping("/adder-service")
    public class AdderService {

        @RequestMapping("/add/{0}/{1}")
        public int add(@PathVariable int a, @PathVariable int b) {...
    }

There are about 200 pages of docs. 

We just added support for integration with Consul and etcd. 

I plan on documenting the libs use with Vertx for Spring MVC style REST, WebSocket RPC, and integration with Consul and etcd from Vertx w/o including 3rd party libs for HTTP etc.

I also plan on publishing some benchmarks for REST/JSON using annotations like the above... Let me give you a hint. It kills the competition. 

On Wednesday, September 17, 2014 at 9:27:33 AM UTC-7, Tim Fox wrote:

Do you work for Pivotal? ;)

Where to start... I've tried to answer your questions below.

On 17/09/14 16:54, Jamie B wrote:

> After evaluating Vert.x for a few erweeks and then doing some wider research, I wonder what people consider to be the main benefits of using Vert.x over Spring Boot (and supporting packages)?

[Mik Quinlan]

Hey Rick

If your library rocks as much as Slash doing a long guitar solo, then I can't wait to see version 1.0.

Would be great if it was considered for integration with Vertx officially.

Mik

[Rick Hight]

Mik,

We have discussed including it. 

I have these pesky things called clients.

They get to set a tremendous amount of direction in what I work on. :)

But I also get to live in a nice house and my kids get to go to a nice school. 

Clients have their upside.

BTW

The link you quoted wrt wrk on Linux. Look who wrote it.

https://github.com/wg/wrk/wiki/Installing-Wrk-on-Linux/_history

I have been perf tuning with Vertx for years. Lost so much sleep tweaking Linux, JVM and Vertx. 

I also wrote Boon:

http://www.infoq.com/news/2014/04/groovy-2.3-json

QBit is doing well and I wrote it to work with Vertx from day one.

If you dig around real hard, you can find benchmarks I have done with QBit+Vertx vs. some others. 

I just don't like all of the personal attacks when you publish benchmarks. 

I am waiting until I think QBit is ready. :)

Give it time. I am emerging out of my shell. :)

Now back to work for me. I owe. I owe. Off to work I go.

https://github.com/advantageous/qbit

But if you want to look at QBit and Vertx integration. I am sure Tim will look at a pull request. 

[Mik Quinlan]

Nice!

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

[Joseph Sintim-Amoah]

Rick, your lib seems like a great addition to Vert.x. General documentation on its usage(together with Vert.X) will be very appreciated.

Hopefully we seem some movement on this soon :-)

--
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/ULSbuw6J27w/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.

--

Joseph Sintim-Amoah
Senior Software Engineer, Consumer Platforms

One LifeWay Plaza
Nashville, TN 37234

joseph.si...@lifeway.com

http://tech.lifeway.com

[Rick Hightower]

Ok. I will work on it. 

I have been working on the consul integration.

https://www.consul.io/

I will write up some tutorials on how to use QBit inside of Vertx. 

I might have to tweak some APIs/Builders. 

Rick Hightower
(415) 968-9037
Profile 

[Joseph Sintim-Amoah]

That will be awesome bro. Very interested. Give us a full working example from different perspectives, netservers, websocket, and a for instance a standard end to end application(a simple blog posting app may suffice).

I think a lot of people will appreciate it and help all the folks who only believe in Scala and Akka persistence - not that it is not a good solution - because I use Scala and Akka myself, but I believe Vert.x in conjunction with you lib, will be the of of the best things that happened to Vert.x.

Thanks again Rick.

[Tim Fox]

+1

A good summary

On 11/03/15 00:24, trueb...@gmail.com wrote:
> We are currently working on a large scale enterprise application taking a
> microservice approach with Spring Boot at its core. I also happen to do
> some prototyping in vertx3. I wonder if it is legitimate to even compare
> those two platforms. If I had to give it a try, I would say the main
> differences are:
>
>

> *- Vertx is reactive, Spring isn't: *

> Vertx uses asynchronous messaging, a mechanism that scales. It is
> particularly useful in mircoservices because messages do not care whether
> you send them across the network or locally in the same JVM. You can start
> with a monolith and do not have to decide upfront how to divide your
> application logic into microservices. Down the road if you decide to
> modularize your application into independently deployable mircoservices,
> you just change the packaging, not the code! That's a big win.
> With Spring you have different mechanisms for local (method call on the
> stack) and remote communication (probably JSON/HTTP). That means you have
> to decide on your service boundaries upfront. That has been a big issue for
> us.
> And "no", Spring does not support asynchronous messaging. Spring's
> AsycRestTemplate is an abomination.
>

> *- Spring is opinionated and heavyweight, Vertx is very raw/lightweight:*

> This has pros and cons. If you do everything the Spring way, if there is an
> annotation for all of your use cases, then you are fast and productive.
> Once you need something Spring does not support out of the box, then the
> pain begins. You have to fight against the framework and employ hideous
> hacks and workarounds. You will also find yourself debugging for hours and
> try to understand what magic causes your code to fail. That's true for most
> frameworks and not limited to Spring.
> Vertx is more like a toolkit, very raw and down to the bone. That makes it
> very flexible because it allows you to tailor and tune the application
> according to your needs. On the downside this means, that you might have to
> write more code or build a library yourself. A simple annotation just won't
> do it. At first I considered this a drawback, but over the time I really
> appreciated that fact. I also have a much better understanding of how
> http-servers/-clients work because I had to think about it.
>
>

> *- Testing asynchronous code is hard:*

> Whether you are using Vertx, RxJava (Observables) or Akka, testing is
> simply not as straightforward as testing traditional, synchronous, blocking
> code. Same for debugging. It takes some time to get used to it. Spring on
> the other hand makes it easy to test your code.
> What I really like about testing in Vertx are the rapid turnaround cycles.
> You can almost TDD on integration- and system-level tests because the
> startup time is so ridiculously fast.
>

> *- Springs ecosystem is huge and it's easier to find help online:*

[Tim Fox]

Hi Joe,

We haven't done any performance work in Vert.x 3.0 yet. I don't expect
it to be slow, but it could probably get much faster too.

Right now we are concentrating on getting it working correctly. If truth
be told, most users don't really need the very top end performance
anyway, some exceptions being some folks in financial services, but
that's really a niche market.

[Tim Fox]

+1

(For those who aren't aware: Rick is the go-to guy if you want to know
about real-world high-volume usage of Vert.x)

> @RequestMapping("/todo-service")public class TodoService {

>
> @RequestMapping("/todo/count")
> public int size() {...
>
> @RequestMapping("/todo/")
> public List<TodoItem> list() {...
>
>
>
> @RequestMapping("/adder-service")
> public class AdderService {
>
> @RequestMapping("/add/{0}/{1}")
> public int add(@PathVariable int a, @PathVariable int b) {...
> }
>

> <https://github.com/advantageous/qbit#qbit-philosophy>

[Rick Hightower]

Thanks dude. That goes right on my consulting bio. :)

Tim Fox says... :)

--
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/ULSbuw6J27w/unsubscribe.

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

For more options, visit https://groups.google.com/d/optout.

[bytor99999]

Talk about resurrection. I love how the OP never returned to this thread. 

Mark

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.

[Rick Hightower]

eh?

[bytor99999]

On Monday, June 1, 2015 at 10:48:49 AM UTC-7, Rick Hight wrote:

eh?

Jamie B

Is the OP.

Anyway, sorry to hijack an old thread and make it a non Vert.x discussion. ;)

Just my sense of humor.

Mark 

[dtree]

Mark,

Please post a Vert.x within Spring Boot sample code.  I am very interested in such a combination.

Thanks,

dtree

[bytor99999]

Sorry, I haven't used Spring Boot yet. Too busy with my current gig. I only have the basic Spring in Vert.x and Vert.x embedded in Spring at my Github account bytor99999

Also, I am worried that Spring Boot is just Spring Roo renamed, and Spring Roo just didn't work right. One of those builders that could build sample projects, but never real world projects.

Mark

[Thiago Moura]

Does anybody have a spring-boot vetx3 integration example ?

[Francesco Cina]

Have a look here:
https://github.com/ufoscout/demo-springboot-vertx3

It is a demo of a multi module maven project that uses Spring boot, nodejs and vertx3.
Cheers

[Tim Fox]

Except https://github.com/vert-x3/vertx-web/issues/104

[Tim Fox]

I've put together a simpler example here:

https://github.com/purplefox/vertx-springboot

It's basically the vertx-web static server example from the vertx-examples repo, but using SpringBoot to start everything up.

[Tim Fox]

So, what's the difference between this example and the original example
that uses Vert.x only:
https://github.com/vert-x3/vertx-examples/tree/master/web-examples/src/main/java/io/vertx/example/web/staticsite
?

Not much as far as I can tell!

The amount of code and boilerplate is pretty much the same.

The only discernible difference to me is the SpringBoot version fatjar
is much bigger than the Vert.x one, and the Spring version is a bit
slower to startup.

[Jez P]

In general not much. If you want to use JPA then there's a bunch more boilerplate (which Spring Boot handles pretty transparently). We use Spring+vert.x in my current client (Spring is primarily a local service container/discovery mechanism which we choose to use because many devs we have access to are far more familiar with Spring than vert.x, so we have a pretty straightforward wrapper around that which our vert.x code talks to, and which can be substituted with, for example, calls into another service container, via configuration rather than code changes).

Note that my current client, while using Spring within vert.x as this local service container, would most definitely not benefit significantly from using Spring Boot (it's not that hard to set up a persistence context for JPA if you want to use services backed by JPA). I personally think Spring Boot combined with vert.x doesn't offer very much over either/or but I'm open to being persuaded to the contrary by an argument which shows clear benefits from using the combination or by a project which actually shows a benefit.

[dtree]

This is not found by maven

<dependency>
  <groupId>io.vertx</groupId>
  <artifactId>vertx-web</artifactId>
  <version>3.0.0-SNAPSHOT</version>
</dependency>

This one has only milestone build

     <dependency>
       <groupId>io.vertx</groupId>
       <artifactId>vertx-core</artifactId>
-      <version>3.0.0-SNAPSHOT</version>
+      <version>3.0.0-milestone5</version>
     </dependency>
     <dependency>

[Tim Fox]

The example has now been added to vertx-examples:

https://github.com/vert-x3/vertx-examples/tree/master/springboot-example

[Tim Fox]

Yeah, Maven central doesn't contain snapshots so you'd have to tell it
to look in oss.sonatype (if you want the snapshot)

[dtree]

Adding this still won't give me snapshots

<distributionManagement>
  <snapshotRepository>
    <id>ossrh</id>
    <url>https://oss.sonatype.org/content/repositories/snapshots</url>
  </snapshotRepository>
</distributionManagement>

I'd prefer milestone build. But I can only find 3.0.0-milestone5 for vertx-core and not for vertx-web anywhere

[Julien Viet]

you need to use milestone6

-- 
Julien Viet
www.julienviet.com

--
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.

[dtree]

It looks like even though Vert.x can run within a Spring Boot app, Spring cannot manage it at all.  When I set up an AOP Aspect class, it cannot intercept any Vert.x called services, or the class itself.  The same service method can be intercepted through normal Spring managed calls.  I suspect Vert.x is creating its own instances every time and the Spring Singleton Bean declared is not even used by Vert.x, which means they cannot be integrated.

[Tim Fox]

Could you explain this in more detail? I'm not sure I followed

[Jez P]

+1, maybe with some sample code on github? I can't promise being able to help, but without seeing something concrete I'm sure I can't :)

[Amit Kumar]

What about the features that vert.x platform library offered in 2.0 (that I assume will be part of 3.0). I have not experienced any better deal than what vert.x had to offer there. e.g. verticle/module level HA (out-of-the-box). Look at its ease of use (just say -ha given a proper clustering configuration). Does Spring Boot even provide those options 

[Akter Hossain]

@tim, I want to handle all of my http request using executeBlocking or router's blockingHandler. 

My app is almost a CRUD app. 

I am also using spring jpa and services though.

Is it a good idea to use executeBlocking in all of my user requests? Also I don't want to use eventBus explicitly.

Please help me to take a better decision. I am in first stage of my project.

- jRoadie