When we need to create a
URI object in Ratpack we can use the
HttpUrlBuilder class. We use several methods to build up a complete
URI object in an easy way. This is very useful when we for example use Ratpack’s
HttpClient object and we need to pass an
URI to do a request.
Pair class in Ratpack is an easy way to create a growing data structure, passed on via
Promise methods. A
Pair object has a left and right part containing data. These parts can even be other
Pair objects. Since Ratpack 1.4.0 the
Promise class has methods to set the right or left part of a
flatRight. The result of these methods is a
Promise<Pair> object. The input can be
Promise type or a
Function that can use a previous
Suppose we want to support partial JSON responses in our Ratpack application. The user must send a request parameter with a list of fields that need to be part of the response. In our code we must use the value of the request parameter and output only the given properties of an object. We implement this logic using a custom renderer in Ratpack. Inside the renderer we can get access to the request parameters of the original request.
Ratpack has a lot of options to add configuration data to our application. We can use for example YAML and JSON files, properties, environment variables and Java system properties. Groovy has the
ConfigSlurper class to parse Groovy script with configuration data. It even supports an
environments block to set configuration value for a specific environment. If we want to support Groovy scripts as configuration definition we write a class that implements the
To define configuration sources for our Ratpack application we have several options. We can set default properties, look at environment variables or Java system properties, load JSON or YAML formatted configuration files or implement our own configuration source. When something goes wrong using one of these methods we want to be able to handle that situation. For example if an optional configuration file is not found, we want to inform the user, but the application must still start. The default exception handling will throw the exception and the application is stopped. We want to customise this so we have more flexibility on how to handle exceptions.
Ratpack has a very useful class:
TestHttpClient. This is a blocking HTTP client that we normally use for testing our Ratpack applications. For example we use
GroovyRatpackMainApplicationUnderTest in a test and invoke the
getHttpClient method to get an instance of
TestHttpClient. The class has a lot of useful methods to make HTTP requests with a nice DSL.
TestHttpClient is also very useful as a standalone HTTP client in other applications.
Suppose we have a piece of code that uses an external HTTP service. If we write a test for this code we can invoke the real HTTP service each time we execute the tests. But it might be there is a request limit for the service or the service is not always available when we run the test. With Ratpack it is very, very easy to write a HTTP service that mimics the API of the external HTTP service. The Ratpack server is started locally in the context of the test and we can write extensive tests for our code that uses the HTTP service. We achieve this using the Ratpack
GroovyEmbeddedApp class. With very little code we configure a server that can be started and respond to HTTP requests.
When we define our Ratpack application using the Groovy DSL in a file
ratpack.groovy, we can split up the definition in multiple files. With the
include method inside the
ratpack configuration closure we can use the file name of the file we want to include. The file that we include also contains a
ratpack configuration closure. We can use the same
serverConfig sections. The
bindings configuration is appended to the parent configuration. The
serverConfig configuration is merged with the parent configuration.
In a previous post we learned how to add an extra
DataSource to our Ratpack application. At that time on the Ratpack Slack channel there was a discussion on this topic and Danny Hyun mentioned an idea by Dan Woods to use a
DataSource objects. So it easier to add more
Sql objects to the Ratpack registry. In this post we are going to take a look at a solution to achieve this.
Recently on our project where we use Ratpack we had to get data from different databases in our Ratpack application. We already used the
HikariModule to get a
DataSource to connect to one database. Then with the
SqlModule we use this
DataSource to create a Groovy
Sql instance in the registry. In our code we use the
Sql object to query for data. To use the second database we used the Guice feature binding annotations to annotate a second
Sql object. In this post we see how we can achieve this.
Interestingly while I was writing this post there was a question on the Ratpack Slack channel on how to use multiple datasources. The solution in this post involves still a lot of code to have a second
DataSource. In the channel Danny Hyun mentioned a more generic solution involving a
Map with multiple datasources. In a follow-up blog post I will write an implementation like that, so we have a more generic solution, with hopefully less code to write. BTW the Ratpack Slack channel is also a great resource to learn more about Ratpack.