Aggregating Reverse Routers

Aggregating Reverse Routers in Play Framework

While routing in the play framework, there are some time conditions in which we have to share reverse Routing in our sub-projects that are not even dependent on each other.

Suppose you have an API and web sub-projects, which are not dependent on each other, except that the web projects want to render links to the API projects for making AJAX requests, whereas API projects want to render links to the web for resources in JSON.

In these circumstances, it would be convenient to utilize the reverse router, but you can't because these projects aren't interdependent.

The routes compiler in the Play framework has a feature that allows a common dependency to build reverse routers for projects that rely on it, allowing the reverse routers to be shared between those projects. This can be achieved by “Aggregating Reverse Routers.”

In the Play framework, one sbt configuration item aggregateReverseRoutes allow a common dependency to generate a reverse router for a project that depends on it.

Syntax of Aggregating Reverse Routers in Routing

The below-given syntax of reverse Routing of a non-dependent file using Aggregating Reverse Routers is:-

lazy val commonfile: Project = (project in file("commonfile"))
  .enablePlugins(PlayScala)
  .settings(
    aggregateReverseRoutes := Seq(module_A, module_B)
  )


lazy val module_A = (project in file("web_folder"))    // reverse routing web
  .enablePlugins(PlayScala)
  .dependsOn(commonfile)


lazy val module_B = (project in file("api_folder"))   // reverse routing API
  .enablePlugins(PlayScala)
  .dependsOn(commonfile)

The reverse routers for module_A (web) and module_B (API)  will be generated as part of the common project in this configuration. Meanwhile, the API and web forwards routers will continue to build routers, but not reverse routers, because their reverse routers have already been generated in the common project on which they rely. Thus they do not need to generate them.

Frequently Asked Questions

What is routing in the play framework?

A route is a URL pattern associated with a handler. The handler can be a physical item, such as a downloaded asset on a website, or a class that handles the request, such as a controller in an MVC application.

What is action in the play framework?

An action is a Java method that processes the request parameters and returns a result to the client. An action returns a play.mvc.Result value represents the HTTP response to send to the web client.

What is an iterator in the play framework?

The iterator interface gives a new way to traverse across any Collection. So, using the iterator approach, we can easily obtain an iterator object from a collection. It also allows the caller to destroy elements from the collection during iteration.

What is the advantage of the play framework?

The following are the benefits of Play Framework:

• It is open source.
• It is a full RESTful framework.
• It is highly flexible.
• Amazing error handling.
• It is a full embedded testing framework.

Conclusion

Congratulations on finishing the blog! We have discussed Aggregating Reverse Routers in the play framework. We further look at the syntax of aggregating reverse routers to reverse routes the non-dependent project.

If you liked this article, please visit more articles on the play framework. Some of them are:

• Guidelines for writing play documentation
• Improving Compilation time
• Cookbook
   

Please refer to our guided pathways on Code studio to learn more about DSA, Competitive Programming, JavaScript, System Design, etc. Enroll in our courses, and use the accessible sample exams and questions as a guide. For placement preparations, look at the interview experiences and interview package.

Please do upvote our blogs if you find them helpful and informative!

Happy learning!