I recently started working with Ratpack and I quite like it. I mostly did quick projects from scratch. But I would like to use it in an existing Spring Boot application to replace the traditional MVC part. This is actually easy to do as everything has been thought out already thanks to their Spring module.

If you follow this blog you might remember an old post about storing, indexing and searching files with Couchbase and Spring Boot. I will use the related code as an example. The idea is to replace Spring MVC by Ratpack, and making my legacy, synchronous, blocking services async and non blocking. The resulting code is available on github as well.

Adding the Right Dependencies

I am using Gradle. Ratpack is very well integrated with it. All you need to do to add a module is to add the right dependency by calling ratpack.dependency("myFavoriteModule"). So in our case, to add support for Spring Boot, you need to add ratpack.dependency("spring-boot"). Unfortunately the version automatically managed by Ratpack is less than 1.4.0.M3, which is the version that brings automatic Couchbase configuration. So this time I will have to add dependencies manually.

What you can see here is that ratpack.dependency("spring-boot") is a shortcut to add org.springframework.boot:spring-boot-autoconfigure:1.4.0.M3 and io.ratpack:ratpack-spring-boot:1.3.3. What this module gives you is the ability to integrate a Ratpack server to your Spring Application. You will be able to retrieve Spring @Beans from the Ratpack context and declare handlers as Spring configuration.

Declare Ratpack Configuration

One thing you have to love with Spring Boot is the autoconfig. You only need to make sure the Couchbase SDK is in the classpath, and that the property spring.couchbase.bootstrap-hosts is declared. At that moment Spring beans will be instantiated for a default Bucket. And this bucket instance will be available as a bean or in Ratpack’s context. So you don’t have to declare any binding for Couchbase in the Ratpack layer.

The first thing you traditionaly do with Ratpack is start a server and define the configuration and handlers. Here we already have a Spring Boot Application running. Every classes annotated with @Configuration will be picked up automatically and added to the application configuration. The first step to declare that configuration is create a Class that implements RatpackServerCustomizer and annotate it with @Confguration. It let you define a list of handlers, bindings and server configuration. In the Following example I am registering some server properties and binding several classes to Ratpack’s context. The ‘server.maxContentLength’ property is the maximum size of file you can upload.

The application templating system relies on Handlebars so you need the HandlebarsModule. FileHandler will handle all the call to the ‘/file’ API and the StoredFileRenderer make sure StoredFile will be rendered correctly. The last two bindings are for error managements.

The most imortant thing going on here is the fileAPI method that declares my handler. A handler defines what’s going on when a user hits a particular URL. Here we associate every ‘/file/*’ call to the FileHandler class. We also define the behavior for POST on ‘/fulltext’ and ‘/n1ql’.

Ratpack uses promises. So when you parse a Form coming from a POST request, you’ll get a promise. What you can see in each of those POST is that the SearchService is fetched from Ratpack’s context. Even if it was never binded in the configuration. That’s because Spring beans are available in the context as part of the integration.

The next step is to call that search service which returns an Observable. We can use Ratpack’s rx-java module that provides a wrapper for Observables. It will wrap this as a promise. Then you can simply render the response.

At this point we got rid of all the Spring MVC controllers. As you can see my service return an Observable. Which is not the case in my previous application.

Migrating Services for Ratpack

Most of my services relies on Couchbase. The SDK is based on RxJava so it’s really easy to convert most of those to an async, non-blocking fashion and have them returns Observable.

Using RxJava

This is a very simple example. It’s a N1QL query that maps the results to a List of Map. The two first lines don’t change at all as they are mostly defining the query. You can see that the mapping feels more natural when using the synchronous bucket in the second version.


What about Blocking Legacy Code?

Some of my services relies on old, blocking code. While there is no magical way to make them non-blocking, we can easily wrap them in a Promise. This will allow us use them easily in the Handlers. Wrapping blocking call is super easy, all you need to do is wrap your function with ‘Blocking.get()’. Here’s a very simple example:



Now you know pretty much everything you need to know to give some Ratpack Love to your Spring Boot application. If you feel like anything is missing please reach out to me on twitter or in the comments below.


Posted by Laurent Doguin, Developer Advocate, Couchbase

Laurent is a Paris based Developer Advocate where he focuses on helping Java developers and the French community. He writes code in Java and blog posts in Markdown. Prior to joining Couchbase he was Nuxeo’s community liaison where he devoted his time and expertise to helping the entire Nuxeo Community become more active and efficient.

Leave a reply