Context Path Routing in CloudFoundry
Context Path Routing in CloudFoundry
I’d like to share a feature developed by the OSS Routing team at Cloud Foundry called Context Path Routing that should simplify creation and management of multiple microservices. This should save time for most of you by streamlining your development and reducing the complexity associated with many applications.
Join the DZone community and get the full member experience.Join For Free
See why enterprise app developers love Cloud Foundry. Download the 2018 User Survey for a snapshot of Cloud Foundry users’ deployments and productivity.
I’d like to share a feature developed by the OSS Routing team at Cloud Foundry called Context Path Routing that should simplify creation and management of multiple microservices. Although this was introduced late last year, we have just completed CLI support for it; so, this is a good time to review it. More importantly, this should save time for most of you by streamlining your development and reducing the complexity associated with many applications.
Most Cloud Foundry developers know that if you push your app to CloudFoundry and want to have data traffic reach that app and do something meaningful, you need to create and map a route to your app. The way you create a route is by adding a hostname to the domain. Here is an example:
cf create-route myspace example.com --hostname myapp
This will create a route myapp.example.com which you would then map to your app. Let’s say you named your app as "my-app" as follows:
cf map-route my-app example.com --hostname myapp
This will map route myapp.example.com to your application named my-app. Now your application is reachable to your clients at myapp.example.com. So, if your clients hit http://myapp.example.com/home or http://myapp.example.com/somewhereelse, both of these requests will be routed by Gorouter to your app "my-app".
This works perfectly fine if all the paths under the domain myapp.example.com can be served by one single app. However, in this era of microservices, it is possible–even likely–to have to create an application consisting of multiple microservices that has the same top domain myapp.example.com but serves just a few context paths in the URL. And, all of these microservices together serve all the supported paths under the domain myapp.example.com. So, how do you solve this issue in the CloudFoundry platform?
This is the problem that Context Path Routing addresses. In short, context path routing is routing based not only on domain names (host header) but also the path specified in the URL. Gorouter now can route requests to different apps based on path as well. So, this will enable your microservices architecture to use the same top level domain (myapp.example.com) and have different apps providing support for different paths in the URL. Now that you can achieve context path based routing, you can independently scale up or down those portions of your app that are in high/low demand or are experiencing high/low traffic.
Here is an example of how to create and map route that has paths:
To create route with path:
cf create-route myspace example.com --hostname myapp --path foo
This will create a route myapp.example.com/foo and then you would map it to your app as follows:
cf map-route my-app example.com --hostname myapp --path foo
This will map your app my-app to myapp.example.com/foo.
Similarly, you can create another route with same top level domain but different path and map it to a different app:
cf create-route myspace example.com --hostname myapp --path bar cf map-route my-another-app example.com --hostname myapp --path bar
Now requests to myapp.example.com/foo will be routed to app my-app while requests to myapp.example.com/bar will be routed to the app: my-another-app.
We hope this feature will help you realize your microservices architecture more quickly and effectively with CloudFoundry. As always, we love feedback–please share your experiences in the comments!
Published at DZone with permission of Atul Kshirsagar . See the original article here.
Opinions expressed by DZone contributors are their own.