Ratpack is a set of Java libraries that facilitate fast, efficient, evolvable and well-tested HTTP applications. It is built on the highly performant and efficient Netty event-driven networking engine.
Netty provides the infrastructure for non-blocking networking but doesn’t help much in the way of web application structure.
It provides an asynchronous API for working with network data (including HTTP).
Some Key Points
- Ratpack provides applications with a Netty-based, non-blocking HTTP client
- Can it be used to integrate with external RESTful services
- Utilizes the same event loop as the server, so resources are appropriately utilized
- Provides a robust API for programmatically crafting requests
- Environment-derivable conﬁguration follows the principle of the Twelve-Factor App Great Support for building MICROSERVICES!!
- NetﬂixOSS Hystrix support, via the ratpack- hystrix module
- Calls to remote services may be made fault tolerant
- Ability to stream Hystrix metrics to the Hystrix Dashboard Great Support for building MICROSERVICES!!
- Ratpack’s Promise API is an implementation of Reactive Streams Speciﬁcation
- The ratpack-rxjava module provides a bridge between a Ratpack Promise and an RxJava Observable
- The ratpack-reactor module allows data to be processed using Project Reactor Great Support for REACTIVE PROGRAMMING
Ratpack is purely a runtime.
To build Ratpack applications, you can use any JVM build tool. The Ratpack project provides specific support for Gradle through plugins, but any could be used.
- To be fast, scalable, and efficient
- To allow applications to evolve in complexity without compromise
- To leverage the benefits of non-blocking programming and reduce the costs
- To be flexible and unopinionated when it comes to integrating other tools and libraries
- To allow applications to be easily and thoroughly tested
Ratpacks’s Goals Are Not:
- To be a fully integrated, “full stack” solution
- Provide every feature you might need in a neat box
- To provide an architecture or framework for “business logic”
When to Use Ratpack?
- High-throughput apps
- Lightweight apps
- Cloud Deployments
Ratpack is strongly typed. Beyond being implemented in Java, a strongly typed language, its API embraces types.
Ratpack at its core is an event-based (i.e. non-blocking) HTTP IO engine, and an API that makes it easy to structure response logic. Being non-blocking imposes a different style of API than “traditional” blocking Java APIs in that the API must be asynchronous.
Ratpack aims to significantly simplify this style of programming for HTTP applications. It provides support for structuring asynchronous code, and uses an innovative approach for structuring request processing into a self-building, asynchronously traversed, graph of functions .
The RatpackServer type is the Ratpack entry point. You write your own main class that uses this API to launch the application.
The port method allows setting the port used to connect to the server. If not configured, the default value is 5050.
Ratpack is designed for “asynchronous” and “non-blocking” request processing. Its internal IO (e.g. HTTP request and response transfer) is all performed in a non-blocking fashion. This approach yields higher throughput, lower resource usage, and importantly, more predictable behavior under load.
This programming model has become increasingly popular of late due to the Node.js platform. Ratpack is built on the same non-blocking, event driven, model as Node.js.
Ratpack Is Fundamentally Asynchronous in Two Key Ways
- HTTP IO is event driven / non-blocking
- Request handling is organized as a pipeline of asynchronous functions
The HTTP IO being event driven is largely transparent when using Ratpack. Netty just does its thing.
Embedding Ratpack in a Spring Boot Application
The ratpack-spring-boot extension provides integration with Spring Boot. There are two main features in this library: one allows a Ratpack server registry to be created from a Spring ApplicationContext , and the other allows Ratpack itself to be embedded in a Spring Boot application (making the ApplicationContext automatically part of the server registry).
As an alternative to embedding Spring (as a Registry) in a Ratpack application, you can do the opposite: embed Ratpack as a server in Spring Boot, providing a nice alternative to the Servlet containers that Spring Boot supports. The core of the feature set is an annotation @EnableRatpack which you add to a Spring configuration class in order to start Ratpack.
TIP: Ratpack will register handlers automatically for static content in the classpath under “/public” or “/static” (just like a regular Spring Boot application).
If Ratpack is embedded in a Spring application it can be helpful to re-use existing Guice modules, e.g. for template rendering. To do this just include a @Bean of type Module. For example with the ThymeleafModule for Thymeleaf support
SpringBoot with Thymeleaf Sample
More details in my GitHub: My Sandbox
What does Ratpack give you over that Vert.x?
- Templating - fully async rendering, and statically compiled using Groovy 2.1
- Error handling (i.e. 500 pages)
- Not found handling (i.e. 404 pages)
- Routing - Vert.x already has this, but Ratpack’s is integrated with 404 and 500 handling (and runtime reloadable)
- Static file serving - Goes above what Vert.x gives you and support HTTP caching headers
- Session support
- Runtime reloading - for routes, and if you’re using the Gradle plugin for all of your application code
- Higher level abstractions - for example Request and Response
- Build tool (Gradle)
Here is a good sample from ratpack.io.