Can Verticle Share the Same Routing Context......

[Andrew Abwoga]

I am a newbie in the business of reactive progamming. I have been trying out vertx. I was just wondering whether its possible for several deployed verticles to share a routing context.

[Nat]

RoutingContext is created for each request and each request belongs to one and only verticle. What is your need to share a routing context?

[Andrew Abwoga]

Well thanks for the info. I have an architectural constraint with regards to vertx. I am developing a web app using vertx and I need to modulerize my app in the best way possible. Let me give my case scenario:

I have module A and module B. They are both are REST API's. I am trying to avoid using different ports for both the Modules because I discovered that if I am to turn them to Verticles that will mean they have to use different ports. That is because I have to create a router i.e. Router router = Router.router(vertx); and I also have to create a server for the verticle to listen to a specific port for each verticle i.e. server.requestHandler(router::accept).listen(8080); 

So basically my question is how do I create the simple microservices without using different ports. I was thinking maybe create a main verticle for routing that will communicate with other moduless verticle via an event-bus. But what are the performance trade-offs?

[ad...@cs.miami.edu]

I think you should consider A and B to be individual worker Verticles: WorkerA and WorkerB.  One standard Vertical listens on the port (say 8080), and then depending on the request, it sends it over the event bus to be handled by either WorkerA or WorkerB.  This way you can keep your system as modules, and deploy the workers separately... either in the same JVM or over a cluster (local or otherwise).  I don't think you will notice any substantial over head if all in the same JVM, perhaps constant time of a  few mill-seconds across the event bus.

-Adam

[ad...@cs.miami.edu]

I recommended above to make two workers to handle A and B.  Of course, they do not need to be workers, perhaps two extra Standard Verticles would be better.  It depends on if you want event loops to drive A and B, or a more blocking style of execution.  The point is that I think A and B should be considered separate vericles that are deployed independently of another verticle that listens on http and communicates to A and B over the event bus.  I believe this will provide the architectural constraint you are looking for, and still have some great vert.x fun factor.

-Adam

[John Moscato]

Have you taken a look at Sub-routers? The docs have a nice example of adding a REST API to an existing router:

http://vertx.io/docs/vertx-web/groovy/#_sub_routers

I am in the process of doing exactly what the example shows, adding a REST API to a vertx 3 web application. I also wanted to modularize my application and not have multiple ports. Sub-routers are allowing me to keep the web application router and REST API router implementations in two separate files, but share one main HttpServer which is created in the main router verticle. In the main router verticle I call each sub-router class, passing the vertx instance to a static method. The static method sets up the router and returns a Router instance. Then, back in the main router verticle I call mainRouter.mountSubRouter() as shown in the docs.

I am using Groovy so my main router is in a Groovy script verticle, but I am using compiled Groovy for the sub-routers.

Since the sub-routers share the same HttpServer they run on the same port, but the difference is in the path prefix.

Hope that helps.

- John

[Andrew Abwoga]

Thanks John, I would like to try that out.

--
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/kXGEu5yQpaA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+un...@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/60f2b953-32c9-4348-a30e-d9cc46a538ef%40googlegroups.com.

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

Note: All emails sent from Strathmore University are subject to Strathmore’s Email Terms & Conditions. Please click here to read the policy.

"Visit our Facebook Page and Twitter Account".